بکاپ سرور؛ راهنمای عملی طراحی پشتیبان و بازیابی مطمئن

بکاپ سرور یعنی ساختن نسخه‌ای جداگانه از داده‌های حیاتی یک سرویس، طوری که پس از یک رخداد ناخوشایند — پاک شدن اشتباهی، قفل شدن داده با باج‌افزار یا از کار افتادن دیسک — بتوان کل سرویس را به حالت سالم برگرداند. اگر آن کپی روی همان دیسکی بماند که داده اصلی رویش است، هر حادثه‌ای که سراغ اصل بیاید نسخه را هم می‌برد. در این راهنما از لایه‌های بکاپ و قاعدهٔ ۳-۲-۱ شروع می‌کنیم، دو شاخص مهم RPO و RTO را می‌شکافیم، ابزارهای رایج را می‌سنجیم و در پایان یاد می‌گیریم بازیابی را چطور واقعاً آزمایش کنیم.

چرا کپی گرفتن بدون برنامه کافی نیست؟

کپی گرفتن از داده‌ها کار سختی نیست؛ سخت‌تر این است که آن کپی در لحظهٔ درست، سالم و در دسترس باشد. حذف اشتباه یک جدول، رمز شدن فایل‌ها با باج‌افزار، خرابی منطقی دیسک یا یک به‌روزرسانی ناموفق، هریک سناریوی متفاوتی برای بازیابی می‌سازند.

بسیاری از باج‌افزارهای امروزی پیش از هر چیز سراغ نسخه‌های پشتیبانِ در دسترس می‌روند تا راه بازگشت را ببندند. به همین دلیل، بکاپی که حساب کاربری و مسیر دسترسی‌اش با سرور اصلی مشترک است، در عمل محافظت چندانی ایجاد نمی‌کند.

بکاپی که با همان دسترسی سرور اصلی قابل حذف باشد، در واقع مستقل نیست.

بکاپ در چه لایه‌هایی گرفته می‌شود؟

یک طرح کامل معمولاً سه لایه را جداگانه پوشش می‌دهد؛ چون روش پشتیبان‌گیری هر لایه با دیگری فرق دارد.

• سطح فایل: پوشه‌های مشخص مثل کد سایت و فایل‌های آپلودی را کپی می‌کند؛ سبک و انعطاف‌پذیر است، اما برای بازگرداندن کل سیستم کافی نیست.
• سطح دیتابیس: باید در حالت سازگار گرفته شود؛ کپی خام از فایل‌های یک دیتابیس در حال اجرا می‌تواند خروجی خراب بسازد.
• سطح ایمیج: از کل دیسک یا ماشین مجازی نسخه می‌گیرد و بازگرداندن کامل سیستم روی سخت‌افزار جدید را ساده‌تر می‌کند.

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

قاعدهٔ ۳-۲-۱؛ چارچوبی ساده و کارآمد

شناخته‌شده‌ترین چارچوب برای طراحی بکاپ، قاعدهٔ ۳-۲-۱ است: سه نسخه از هر دادهٔ مهم نگه دارید، این نسخه‌ها روی دو نوع رسانهٔ متفاوت باشند و دست‌کم یکی بیرون از محل کسب‌وکار قرار بگیرد.

نسخهٔ بیرون از محل می‌تواند یک سرور در دیتاسنتر دیگر، یک فضای ذخیره‌سازی ابری یا یک مقصد جداگانه باشد؛ مهم این است که با سرور اصلی هم‌حساب نباشد. برخی سازمان‌ها برای کاهش ریسک منطقه‌ای، یک نسخه را در کشور دیگری هم نگه می‌دارند.

RPO و RTO؛ دو عددی که طرح را شکل می‌دهند

RPO بیشترین فاصلهٔ زمانی قابل قبول از آخرین نقطهٔ بازیابی است؛ یعنی چقدر داده می‌توانید از دست بدهید. RTO بیشترین زمان قابل قبول بین قطع سرویس و بازگشت آن است. اگر این دو عدد روشن نباشند، انتخاب ابزار و بسامد بکاپ روی حدس بنا می‌شود.

اول RPO و RTO را بنویسید، بعد ابزار را انتخاب کنید؛ نه برعکس.

بکاپ را کجا نگه داریم؟

مقصد نسخه‌ها به همان اندازه خود بکاپ مهم است. سه گزینهٔ رایج عبارت‌اند از سرور پشتیبان اختصاصی، فضای ذخیره‌سازی ابری و ذخیره‌ساز شبکه‌ای مستقل. هر کدام تعادل متفاوتی میان کنترل، هزینه و آسانی نگهداری ایجاد می‌کنند.

دو مفهوم کلیدی در انتخاب مقصد، تغییرناپذیری و جداسازی شبکه است. نسخهٔ تغییرناپذیر تا پایان بازهٔ نگهداری قابل بازنویسی یا حذف نیست و نسخهٔ جدا از شبکه حتی از سرور اصلی هم مسیر مستقیمی برای رسیدن ندارد. مدل «کشیدن»، که در آن مقصد خودش نسخه را برمی‌دارد، امنیت بیشتری از مدل «هل دادن» دارد.

ابزارها؛ هر کدام برای چه کاری

ابزارهای بکاپ رقیب یکدیگر نیستند و در بسیاری از طرح‌ها کنار هم کار می‌کنند. انتخاب درست به جنس داده، محیط سرور و سطح مهارت تیم بستگی دارد.

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

زمان‌بندی، نگهداری نسخه‌ها و هشدار شکست

بکاپ دستی دیر یا زود فراموش می‌شود؛ پس اجرای منظم آن را به زمان‌بند بسپارید. الگوی شناخته‌شدهٔ GFS نسخه‌های روزانه، هفتگی و ماهانه را کنار هم نگه می‌دارد تا هم بازیابی نزدیک ممکن باشد و هم تاریخچه‌ای دورتر باقی بماند.

به همان اندازهٔ زمان‌بندی، هشدار اهمیت دارد. اسکریپتی که بی‌صدا شکست می‌خورد از نبود بکاپ خطرناک‌تر است، چون حس امنیت کاذب می‌دهد. پایش باید تازگی آخرین نسخه را هم بسنجد و در صورت قدیمی بودن، هشدار بفرستد.

تمرین بازیابی؛ حلقه‌ای که فراموش می‌شود

ارزش بکاپ فقط زمانی مشخص می‌شود که بتوان آن را بازگرداند. پیشنهاد روشن این است که دست‌کم فصلی یک‌بار، یک بازیابی کامل را روی محیطی جدا از سرور اصلی تمرین کنید و زمان کل کار را یادداشت کنید. این عدد، RTO واقعی شماست و معمولاً با برآورد روی کاغذ فاصله دارد.

1. یک نسخهٔ تصادفی، نه لزوماً آخرین نسخه، انتخاب کنید.
2. آن را روی محیطی جدا از سرور اصلی بازیابی کنید.
3. سلامت داده را بسنجید: تعداد رکوردها، باز شدن فایل‌ها و ورود به پنل.
4. زمان و مشکلات را ثبت و مستندات بازیابی را به‌روز کنید.

جمع‌بندی

بکاپ سرور یک نرم‌افزار یا یک دستور نیست؛ زنجیره‌ای از تصمیم‌هاست. قاعدهٔ ۳-۲-۱ چارچوب را می‌دهد، RPO و RTO اعداد را تعیین می‌کنند و ابزارهایی مثل Veeam، Proxmox Backup Server و Rclone هرکدام بخشی از کار را بر عهده می‌گیرند.

اگر امروز فقط یک قدم بردارید، یک نسخه از داده‌های مهم را به فضایی بیرون از سرور بفرستید و بازگردانی‌اش را یک بار امتحان کنید. سپس زمان‌بندی خودکار، هشدار شکست و نگهداری نسخه‌های روزانه، هفتگی و ماهانه را اضافه کنید. همین چند گام، فاصلهٔ میان یک حادثهٔ مدیریت‌شده و یک بحران را می‌سازد.