بیشتر سازمان‌ها بکاپ دارند؛ گزارش روزانهٔ نرم‌افزار پشتیبان‌گیری هم سبز است. اما سؤال مهم این نیست که «بکاپ داریم؟»؛ این است که «اگر همین امروز سرور از دست برود، در چند ساعت و تا چه حد برمی‌گردد؟». این مقاله روالی را توضیح می‌دهد که برای جواب دادن به این سؤال استفاده می‌کنم؛ همان رویکردی که در پروژهٔ مرکز تصویربرداری گلرخ طب با پشتیبان‌گیری خودکار Veeam به کار رفت.
چرا «بکاپ موفق» کافی نیست؟
پیام «موفق» فقط می‌گوید کار پشتیبان‌گیری بدون خطا تمام شده. این‌ها را تضمین نمی‌کند:
- از همهٔ چیزهایی که لازم است نسخه گرفته شده باشد؛ مثلاً سرور جدیدی که بعداً اضافه شده، در Job نیست.
- پایگاه داده در لحظهٔ پشتیبان‌گیری در وضعیت سالم و سازگار بوده باشد.
- نسخهٔ پشتیبان خودش خراب نشده یا گرفتار باج‌افزار نشده باشد.
- بازیابی در زمانی که کسب‌وکار تحمل می‌کند تمام شود.
قدم ۱: بنویسید چه چیزی باید برگردد و تا کی
برای هر سرویس مهم دو عدد را با مدیران توافق کنید:
- حداکثر دادهٔ قابل از دست دادن (RPO): اگر بکاپ شبانه است، تا یک روز کاری داده ممکن است از دست برود. اگر این قابل قبول نیست، فاصلهٔ پشتیبان‌گیری باید کمتر شود.
- حداکثر زمان توقف (RTO): سرویس باید در چند ساعت برگردد.
بدون این دو عدد، معلوم نیست آزمون بازیابی موفق بوده یا نه.
قدم ۲: گزارش‌ها را واقعاً بخوانید
- هشدارها (Warning) را نادیده نگیرید؛ بسیاری از مشکل‌ها اول به‌صورت هشدار دیده می‌شوند.
- هر بار سرور یا ماشین مجازی جدیدی اضافه شد، بررسی کنید در Job پشتیبان‌گیری هست.
- فضای باقی‌مانده و مدت نگهداری نسخه‌ها را دوره‌ای بررسی کنید.
قدم ۳: آزمون بازیابی فایل
ساده‌ترین آزمون: چند فایل و پوشه از تاریخ‌های مختلف را در مسیری جدا بازیابی کنید و باز کنید. فایل‌هایی را انتخاب کنید که کاربران واقعاً استفاده می‌کنند، نه فایل آزمایشی.
قدم ۴: آزمون بالا آمدن ماشین مجازی
یک ماشین مجازی کامل را در شبکهٔ جدا (بدون اتصال به شبکهٔ اصلی، تا با نسخهٔ اصلی تداخل نکند) بازیابی کنید و ببینید:
- سیستم‌عامل بالا می‌آید؟
- سرویس‌ها اجرا می‌شوند و می‌شود وارد شد؟
در Veeam، قابلیت SureBackup همین آزمون را خودکار می‌کند: ماشین را از روی نسخهٔ پشتیبان در محیطی ایزوله اجرا و سالم بودنش را بررسی می‌کند.
قدم ۵: آزمون نرم‌افزار و پایگاه داده
بالا آمدن سرور یعنی سیستم‌عامل سالم است، نه لزوماً داده. پایگاه داده‌های مهم (مثلاً SQL Server نرم‌افزار مالی یا سامانهٔ پذیرش) را بازیابی کنید و:
- سلامت پایگاه داده را بررسی کنید؛ در SQL Server با
DBCC CHECKDB. - از کاربر کلیدی همان نرم‌افزار بخواهید چند رکورد آخر را ببیند و تأیید کند داده‌ها تا تاریخ مورد انتظار هستند.
قدم ۶: زمان بازیابی را اندازه بگیرید
از شروع تا پایان بازیابی را با ساعت ثبت کنید و با RTO مقایسه کنید. اگر بازیابی کامل ۱۲ ساعت طول می‌کشد و کسب‌وکار ۴ ساعت تحمل دارد، مشکل در طراحی است، نه در آزمون.
قدم ۷: یک نسخه دور از دسترس باج‌افزار
- قاعدهٔ ۳-۲-۱: سه نسخه، روی دو نوع رسانه، یکی بیرون از سازمان. جزئیاتش در مقالهٔ پشتیبان‌گیری با Veeam Backup؛ قانون ۳-۲-۱ آمده است.
- دست‌کم یک نسخه غیرقابل‌تغییر (Immutable) یا جدا از شبکه باشد.
- رمز و حساب مدیریت پشتیبان‌گیری را از حساب‌های دامنه جدا نگه دارید؛ باج‌افزاری که به دامنه دسترسی پیدا کند، نباید بتواند نسخه‌ها را پاک کند.
قدم ۸: نتیجه را ثبت کنید و دستورالعمل بنویسید
بعد از هر آزمون، یک صفحه کافی است: تاریخ، چه چیزی بازیابی شد، چقدر طول کشید، چه مشکلی پیش آمد و چه اصلاحی لازم است. یک دستورالعمل بازیابی مرحله‌به‌مرحله هم بنویسید تا در روز بحران، فرد دیگری هم بتواند انجامش دهد.
برنامهٔ پیشنهادی
- هر روز: بررسی گزارش‌ها و هشدارها
- هر ماه: بازیابی چند فایل و یک پایگاه داده
- هر سه ماه: بالا آوردن کامل ماشین‌های مجازی مهم در محیط جدا و اندازه‌گیری زمان
- هر بار تغییر بزرگ: آزمون دوباره؛ مثلاً بعد از مهاجرت سرور یا تغییر نرم‌افزار پشتیبان‌گیری
اگر نمی‌دانید بکاپ سرورهای مجموعه‌تان واقعاً برمی‌گردد یا نه، از صفحهٔ سرور HP و مجازی‌سازی درخواست بررسی بدهید.
عکس: NOIRLab/NSF/AURA/T. Slovinský، با مجوز CC BY 4.0، از ویکی‌مدیا کامنز.jpg)؛ برش داده شده.
