بکاپی که آزموده نشده، بکاپ نیست: آزمون بازیابی را چطور انجام دهیم

یک جملهٔ ساده که تا روز حادثه بی‌آزار به نظر می‌رسد: «جاب بکاپ سبز است». جاب سبز یعنی فایلی نوشته شد. یعنی نوشتن موفق بود. دربارهٔ اینکه آن فایل قابل بازگرداندن است، چیزی نمی‌گوید.

فهرست چیزهایی که فقط در آزمون بازیابی معلوم می‌شوند، طولانی‌تر از چیزی است که اغلب تصور می‌شود — و هیچ‌کدامشان در لاگ موفقیت بکاپ دیده نمی‌شوند.

چه چیزهایی فقط اینجا معلوم می‌شوند

• فایل روی مسیری نوشته شده که دیگر وجود ندارد، یا کسی پاکش کرده.
• زنجیرهٔ لاگ شکسته: یک بکاپ دستی گرفته شده، یا مدل بازیابی عوض شده و برگشته.
• دیتابیس از قبل خرابی صفحه داشته، و بکاپ‌ها آن خرابی را وفادارانه کپی کرده‌اند.
• بکاپ رمزنگاری‌شده و کلیدش روی همان سروری بوده که قرار است بسوزد.
• بازیابی چهار ساعت طول می‌کشد، در حالی که تعهد شما یک ساعت است.
• سرور مقصد نسخهٔ پایین‌تری از SQL Server دارد و بکاپ را اصلاً نمی‌پذیرد.
• فضای دیسک مقصد برای دیتابیس بازگردانده‌شده کافی نیست.

کم‌ترین کار مفید

لازم نیست تمرین بزرگی برگزار کنید. این چهار خط، بیشتر ارزش را می‌دهند:

-- ۱) بازگرداندن با نام و مسیر دیگر
RESTORE DATABASE [Sales_drill]
FROM DISK = N'E:\backup\Sales_full.bak'
WITH MOVE N'Sales'     TO N'T:\drill\Sales_drill.mdf',
     MOVE N'Sales_log' TO N'T:\drill\Sales_drill.ldf',
     RECOVERY, STATS = 10;

-- ۲) آیا داده سالم است؟
DBCC CHECKDB([Sales_drill]) WITH NO_INFOMSGS, ALL_ERRORMSGS;

-- ۳) یک بررسی معنایی سبک: جدول‌های مهم خالی نیستند؟
SELECT COUNT(*) FROM [Sales_drill].dbo.Orders;

-- ۴) پاک‌سازی
DROP DATABASE [Sales_drill];

بند سوم را جدی بگیرید. CHECKDB سلامت ساختاری را می‌سنجد، نه معنایی. بکاپی که از دیتابیسی گرفته شده که اپلیکیشن دیشب خالی‌اش کرده، از نظر CHECKDB کاملاً سالم است.

چند نکتهٔ عملی

نام و مسیر متفاوت، اجباری است. یک اشتباه تایپی در نام دیتابیس، آزمون بازیابی را به حادثه تبدیل می‌کند. اگر ابزاری این کار را خودکار می‌کند، باید نامی بسازد که ممکن نیست با دیتابیس تولیدی اشتباه شود.

ترجیحاً روی سرور دیگری. اگر روی سرور تولیدی انجامش می‌دهید، CHECKDB سبک نیست و I/O می‌خورد. پنجرهٔ کم‌باری انتخاب کنید و هم‌زمان چند دیتابیس را آزمون نکنید.

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

مدت را ثبت کنید. این عدد همان RTO واقعی شماست و با بزرگ شدن دیتابیس رشد می‌کند. اگر ثبتش نکنید، متوجه نمی‌شوید که تعهد یک‌ساعته‌تان سال گذشته درست بود و امسال نیست.

هر چند وقت؟

بستگی به اهمیت دارد، ولی یک نقطهٔ شروع منطقی:

• دیتابیس‌های حیاتی: هفتگی.
• بقیه: ماهانه.
• و همیشه بعد از هر تغییر ساختاری — ارتقای نسخه، جابه‌جایی فایل‌ها، تغییر مقصد بکاپ.

نکته این است که این کار باید خودکار باشد. کاری که دستی انجام می‌شود، در ماه سوم انجام نمی‌شود؛ نه به‌خاطر تنبلی، بلکه چون در ماه سوم همه‌چیز آرام است و چیزی یادآوری‌اش نمی‌کند.

یک تجربهٔ شخصی دربارهٔ اعتماد به «خطا نداد»

اسکریپت ساخت حساب‌های دسترسی محصول خودمان را نوشته بودم و پیش از اجرا با SET PARSEONLY ON بررسی‌اش کرده بودم. نحو درست بود. اسکریپت روی سرور مشتری اجرا شد و بیشترش موفق بود — ولی سه GRANT سطح سرور بی‌صدا رد شدند، چون در آن نقطه دیتابیس جاری master نبود.

بررسی نحوی نمی‌توانست این را بگیرد: نحو درست بود، زمینهٔ اجرا غلط بود. و چون بقیهٔ اسکریپت موفق بود، همه‌چیز سالم به نظر می‌رسید تا وقتی که معلوم شد هیچ DMVی داده برنمی‌گرداند.

درسش دقیقاً همان درس آزمون بازیابی است: بررسی اینکه «خطا نداد» با بررسی اینکه «کار کرد» یکی نیست. تنها چیزی که دومی را ثابت می‌کند، انجام دادن همان کار در شرایط واقعی است — یک بار بازگرداندن، یک بار خواندن نتیجهٔ مجوزها، یک بار اجرای همان کوئری‌ای که قرار است روزی به دردتان بخورد.