فصل 23 از 24 درس 1 از 1

Backup، Restore و نگهداری Database

Backup، Restore و نگهداری Database

بخشی از آموزش جامع SQL Server

محتوای درس Backup، Restore و نگهداری Database

SQL Server | Recovery Model، Backup Chain و Restore Test

Backup زمانی ارزش عملی دارد که Restore آن تست شده باشد. Recovery Model، RPO و RTO تعیین می‌کنند Full، Differential و Log Backup با چه تناوبی و چه Retentionی نگهداری شوند.

متن این فصل با رویکرد مرجع فنی و قابل استفاده در پروژه واقعی تنظیم شده است؛ مثال‌ها در امتداد مدل StoreDb نوشته شده‌اند و اصطلاحات اصلی SQL Server و T-SQL به‌صورت یکدست به‌کار می‌روند.

1. مفاهیم و قراردادهای اصلی

Backup زمانی ارزش عملی دارد که Restore آن تست شده باشد. Recovery Model، RPO و RTO تعیین می‌کنند Full، Differential و Log Backup با چه تناوبی و چه Retentionی نگهداری شوند.

در طراحی پایگاه داده، Syntax تنها بخشی از مسئله است. نوع داده، Constraint، الگوی دسترسی، Transaction و هزینه اجرای Query باید هم‌زمان با نیاز Domain در نظر گرفته شوند.

مفهومکارکرد
Full Backupنسخه کامل
Differentialتغییرات از Full پایه
Log Backupزنجیره Transaction Log
Recovery Modelسیاست Log/Restore
RPOحداکثر از دست رفتن داده
RTOزمان بازیابی هدف

2. ساختار و Syntax پایه

Backup روی Storage مستقل نگهداری و با CHECKSUM در صورت سیاست سازمان تولید می‌شود. Restore Test دوره‌ای روی محیط جدا انجام می‌شود و فایل‌های لازم برای Chain مستند می‌مانند.

BACKUP DATABASE StoreDb
TO DISK = N'D:\SqlBackups\StoreDb_FULL.bak'
WITH INIT, CHECKSUM, STATS = 10;
GO

3. سناریوی StoreDb

برای Recovery Model FULL، Log Backupهای منظم بین Full/Differentialها نگهداری می‌شوند. حذف فایل قدیمی بدون فهم Dependency Chain می‌تواند Recovery را غیرممکن کند.

نمونه‌های این فصل بر مدل فروشگاهی StoreDb بنا شده‌اند تا ارتباط مفاهیم میان فصل‌ها حفظ شود و Queryها در یک Context یکپارچه قابل بررسی باشند.

RESTORE VERIFYONLY
FROM DISK = N'D:\SqlBackups\StoreDb_FULL.bak'
WITH CHECKSUM;
GO

-- Restore must also be tested on a separate instance/database.

4. اصول طراحی و Performance

طراحی پایدار باید هم صحت داده و هم هزینه اجرای عملیات را پوشش دهد. انتخاب ساده‌تر زمانی ترجیح دارد که Contract داده را روشن‌تر و رفتار Optimizer را قابل پیش‌بینی‌تر نگه دارد.

  • Backup روی همان Disk اصلی تنها نسخه نباشد.
  • Retention بر اساس RPO/RTO و ظرفیت Storage تعریف شود.
  • Backup Encryption نیازمند حفاظت جدا از Certificate/Key است.
  • Job Failure Alerting فعال باشد.

5. خطاهای رایج و نکات ایمنی

دستورهای SQL می‌توانند مستقیماً داده و ساختار را تغییر دهند؛ بنابراین بازبینی Context، تعداد Rowهای هدف و اثر Transaction قبل از اجرای تغییرات اهمیت عملی دارد.

  • داشتن فایل Backup بدون Restore Test.
  • حذف Log Backup میانی در Chain لازم.
  • عدم دسترسی SQL Server Service Account به Path.
  • ذخیره تنها Backup روی همان Server.

6. چک‌لیست نهایی فصل

  • RPO و RTO مشخص‌اند.
  • Full/Diff/Log Schedule تعریف شده است.
  • Restore Test اجرا می‌شود.
  • Backup Storage و Encryption Key محافظت می‌شوند.

7. جمع‌بندی

خروجی این فصل باید به تصمیمی قابل اتکا در طراحی یا Query منجر شود؛ صحت داده، قابلیت نگهداری و رفتار Performance سه معیار ثابت برای ارزیابی نمونه‌ها هستند.