بکاپ‌گیری و Disaster Recovery در سرورهای لینوکسی: راهنمای عملی
هیچ سروری از خطا در امان نیست؛ خرابی دیسک، حذف تصادفی فایل، حملهٔ باج‌افزاری یا حتی یک اشتباه انسانی ساده می‌تواند در چند ثانیه داده‌های ماه‌ها را از بین ببرد. تنها چیزی که در چنین لحظه‌ای شما را نجات می‌دهد، یک استراتژی بکاپ‌گیری درست و از پیش تست‌شده است. در این راهنما یاد می‌گیرید چطور یک برنامهٔ بکاپ‌گیری و Disaster Recovery (DR) قابل‌اتکا برای سرور لینوکسی خود بسازید.
تفاوت Backup و Disaster Recovery
این دو مفهوم مکمل هم هستند اما یکی نیستند:
- Backup (بکاپ‌گیری): فرآیند کپی کردن داده‌ها در یک مکان جدا، برای بازیابی در صورت از دست رفتن یا خراب شدن داده
- Disaster Recovery: مجموعه‌ای کامل از سیاست‌ها و رویه‌ها برای بازگرداندن کل سرویس (نه فقط داده) پس از یک حادثهٔ جدی، در کمترین زمان ممکن
قانون طلایی ۳-۲-۱
استاندارد شناخته‌شده در صنعت برای بکاپ‌گیری، قانون ۳-۲-۱ است:
| عدد | معنی |
|---|---|
| ۳ | حداقل ۳ نسخه از داده نگه‌داری شود (۱ نسخهٔ اصلی + ۲ بکاپ) |
| ۲ | بکاپ‌ها روی حداقل ۲ نوع رسانهٔ ذخیره‌سازی متفاوت باشند (مثلاً دیسک محلی + Object Storage) |
| ۱ | حداقل ۱ نسخه به‌طور کامل خارج از سایت (Off-site) نگه‌داری شود |
انواع بکاپ‌گیری
- Full Backup: کپی کامل تمام داده‌ها؛ ساده ولی حجیم و کند
- Incremental Backup: فقط تغییرات از آخرین بکاپ (کامل یا افزایشی) ذخیره می‌شود؛ سریع و کم‌حجم
- Differential Backup: تغییرات از آخرین بکاپ کامل ذخیره می‌شود؛ بین دو حالت بالا از نظر سرعت و حجم
بکاپ‌گیری از فایل‌سیستم با rsync
برای بکاپ‌گیری افزایشی از دایرکتوری‌های سرور به یک مقصد دیگر (سرور دیگر یا دیسک جداگانه):
rsync -avz --delete /var/www/ user@backup-server:/backups/www/
crontab -e
0 3 * * * rsync -avz --delete /var/www/ user@backup-server:/backups/www/ >> /var/log/backup.log 2>&1بکاپ‌گیری از پایگاه داده
بکاپ‌گیری از فایل‌های خام دیتابیس در حین اجرا خطرناک است؛ همیشه از ابزار رسمی خود دیتابیس استفاده کنید. برای MySQL/MariaDB دقیقاً همان روشی که در آموزش ایمپورت و اکسپورت دیتابیس در MySQL و MariaDB توضیح داده شده کاربرد دارد:
mysqldump -u root -p --all-databases | gzip > /backups/db/all-$(date +%F).sql.gz
find /backups/db/ -name "*.sql.gz" -mtime +7 -deleteاگر پیش از این با خرابی جدول‌های MySQL مواجه شده‌اید، مقالهٔ آموزش رفع خرابی جدول‌ها در MySQL نشان می‌دهد که چرا بکاپ منظم قبل از هر تعمیر جدول، یک قدم غیرقابل‌حذف است.
خودکارسازی و مانیتورینگ بکاپ‌ها
بکاپی که تست نشده، بکاپ نیست. حداقل موارد زیر را رعایت کنید:
- هر بکاپ باید لاگ بگیرد و در صورت شکست، هشدار (مثلاً ایمیل یا پیام) ارسال شود
- حداقل هر ۳ ماه یک‌بار، یک بازیابی آزمایشی (Restore Test) واقعی انجام دهید
- چک‌سام فایل بکاپ را پس از انتقال بررسی کنید تا از سالم بودن آن مطمئن شوید
#!/bin/bash
if ! mysqldump -u root -p"$DB_PASS" --all-databases | gzip > /backups/db/all-$(date +%F).sql.gz; then
echo "Backup failed at $(date)" | mail -s "Backup Alert" admin@example.com
fiبرنامهٔ Disaster Recovery: فراتر از بکاپ‌گیری
برای اینکه یک سرویس واقعاً در برابر حوادث بزرگ مقاوم باشد، دو معیار کلیدی را باید مشخص کنید:
- RPO (Recovery Point Objective): حداکثر میزان دادهٔ قابل‌قبول برای از دست دادن (مثلاً «حداکثر ۱ ساعت دادهٔ اخیر»)
- RTO (Recovery Time Objective): حداکثر زمان قابل‌قبول برای بازگشت سرویس به حالت عادی (مثلاً «حداکثر ۳۰ دقیقه قطعی»)
هرچه RPO و RTO کوچک‌تر باشند، هزینهٔ زیرساخت (سرورهای پشتیبان آماده، رپلیکیشن بلادرنگ و...) بالاتر می‌رود؛ بنابراین این اعداد باید متناسب با اهمیت واقعی سرویس تعیین شوند، نه بیشتر.
برای اینکه مطمئن شوید اسکریپت‌های بکاپ واقعاً هر شب اجرا می‌شوند و شکست نمی‌خورند، بهتر است اجرای موفق آن‌ها را هم مانیتور کنید. در مقالهٔ مانیتورینگ سرور لینوکس با Prometheus و Node Exporter نحوهٔ راه‌اندازی این زیرساخت را توضیح داده‌ایم.
جمع‌بندی
یک استراتژی بکاپ‌گیری خوب، ترکیبی از بکاپ منظم و خودکار (فایل‌سیستم و دیتابیس)، نگه‌داری نسخه‌ها طبق قانون ۳-۲-۱، و تست دورانی بازیابی است. بدون تعیین RPO و RTO مشخص، حتی بهترین بکاپ‌ها هم تضمینی برای بازگشت سریع سرویس در زمان بحران نیستند.