آموزش جامع دستور BACKUP در SQL Server
مقدمه و مسیر یادگیری
دستور BACKUP یکی از موضوعهای مهم مجموعه دستورات کاربردی Microsoft SQL Server است. نسخه پشتیبان کامل، تفاضلی یا Transaction Log را روی رسانه مشخص ایجاد میکند و ستون اصلی راهبرد بازیابی SQL Server است. شناخت این دستور زمانی ارزشمند میشود که علاوه بر شکل نوشتن، محدوده اثر، نیازمندی مجوز، رفتار در تراکنش و پیامد عملیاتی آن نیز روشن باشد.
این مقاله از تعریف و Syntax آغاز میکند، سپس پارامترها، خروجی، مثالهای مستقل، خطاهای رایج، ملاحظات کارایی و بهترین روشهای استفاده را توضیح میدهد. نمونهها از ساده به حرفهای چیده شدهاند و بخش پرسشهای متداول و مصاحبه نیز برای مرور سریع در نظر گرفته شده است.
پیش از اجرای نمونههای مدیریتی روی سرور واقعی، نام Database، مسیر فایل، شناسه Session و سطح دسترسی را با محیط خود تطبیق دهید. نمونهای که شامل Backup، Restore، DBCC یا KILL باشد باید ابتدا در آزمایشگاه و با برنامه بازگشت بررسی شود.
برای دیدن جایگاه این موضوع در کنار سایر فرمانها، راهنمای جامع دستورات کاربردی SQL Server را مطالعه کنید. مقاله مادر مسیر انتخاب میان فرمانهای پیام، خطا، Session، نگهداری و بازیابی را یکجا نشان میدهد.
تعریف دستور BACKUP
نسخه پشتیبان کامل، تفاضلی یا Transaction Log را روی رسانه مشخص ایجاد میکند و ستون اصلی راهبرد بازیابی SQL Server است.
در SQL Server هر فرمان در یک Scope مشخص اجرا میشود. هنگام استفاده از BACKUP باید مشخص باشد اثر آن فقط روی عبارت فعلی، Batch، Session، Database یا کل Instance است. همین تشخیص، پایه جلوگیری از اجرای ناخواسته و طراحی درست آزمون است.
از دید مهندسی، Syntax صحیح شرط لازم است اما کافی نیست. داده ورودی، Collation، نوع داده، تنظیمات SET، سطح جداسازی، مجوز و وضعیت Connection میتوانند نتیجه را تغییر دهند. بنابراین مثال حرفهای باید پیششرط و خروجی کنترلی داشته باشد.
Syntax استاندارد
BACKUP { DATABASE database_name | LOG database_name } TO backup_device [ WITH backup_option [ ,...n ] ];
پارامترها و اجزای مهم
- نام Database منبع
- نوع DATABASE یا LOG
- مقصد DISK یا URL/Device
- گزینههایی مانند CHECKSUM، COMPRESSION، COPY_ONLY و STATS
- نام و توضیح Backup Set
خروجی و اثر اجرایی
پیام پیشرفت و تکمیل Backup ایجاد میکند و Backup Set در رسانه و تاریخچه msdb ثبت میشود.
اگر این دستور در Procedure، Job یا ابزار استقرار استفاده شود، Caller باید بداند موفقیت چگونه اعلام میشود و خطا از چه مسیری برمیگردد. استفاده از Result Set کنترلی، پیام کوتاه، Error Number مشخص یا رکورد لاگ باید بر اساس قرارداد پروژه انتخاب شود.
کاربردهای واقعی در پروژه
سه کاربرد پرتکرار این موضوع عبارتاند از بازیابی حادثه، ساخت زنجیره Full/Differential/Log، تهیه COPY_ONLY پیش از تغییر پرریسک. در هر سه حالت، مالک عملیات و معیار پذیرش باید قبل از اجرا تعیین شود و تغییر مهم بدون نسخه پشتیبان یا مسیر Rollback انجام نشود.
در پروژه سازمانی بهتر است فرمان داخل یک Runbook یا اسکریپت نسخهبندیشده قرار گیرد. نام سرور و Database از محیط دریافت شود، ولی Identifier پویا فقط پس از اعتبارسنجی و QUOTENAME ساخته شود. مقادیر داده نیز در Dynamic SQL بهصورت پارامتر ارسال شوند.
قاعده عملی: BACKUP را فقط زمانی اجرا کنید که بتوانید در یک جمله بگویید چه چیزی تغییر میکند، موفقیت چگونه سنجیده میشود و در صورت شکست چه اقدامی انجام خواهد شد.
مثالهای عملی مستقل
ده مثال زیر جنبههای متفاوت BACKUP را پوشش میدهند. هر نمونه هدف، Query، خروجی مورد انتظار و نکته عملیاتی دارد. فرمانهای دارای اثر مدیریتی با نامها و مسیرهای نمونه نوشته شدهاند و باید پیش از اجرا شخصیسازی و تأیید شوند.
مثال شماره 1: Backup کامل پایه
در این سناریو هدف آن است که «Backup کامل پایه» به شکلی روشن و قابل بازتولید بررسی شود. Query زیر یک Batch کامل ارائه میدهد و میتوان آن را پس از کنترل Context و مجوزها در محیط آزمایش اجرا کرد.
BACKUP DATABASE [YourDatabase]
TO DISK = N'C:\SQLBackups\YourDatabase_Full.bak'
WITH INIT, NAME = N'YourDatabase Full Backup', STATS = 10;
| خروجی نمونه | تفسیر نتیجه |
|---|
| پیام درصد پیشرفت و تکمیل موفق | نتیجه مورد انتظار نشان میدهد سناریوی Backup کامل پایه با موفقیت طی شده است. |
نام Database و مسیر را برای محیط خود جایگزین و دسترسی سرویس را کنترل کنید. در محیط عملیاتی بهتر است ورودی، زمان اجرا، نام پایگاه داده و نتیجه نهایی نیز در یک لاگ ساختاریافته ثبت شود تا عیبیابی و ممیزی بعدی قابل اتکا باشد.
مثال شماره 2: Backup کامل با Checksum
در این سناریو هدف آن است که «Backup کامل با Checksum» به شکلی روشن و قابل بازتولید بررسی شود. Query زیر یک Batch کامل ارائه میدهد و میتوان آن را پس از کنترل Context و مجوزها در محیط آزمایش اجرا کرد.
BACKUP DATABASE [YourDatabase]
TO DISK = N'C:\SQLBackups\YourDatabase_Full_Checksum.bak'
WITH CHECKSUM, INIT, STATS = 10;
| خروجی نمونه | تفسیر نتیجه |
|---|
| Backup Set همراه Checksum | نتیجه مورد انتظار نشان میدهد سناریوی Backup کامل با Checksum با موفقیت طی شده است. |
CHECKSUM احتمال کشف برخی خرابیهای صفحه و انتقال را افزایش میدهد. در محیط عملیاتی بهتر است ورودی، زمان اجرا، نام پایگاه داده و نتیجه نهایی نیز در یک لاگ ساختاریافته ثبت شود تا عیبیابی و ممیزی بعدی قابل اتکا باشد.
مثال شماره 3: Backup فشرده
در این سناریو هدف آن است که «Backup فشرده» به شکلی روشن و قابل بازتولید بررسی شود. Query زیر یک Batch کامل ارائه میدهد و میتوان آن را پس از کنترل Context و مجوزها در محیط آزمایش اجرا کرد.
BACKUP DATABASE [YourDatabase]
TO DISK = N'C:\SQLBackups\YourDatabase_Full_Compressed.bak'
WITH COMPRESSION, CHECKSUM, INIT, STATS = 5;
| خروجی نمونه | تفسیر نتیجه |
|---|
| فایل معمولاً کوچکتر با مصرف CPU بیشتر | نتیجه مورد انتظار نشان میدهد سناریوی Backup فشرده با موفقیت طی شده است. |
پیش از استانداردسازی، Duration و CPU را در بار واقعی مقایسه کنید. در محیط عملیاتی بهتر است ورودی، زمان اجرا، نام پایگاه داده و نتیجه نهایی نیز در یک لاگ ساختاریافته ثبت شود تا عیبیابی و ممیزی بعدی قابل اتکا باشد.
مثال شماره 4: Backup تفاضلی
در این سناریو هدف آن است که «Backup تفاضلی» به شکلی روشن و قابل بازتولید بررسی شود. Query زیر یک Batch کامل ارائه میدهد و میتوان آن را پس از کنترل Context و مجوزها در محیط آزمایش اجرا کرد.
BACKUP DATABASE [YourDatabase]
TO DISK = N'C:\SQLBackups\YourDatabase_Diff.bak'
WITH DIFFERENTIAL, CHECKSUM, INIT, STATS = 10;
| خروجی نمونه | تفسیر نتیجه |
|---|
| Backup تغییرات از Full پایه | نتیجه مورد انتظار نشان میدهد سناریوی Backup تفاضلی با موفقیت طی شده است. |
Full پایه مناسب باید نگهداری شود تا Differential قابل Restore باشد. در محیط عملیاتی بهتر است ورودی، زمان اجرا، نام پایگاه داده و نتیجه نهایی نیز در یک لاگ ساختاریافته ثبت شود تا عیبیابی و ممیزی بعدی قابل اتکا باشد.
مثال شماره 5: Backup لاگ
در این سناریو هدف آن است که «Backup لاگ» به شکلی روشن و قابل بازتولید بررسی شود. Query زیر یک Batch کامل ارائه میدهد و میتوان آن را پس از کنترل Context و مجوزها در محیط آزمایش اجرا کرد.
BACKUP LOG [YourDatabase]
TO DISK = N'C:\SQLBackups\YourDatabase_Log.trn'
WITH CHECKSUM, INIT, STATS = 10;
| خروجی نمونه | تفسیر نتیجه |
|---|
| یک Log Backup در Recovery Model کامل یا Bulk-logged | نتیجه مورد انتظار نشان میدهد سناریوی Backup لاگ با موفقیت طی شده است. |
زنجیره Log برای Point-in-time Recovery حیاتی است. در محیط عملیاتی بهتر است ورودی، زمان اجرا، نام پایگاه داده و نتیجه نهایی نیز در یک لاگ ساختاریافته ثبت شود تا عیبیابی و ممیزی بعدی قابل اتکا باشد.
مثال شماره 6: Backup از نوع COPY_ONLY
در این سناریو هدف آن است که «Backup از نوع COPY_ONLY» به شکلی روشن و قابل بازتولید بررسی شود. Query زیر یک Batch کامل ارائه میدهد و میتوان آن را پس از کنترل Context و مجوزها در محیط آزمایش اجرا کرد.
BACKUP DATABASE [YourDatabase]
TO DISK = N'C:\SQLBackups\YourDatabase_CopyOnly.bak'
WITH COPY_ONLY, CHECKSUM, COMPRESSION, INIT;
| خروجی نمونه | تفسیر نتیجه |
|---|
| Full Backup مستقل از Differential Base | نتیجه مورد انتظار نشان میدهد سناریوی Backup از نوع COPY_ONLY با موفقیت طی شده است. |
برای Backup موردی که نباید برنامه عادی را به هم بزند مناسب است. در محیط عملیاتی بهتر است ورودی، زمان اجرا، نام پایگاه داده و نتیجه نهایی نیز در یک لاگ ساختاریافته ثبت شود تا عیبیابی و ممیزی بعدی قابل اتکا باشد.
مثال شماره 7: نوشتن روی دو فایل
در این سناریو هدف آن است که «نوشتن روی دو فایل» به شکلی روشن و قابل بازتولید بررسی شود. Query زیر یک Batch کامل ارائه میدهد و میتوان آن را پس از کنترل Context و مجوزها در محیط آزمایش اجرا کرد.
BACKUP DATABASE [YourDatabase]
TO DISK = N'C:\SQLBackups\YourDatabase_1.bak',
DISK = N'D:\SQLBackups\YourDatabase_2.bak'
WITH CHECKSUM, COMPRESSION, INIT, STATS = 10;
| خروجی نمونه | تفسیر نتیجه |
|---|
| Backup نواریشده روی دو مقصد | نتیجه مورد انتظار نشان میدهد سناریوی نوشتن روی دو فایل با موفقیت طی شده است. |
هر دو فایل برای Restore لازماند و Failure Domain مقصدها باید بررسی شود. در محیط عملیاتی بهتر است ورودی، زمان اجرا، نام پایگاه داده و نتیجه نهایی نیز در یک لاگ ساختاریافته ثبت شود تا عیبیابی و ممیزی بعدی قابل اتکا باشد.
مثال شماره 8: افزودن Metadata خوانا
در این سناریو هدف آن است که «افزودن Metadata خوانا» به شکلی روشن و قابل بازتولید بررسی شود. Query زیر یک Batch کامل ارائه میدهد و میتوان آن را پس از کنترل Context و مجوزها در محیط آزمایش اجرا کرد.
BACKUP DATABASE [YourDatabase]
TO DISK = N'C:\SQLBackups\YourDatabase_Named.bak'
WITH NAME = N'Full Nightly', DESCRIPTION = N'نسخه کامل شبانه', CHECKSUM;
| خروجی نمونه | تفسیر نتیجه |
|---|
| Backup Set با Name و Description | نتیجه مورد انتظار نشان میدهد سناریوی افزودن Metadata خوانا با موفقیت طی شده است. |
Metadata مدیریت Media حاوی چند Backup Set را سادهتر میکند. در محیط عملیاتی بهتر است ورودی، زمان اجرا، نام پایگاه داده و نتیجه نهایی نیز در یک لاگ ساختاریافته ثبت شود تا عیبیابی و ممیزی بعدی قابل اتکا باشد.
مثال شماره 9: رمزنگاری Backup
در این سناریو هدف آن است که «رمزنگاری Backup» به شکلی روشن و قابل بازتولید بررسی شود. Query زیر یک Batch کامل ارائه میدهد و میتوان آن را پس از کنترل Context و مجوزها در محیط آزمایش اجرا کرد.
BACKUP DATABASE [YourDatabase]
TO DISK = N'C:\SQLBackups\YourDatabase_Encrypted.bak'
WITH ENCRYPTION (ALGORITHM = AES_256, SERVER CERTIFICATE = [BackupCertificate]),
CHECKSUM, COMPRESSION;
| خروجی نمونه | تفسیر نتیجه |
|---|
| Backup رمزگذاریشده در صورت وجود Certificate | نتیجه مورد انتظار نشان میدهد سناریوی رمزنگاری Backup با موفقیت طی شده است. |
Certificate و Private Key باید جداگانه و امن پشتیبانگیری شوند. در محیط عملیاتی بهتر است ورودی، زمان اجرا، نام پایگاه داده و نتیجه نهایی نیز در یک لاگ ساختاریافته ثبت شود تا عیبیابی و ممیزی بعدی قابل اتکا باشد.
مثال شماره 10: اعتبارسنجی فایل پس از Backup
در این سناریو هدف آن است که «اعتبارسنجی فایل پس از Backup» به شکلی روشن و قابل بازتولید بررسی شود. Query زیر یک Batch کامل ارائه میدهد و میتوان آن را پس از کنترل Context و مجوزها در محیط آزمایش اجرا کرد.
RESTORE VERIFYONLY
FROM DISK = N'C:\SQLBackups\YourDatabase_Full.bak'
WITH CHECKSUM;
| خروجی نمونه | تفسیر نتیجه |
|---|
| پیام معتبر بودن ساختار Backup | نتیجه مورد انتظار نشان میدهد سناریوی اعتبارسنجی فایل پس از Backup با موفقیت طی شده است. |
VERIFYONLY مفید است اما جای Restore آزمایشی کامل را نمیگیرد. در محیط عملیاتی بهتر است ورودی، زمان اجرا، نام پایگاه داده و نتیجه نهایی نیز در یک لاگ ساختاریافته ثبت شود تا عیبیابی و ممیزی بعدی قابل اتکا باشد.
خطاهای رایج و روش پیشگیری
فایل Backup بدون آزمون Restore تضمین بازیابی نیست. این خطا معمولاً زمانی رخ میدهد که نمونه آموزشی بدون بررسی Context یا Scope به Production منتقل میشود. افزودن Guard، نمایش مقصد و توقف سریع با THROW راه پیشگیری قابل اتکایی است.
INIT میتواند Backup Setهای قبلی همان Media را بازنویسی کند. برای کنترل این وضعیت، ورودیها را پیش از اجرا اعتبارسنجی کنید و نتیجه مرحله حساس را با Query مستقل بسنجید. اگر عملیات قابل Rollback نیست، تأیید دوم و Backup معتبر ضروری است.
مسیر مقصد باید برای حساب سرویس SQL Server قابل دسترسی باشد. مستندسازی رفتار مورد انتظار و ثبت Error Number، Message، State و زمان اجرا باعث میشود تیم به جای آزمون و خطای تکراری، علت را بر اساس شواهد پیدا کند.
- نام Database و Instance پیش از اجرا کنترل شود.
- مجوز حساب اجرا با اصل کمترین دسترسی تعیین شود.
- در مسیر CATCH وضعیت تراکنش و تنظیمات Session تعیین تکلیف شود.
- Query کنترلی پس از عملیات، نتیجه واقعی را ثابت کند.
ملاحظات Performance و همزمانی
COMPRESSION معمولاً IO را کم و CPU را بیشتر مصرف میکند. ارزیابی کارایی باید بر اساس Baseline و در بازه زمانی مشخص باشد؛ یک Execution Plan یا عدد تجمعی بدون مقایسه، برای تصمیم Production کافی نیست.
Backup را روی Storage مستقل و پایششده بنویسید. اگر فرمان روی IO، Transaction Log، Worker Thread یا قفل اثر دارد، Wait Type و Blocking همزمان بررسی شود. افزایش سرعت یک Batch نباید با طولانیشدن توقف کاربران جبران شود.
Throughput، Duration و رشد Database را روندگیری کنید. برای اجرای دورهای، Duration، نتیجه، تعداد ردیف، حجم داده و خطاها در جدول تاریخچه ثبت شود. این تاریخچه ظرفیتسنجی و تشخیص تغییر رفتار پس از ارتقای نسخه را ممکن میکند.
بهترین روشها
- هدف و Scope دستور BACKUP را در ابتدای اسکریپت توضیح دهید.
- از نام Schema، نوع داده و تبدیل صریح استفاده کنید.
- مقادیر فارسی را با N و نوع nvarchar نگه دارید.
- برای خطای واقعی از TRY/CATCH و THROW استفاده کنید.
- تراکنش را کوتاه نگه دارید و XACT_STATE را در CATCH کنترل کنید.
- اسکریپت را تا حد ممکن قابل اجرای مجدد طراحی کنید.
- خروجی کنترلی و معیار پذیرش را در همان فایل قرار دهید.
- نسخه SQL Server و تفاوت محیط Cloud را پیش از استقرار بررسی کنید.
مقایسه BACKUP با Snapshot یا کپی فایل که جایگزین Backup سازگار SQL Server نیست باید بر اساس نیاز واقعی انجام شود. انتخاب فناوری یا فرمان صرفاً به دلیل آشنایی قبلی، ممکن است خوانایی، سازگاری یا قابلیت پشتیبانی آینده را کاهش دهد.
سؤالات متداول
سؤال 1: دستور BACKUP در SQL Server دقیقاً چه کاری انجام میدهد؟
دستور BACKUP نسخه پشتیبان کامل، تفاضلی یا Transaction Log را روی رسانه مشخص ایجاد میکند و ستون اصلی راهبرد بازیابی SQL Server است. دامنه اثر آن باید پیش از اجرا شناخته شود و نمونه نخست در محیط آزمایش بررسی شود تا انتظار تیم از پیام، Result Set یا تغییر وضعیت Session دقیق باشد.
سؤال 2: برای شروع یادگیری BACKUP چه پیشنیازی لازم است؟
آشنایی با Batch، Session، نوع داده، مجوز و تفاوت محیط توسعه و تولید کافی است. ابتدا Syntax و مثالهای پایه را اجرا کنید، سپس رفتار خطا و تراکنش را با داده کوچک بسنجید و در پایان سراغ سناریوی سازمانی بروید.
سؤال 3: BACKUP چه ارزش تجاری برای یک سامانه داده دارد؟
کاربرد درست آن میتواند زمان توقف، خطای انسانی و هزینه عیبیابی را کاهش دهد. ارزش واقعی زمانی ایجاد میشود که فرمان در Runbook، کنترل دسترسی، مانیتورینگ و آزمون بازیابی یا استقرار قرار گیرد، نه اینکه فقط یک دستور منفرد باشد.
سؤال 4: آیا استفاده حرفهای از BACKUP هزینه پروژه SQL Server را کم میکند؟
بله، اگر همراه استاندارد کدنویسی، بازبینی و پایش باشد. کاهش اجرای اشتباه، کوتاهشدن زمان تشخیص رخداد و قابل تکرار شدن عملیات، هزینه پشتیبانی را پایین میآورد؛ اما خودکارسازی بدون Guard میتواند ریسک را بیشتر کند.
سؤال 5: تفاوت BACKUP با Snapshot یا کپی فایل که جایگزین Backup سازگار SQL Server نیست چیست؟
BACKUP برای نسخه پشتیبان کامل، تفاضلی یا Transaction Log را روی رسانه مشخص ایجاد میکند و ستون اصلی راهبرد بازیابی SQL Server است. گزینه تخصصیتری است، درحالیکه Snapshot یا کپی فایل که جایگزین Backup سازگار SQL Server نیست دامنه یا هدف متفاوتی دارد. انتخاب باید بر اساس نیاز به سازگاری نسخه، اثر روی Session، مدیریت خطا، امکان Rollback و نتیجه قابل مشاهده انجام شود.
سؤال 6: چه زمانی برای پیادهسازی BACKUP از خدمات مشاوره SQL Server استفاده کنیم؟
اگر فرمان بخشی از مهاجرت، بازیابی، نگهداری Production، تغییر امنیتی یا عملیات دارای SLA است، بازبینی متخصص ارزشمند است. مشاور میتواند پیشنیاز، اسکریپت برگشت، مانیتورینگ، تست بار و معیار پذیرش را قبل از اجرا مشخص کند.
سؤال 7: رایجترین خطا هنگام کار با BACKUP چیست؟
فایل Backup بدون آزمون Restore تضمین بازیابی نیست. همچنین بیتوجهی به Context، مجوز و Scope باعث میشود نمونهای که در آزمایش موفق بوده در Production رفتار دیگری نشان دهد. راهحل، Guard صریح، TRY/CATCH و ثبت ورودیهای واقعی است.
سؤال 8: اثر BACKUP بر Performance چگونه ارزیابی میشود؟
COMPRESSION معمولاً IO را کم و CPU را بیشتر مصرف میکند. پیش و پس از اجرا باید Duration، CPU، IO، Waitها، Blocking و حجم Log متناسب با موضوع اندازهگیری شود. یک Snapshot منفرد کافی نیست و مقایسه با Baseline دوره مشابه نتیجه معتبرتری میدهد.
سؤال 9: بهترین روش استفاده از BACKUP چیست؟
بهترین روش این است که هدف، Context، مجوز، اثر تراکنشی، Timeout و مسیر بازگشت مستند شوند. اسکریپت باید قابل اجرای مجدد یا دستکم دارای کنترل جلوگیری از اجرای دوباره باشد و نتیجه نهایی را بهصورت قابل ممیزی گزارش کند.
سؤال 10: BACKUP با کدام نسخههای SQL Server سازگار است؟
گزینهها به Edition، نسخه و مقصد ذخیرهسازی وابستهاند؛ فشردهسازی و رمزنگاری باید در محیط هدف بررسی شود. علاوه بر شماره نسخه، Compatibility Level، Edition، سیستمعامل، سرویس ابری و مجوز حساب اجرا نیز باید در محیط مقصد آزموده شود؛ مستندات همان نسخه مرجع نهایی تصمیم است.
سؤالات مصاحبه SQL Server
پرسش مصاحبه 1: در مصاحبه چگونه کاربرد BACKUP را توضیح دهیم؟
ابتدا هدف را در یک جمله بگویید، سپس Scope اثر، یک مثال واقعی، خطر اصلی و روش کنترل آن را شرح دهید. پاسخ حرفهای فقط Syntax نیست و باید نشان دهد اثر دستور روی Session، Transaction، IO یا بازیابی را میفهمید.
پرسش مصاحبه 2: چه نکتهای پاسخ مبتدی و حرفهای درباره BACKUP را جدا میکند؟
پاسخ حرفهای درباره خطا، مجوز، قابلیت اجرای مجدد، مشاهدهپذیری و تفاوت محیط آزمایش و Production صحبت میکند. همچنین جایگزین مناسب و دلیل انتخاب را بیان میکند.
پرسش مصاحبه 3: اگر اجرای BACKUP شکست بخورد چه میکنید؟
ابتدا Error Number، Message، State، Context، ورودی و وضعیت تراکنش ثبت میشود. سپس بدون تکرار کورکورانه، علت بررسی و بر اساس Runbook مسیر Rollback یا Retry کنترلشده اجرا میشود.
پرسش مصاحبه 4: چگونه BACKUP را برای Production آماده میکنید؟
حداقل مجوز، Guard مقصد، ورودی پارامتری، Timeout، TRY/CATCH، ثبت نتیجه، آزمون روی داده نماینده و تأیید مالک سرویس لازم است. برای عملیات مدیریتی، پنجره اجرا و برنامه بازگشت نیز تعیین میشود.
پرسش مصاحبه 5: چه معیارهایی موفقیت BACKUP را ثابت میکنند؟
معیار باید قابل اندازهگیری باشد: نتیجه داده، وضعیت Session یا Database، زمان اجرا، نبود خطای جدید، اثر قابل قبول بر IO و Blocking و ثبت خروجی کنترلی. معیار پذیرش پیش از اجرا نوشته میشود.
چکلیست نهایی
- Context پایگاه داده و نام Instance تأیید شد.
- Syntax و ورودیها در محیط آزمایش اجرا شدند.
- مجوزها و اثر روی Session یا Database مشخص است.
- مسیر خطا، Rollback و Timeout بررسی شده است.
- اثر کارایی با Baseline مقایسه میشود.
- خروجی کنترلی و لاگ نهایی تعریف شده است.
- برای عملیات حساس، Backup و تأیید مالک سرویس وجود دارد.
- اسکریپت و نتیجه اجرا نسخهبندی و مستند میشوند.
جمعبندی
دستور BACKUP زمانی بهدرستی استفاده شده است که علاوه بر نتیجه فنی، ریسک عملیاتی آن هم مدیریت شود. در این مقاله Syntax، پارامترها، ده سناریوی مستقل، خروجی نمونه، خطاها، Performance، Best Practice و پرسشهای مصاحبه بررسی شد تا بتوانید فرمان را آگاهانه در Query، Procedure، Job یا Runbook به کار ببرید.
برای مرور ارتباط BACKUP با دیگر موضوعهای این مجموعه، به مقاله مادر دستورات کاربردی SQL Server بازگردید. پیش از استفاده در Production، نمونه مرتبط را با نامها، مسیرها، مجوزها و SLA واقعی سازمان خود تطبیق دهید.