📌 Backup در SQL Server چیست؟

Backup یعنی گرفتن یک کپی ایمن از داده‌ها و ساختار پایگاه داده برای اینکه در مواقعی مثل:

• حذف یا خراب شدن داده‌ها
• حمله یا ویروس
• خطای انسانی (مثلا کسی اشتباه داده پاک کنه)
• خرابی سخت‌افزار یا سرور

بتونی دیتابیس رو برگردونی (Restore) به حالت قبل.

---

📌 انواع Backup در SQL Server

SQL Server چند نوع مختلف از بکاپ رو پشتیبانی می‌کنه:

1. Full Backup (بکاپ کامل)

• تمام دیتابیس (جداول، داده‌ها، ایندکس‌ها، توابع، پروسیجرها و …) رو ذخیره می‌کنه.
• نقطه شروع همه‌ی بکاپ‌هاست.
• معمولا به صورت هفتگی یا روزانه گرفته می‌شه.

مثال:

BACKUP DATABASE MyDatabase
TO DISK = 'C:\Backups\MyDatabase_Full.bak'
WITH INIT, NAME = 'Full Backup of MyDatabase';

---

2. Differential Backup (بکاپ تفاضلی/تفاوتی)

• فقط تغییراتی که از آخرین Full Backup تا الان رخ داده رو ذخیره می‌کنه.
• سریع‌تر و حجم کمتر از Full داره.
• برای Restore نیاز به آخرین Full Backup + آخرین Differential Backup داری.

مثال:

BACKUP DATABASE MyDatabase
TO DISK = 'C:\Backups\MyDatabase_Diff.bak'
WITH DIFFERENTIAL, NAME = 'Differential Backup of MyDatabase';

---

3. Transaction Log Backup (بکاپ لاگ تراکنش‌ها)

• برای دیتابیس‌هایی که در حالت FULL یا BULK_LOGGED recovery model هستن.
• تغییرات ثبت‌شده در Transaction Log رو ذخیره می‌کنه.
• امکان Point-in-Time Recovery می‌ده (یعنی می‌تونی دیتابیس رو برگردونی دقیقا تا ساعت/ثانیه خاص).
• معمولا در سیستم‌های حساس (بانک، فروش آنلاین) هر ۱۵ دقیقه یا کمتر گرفته می‌شه.

مثال:

BACKUP LOG MyDatabase
TO DISK = 'C:\Backups\MyDatabase_Log.trn'
WITH NAME = 'Log Backup of MyDatabase';

---

4. File و Filegroup Backup

• مخصوص دیتابیس‌های بزرگ (مثلا چند ترابایت).
• می‌تونی به جای کل دیتابیس، فقط فایل‌ها یا گروه فایل‌های خاص رو بکاپ بگیری.

---

5. Partial Backup

• فقط قسمت‌هایی از دیتابیس (مثلا گروه فایل Primary و بعضی Filegroupها) رو ذخیره می‌کنه.

---

📌 Recovery Models در SQL Server

قبل از طراحی استراتژی بکاپ، باید Recovery Model دیتابیس رو بشناسی:

1. Simple → فقط Full و Differential کار می‌کنه. لاگ تراکنش به صورت خودکار truncate می‌شه.
   • مناسب دیتابیس‌هایی که نیاز به point-in-time recovery ندارن.
   • مثال: دیتابیس گزارشات موقت.
2. Full → همه‌ی انواع بکاپ (Full, Differential, Log) پشتیبانی می‌شه.
   • مناسب دیتابیس‌های حیاتی (بانکی، مالی).
3. Bulk-Logged → مثل Full ولی عملیات Bulk (مثل Import بزرگ) با حداقل لاگ ذخیره می‌شه.

---

📌 Restore در SQL Server

برای بازگردانی بکاپ‌ها از دستور RESTORE استفاده می‌کنیم.

Restore Full Backup

RESTORE DATABASE MyDatabase
FROM DISK = 'C:\Backups\MyDatabase_Full.bak'
WITH REPLACE, RECOVERY;

Restore Full + Differential

-- Full
RESTORE DATABASE MyDatabase
FROM DISK = 'C:\Backups\MyDatabase_Full.bak'
WITH NORECOVERY;

-- Differential
RESTORE DATABASE MyDatabase
FROM DISK = 'C:\Backups\MyDatabase_Diff.bak'
WITH RECOVERY;

Restore Full + Log Backups (Point-in-Time)

-- Full
RESTORE DATABASE MyDatabase
FROM DISK = 'C:\Backups\MyDatabase_Full.bak'
WITH NORECOVERY;

-- Log
RESTORE LOG MyDatabase
FROM DISK = 'C:\Backups\MyDatabase_Log.trn'
WITH STOPAT = '2025-09-26T10:30:00', RECOVERY;

---

📌 استراتژی‌های بکاپ رایج در سازمان‌ها

🔹 مثال: سیستم فروش اینترنتی

• یک Full Backup در هفته (مثلا شنبه شب)
• یک Differential Backup هر شب
• یک Transaction Log Backup هر ۱۵ دقیقه

🔹 مثال: دیتابیس گزارش‌ها (Report DB)

• فقط Full Backup شبانه
• یا حتی هفتگی، چون اطلاعات حیاتی نیست.

---

📌 نکات مهم برای آزمون استخدامی

• Full Backup = کل دیتابیس.
• Differential = تغییرات از آخرین Full.
• Log Backup = تغییرات در لاگ → برای Point-in-Time Recovery.
• Recovery Models تعیین می‌کنن چه بکاپ‌هایی می‌شه گرفت.
• برای برگردوندن به زمان خاص → Full + (Diff) + Log(s) نیاز داری.
• WITH NORECOVERY یعنی آماده نگه داشتن دیتابیس برای Restoreهای بعدی.
• WITH RECOVERY یعنی Restore رو کامل کن.

---

📌 یک سناریوی واقعی (مثال تریس‌شده)

فرض کن:

• Full Backup → شنبه شب
• Differential Backup → دوشنبه شب
• Log Backups → هر ساعت

سه‌شنبه ساعت ۱۰ صبح دیتابیس کرش کرد.

برای Restore باید:

1. Full Backup (شنبه) رو Restore کنی (WITH NORECOVERY)
2. Differential Backup (دوشنبه) رو Restore کنی (WITH NORECOVERY)
3. تمام Log Backupها رو تا ساعت ۱۰ صبح Restore کنی
   (آخرین Log با WITH STOPAT دقیقاً تا ساعت ۱۰)
4. آخرین دستور رو WITH RECOVERY بزنی.

📌 سناریو

• Full Backup → شنبه شب (MyDB_Full.bak)
• Differential Backup → دوشنبه شب (MyDB_Diff.bak)
• Log Backups → هر ساعت (MyDB_Log_20250923_01.trn, MyDB_Log_20250923_02.trn, … تا ساعت ۱۰ صبح سه‌شنبه)
• کرش اتفاق افتاده → سه‌شنبه ساعت ۱۰ صبح

---

📌 مراحل Restore

1️⃣ ریستور Full Backup (شنبه شب)

اینجا از WITH NORECOVERY استفاده می‌کنیم چون می‌خوایم هنوز بکاپ‌های دیگه هم اعمال کنیم.

RESTORE DATABASE MyDB
FROM DISK = 'C:\Backups\MyDB_Full.bak'
WITH NORECOVERY;

---

2️⃣ ریستور Differential Backup (دوشنبه شب)

باز هم WITH NORECOVERY چون هنوز لاگ‌ها رو باید اعمال کنیم.

RESTORE DATABASE MyDB
FROM DISK = 'C:\Backups\MyDB_Diff.bak'
WITH NORECOVERY;

---

3️⃣ ریستور Log Backups (تا قبل از ساعت ۱۰ صبح سه‌شنبه)

هر Log Backup رو به ترتیب اعمال می‌کنیم. همه با WITH NORECOVERY به جز آخرین مورد.

مثال:

-- Log ساعت ۷ صبح
RESTORE LOG MyDB
FROM DISK = 'C:\Backups\MyDB_Log_20250923_07.trn'
WITH NORECOVERY;

-- Log ساعت ۸ صبح
RESTORE LOG MyDB
FROM DISK = 'C:\Backups\MyDB_Log_20250923_08.trn'
WITH NORECOVERY;

-- Log ساعت ۹ صبح
RESTORE LOG MyDB
FROM DISK = 'C:\Backups\MyDB_Log_20250923_09.trn'
WITH NORECOVERY;

-- Log ساعت ۱۰ صبح (با توقف دقیق در ساعت کرش)
RESTORE LOG MyDB
FROM DISK = 'C:\Backups\MyDB_Log_20250923_10.trn'
WITH STOPAT = '2025-09-23T10:00:00',
     RECOVERY;

---

📌 نکته مهم

• WITH NORECOVERY → دیتابیس در حالت Restoring باقی می‌مونه (برای اعمال بکاپ‌های بعدی).
• WITH RECOVERY → دیتابیس آماده استفاده می‌شه و روند Restore تموم می‌شه.

---

✅ با این روش دیتابیس دقیقا تا ساعت ۱۰ صبح سه‌شنبه بازیابی می‌شه.

چرا باید همه Log Backupها رو به ترتیب Restore کنیم؟

• هر Transaction Log Backup فقط شامل تراکنش‌هایی هست که بعد از آخرین Log Backup گرفته شده، ثبت شدن.
• یعنی Log ساعت ۸ فقط تغییرات بین ۷ تا ۸ رو داره.
• Log ساعت ۹ فقط تغییرات بین ۸ تا ۹ رو داره.
• Log ساعت ۱۰ فقط تغییرات بین ۹ تا ۱۰ رو داره.

📌 بنابراین:
اگر مستقیم فقط Log ساعت ۱۰ رو Restore کنی → SQL Server تغییرات بین ۷ تا ۹ رو نداره، پس دیتابیس ناقص و ناسازگار می‌شه.

---

📌 تریس ساده با مثال

فرض کن یک جدول داری و تراکنش‌ها این شکلی اتفاق افتادن:

• ساعت 07:10 → کاربر A یک رکورد اضافه کرد.
• ساعت 08:20 → کاربر B یک رکورد حذف کرد.
• ساعت 09:45 → کاربر C یک رکورد آپدیت کرد.
• ساعت 09:59 → کاربر D یک رکورد اضافه کرد.

حالا اگه دیتابیس کرش کنه و تو فقط Log ساعت ۱۰ رو Restore کنی:

• تغییرات 07:10، 08:20 و 09:45 گم می‌شن چون اونها توی Log 10 نیستن (توی لاگ‌های قبلی بودن).

---

📌 روند درست

برای اینکه دیتابیس دقیقاً همون چیزی بشه که بود:

1. Full Restore (شنبه)
2. Diff Restore (دوشنبه)
3. Log Restore 7 → تغییرات بین 6–7
4. Log Restore 8 → تغییرات بین 7–8
5. Log Restore 9 → تغییرات بین 8–9
6. Log Restore 10 → تغییرات بین 9–10 (و StopAt = 10:00)

نمی‌شه فقط آخرین Log رو Restore کرد.
چون Logها زنجیره‌ای (Chain) هستن و باید به ترتیب اعمال بشن تا دیتابیس کامل و سالم بازیابی بشه.

سناریو جدید

• Full Backup → شنبه شب
• Differential Backup → دوشنبه شب
• Transaction Log Backup → هر ساعت
• دیتابیس چهارشنبه ساعت ۱۰ صبح کرش کرده

---

📌 روند Restore

1️⃣ Full Backup شنبه شب → Restore با WITH NORECOVERY

RESTORE DATABASE MyDB
FROM DISK = 'C:\Backups\MyDB_Full.bak'
WITH NORECOVERY;

2️⃣ Differential Backup دوشنبه شب → Restore با WITH NORECOVERY

RESTORE DATABASE MyDB
FROM DISK = 'C:\Backups\MyDB_Diff.bak'
WITH NORECOVERY;

3️⃣ Transaction Log Backups

• چون کرش چهارشنبه ساعت ۱۰ صبح اتفاق افتاده، همه Logها از بعد Differential تا زمان کرش باید اعمال بشن.
• فرض کن Logها هر ساعت هستن، پس باید به ترتیب:
  • سه‌شنبه ۰۰:۰۰ تا ۰۱:۰۰
  • سه‌شنبه ۰۱:۰۰ تا ۰۲:۰۰
  • …
  • چهارشنبه ۰۹:۰۰ تا ۱۰:۰۰
• هر Log Backup با WITH NORECOVERY و آخرین Log Backup با WITH STOPAT = 'زمان کرش' و WITH RECOVERY

مثال آخرین دستور:

RESTORE LOG MyDB
FROM DISK = 'C:\Backups\MyDB_Log_20250925_10.trn'
WITH STOPAT = '2025-09-25T10:00:00',
     RECOVERY;

---

📌 نکات مهم

• تفاوت با سناریوی سه‌شنبه: Logها بیشتر شدن چون باید کل Logها از Differential (دوشنبه شب) تا چهارشنبه ۱۰ صبح اعمال بشن.
• Differential Backup همیشه از آخرین Full Backup هست. پس همیشه ترتیب: Full → Differential → Logs.
• اگر Logها رو Skip کنی یا ترتیبشون رعایت نشه → دیتابیس ناقص یا خراب می‌شه.

---

تفاوت بکاپ و اسنپ شات

Database Snapshot در SQL Server

🔹 Snapshot در SQL Server یعنی گرفتن یک عکس لحظه‌ای (Read-Only) از دیتابیس در یک زمان مشخص.

• برخلاف Backup، Snapshot روی همون سرور ذخیره می‌شه (نه روی فایل جدا برای بکاپ).
• Snapshot برای Backup و Restore واقعی استفاده نمی‌شه؛ بیشتر برای برگشت سریع به حالت قبلی (Rollback) یا گزارش‌گیری به کار می‌ره.

---

✨ ویژگی‌های Snapshot

1. فقط روی دیتابیس‌های Full Recovery Model قابل استفاده‌ست.
2. Read-Only هست (کاربر فقط می‌تونه بخونه، تغییر نمی‌تونه بده).
3. هر تغییر در دیتابیس اصلی بعد از ساخت Snapshot، در یک فایل جدا (Sparse File) ذخیره می‌شه → یعنی Snapshot فقط تغییرات رو نگه می‌داره، نه کل دیتابیس.
4. می‌تونی به سرعت دیتابیس رو به حالت Snapshot برگردونی (Restore to Snapshot).

---

📌 مثال ایجاد Snapshot

CREATE DATABASE MyDB_Snapshot_20250926
ON
(
    NAME = MyDB_Data,
    FILENAME = 'C:\Snapshots\MyDB_Snapshot_20250926.ss'
)
AS SNAPSHOT OF MyDB;

📌 این کد یک Snapshot به اسم MyDB_Snapshot_20250926 از دیتابیس MyDB می‌سازه.

---

📌 استفاده از Snapshot برای بازگشت

فرض کن کسی یک عملیات اشتباه انجام داد (مثلا یک جدول مهم پاک شد).
اگر قبلا Snapshot گرفته باشی، می‌تونی خیلی سریع برگردی:

RESTORE DATABASE MyDB
FROM DATABASE_SNAPSHOT = 'MyDB_Snapshot_20250926';

---

📌 تفاوت Snapshot با Backup

ویژگی	Backup	Snapshot
محل ذخیره	روی دیسک جدا (قابل انتقال)	روی همون سرور (Sparse File)
نوع دسترسی	Backup/Restore کامل	Read-Only
هدف اصلی	حفاظت در برابر خرابی، انتقال، بازیابی در آینده	بازگشت سریع به یک حالت خاص، گزارش‌گیری
مصرف فضا	بسته به نوع (Full/Diff/Log)	فقط تغییرات بعد از Snapshot
ماندگاری	بلندمدت	موقت (تا وقتی Snapshot وجود داره)

---

📌 سناریوی واقعی

• قبل از اجرای یک عملیات حساس (مثل آپدیت سنگین یا اسکریپت تغییر ساختار)، DBA یک Snapshot می‌سازه.
• اگر عملیات موفق بود → Snapshot رو پاک می‌کنه.
• اگر عملیات اشتباه شد → دیتابیس رو به Snapshot برمی‌گردونه.

---

🔑 نتیجه:

• Backup → برای حفاظت بلندمدت و ریکاوری بعد از خرابی‌هاست.
• Snapshot → برای برگردوندن سریع در کوتاه‌مدت و تست‌هاست.

📌 جدول مقایسه روش‌های حفاظت داده در SQL Server

روش	توضیح ساده	نوع دسترسی	هدف اصلی	مصرف منابع	سناریوی رایج
Full Backup	بکاپ کامل از کل دیتابیس (ساختار + داده)	قابل بازیابی کامل	حفاظت بلندمدت	زیاد (کل دیتابیس)	هفتگی/روزانه در همه دیتابیس‌ها
Differential Backup	ذخیره تغییرات از آخرین Full	نیاز به Full + Diff	سرعت در بکاپ‌گیری	متوسط	بکاپ شبانه برای کاهش حجم
Transaction Log Backup	ذخیره تراکنش‌های ثبت‌شده در لاگ	Point-in-Time Recovery	بازیابی لحظه‌ای	کم ولی زیاد می‌شه (اگر مداوم گرفته نشه)	دیتابیس‌های مالی/بانکی
File/Filegroup Backup	بکاپ‌گیری فقط از فایل‌ها یا گروه فایل‌ها	بستگی دارد	دیتابیس‌های بزرگ (TB)	کمتر از Full	دیتابیس‌های عظیم
Snapshot	تصویر لحظه‌ای Read-Only از دیتابیس	فقط خواندنی	بازگشت سریع، گزارش‌گیری	کم (Sparse File)	قبل از عملیات حساس
Mirroring	نگه داشتن کپی کامل دیتابیس روی سرور دوم	فقط Failover	افزایش دسترس‌پذیری (HA)	بالا (نیاز سرور دوم)	سیستم‌های حساس
Replication	کپی و همگام‌سازی داده‌ها بین چند دیتابیس	بسته به نوع (Read/Write)	توزیع داده، گزارش‌گیری	متوسط تا بالا	سیستم‌های توزیع‌شده، گزارش‌ها
Always On (Availability Groups)	راهکار مدرن HA/DR با چند Replica	Read/Write (قابل تنظیم)	High Availability + Disaster Recovery	بالا (نیاز چند سرور + لایسنس)	سازمان‌های Enterprise
Log Shipping	انتقال لاگ‌های تراکنش به سرور دیگر + Restore خودکار	Read-Only (سرور مقصد)	Disaster Recovery	متوسط	سرور DR ساده و ارزان

---

📌 جمع‌بندی ساده

• Backup/Diff/Log → حفاظت سنتی (فایل بکاپ → بازیابی).
• Snapshot → عکس لحظه‌ای، کوتاه‌مدت.
• Mirroring / Always On → High Availability (بدون Downtime).
• Replication → پخش داده برای گزارش/عملکرد.
• Log Shipping → انتقال به سرور پشتیبان ساده.