بکاپ گیری از سرور: قانون 3-2-1، انواع بکاپ و تست بازیابی

بکاپ گیری از سرور فقط روشن کردن یک ابزار نیست؛ باید معلوم باشد چه چیزی، هر چند وقت، کجا و با چه روشی ذخیره می شود و اگر لازم شد، بازیابی چقدر طول می کشد. بیشتر شرکت هایی که داده از دست می دهند بکاپ داشتند. مشکل این بود که بکاپ روی همان سرور بود، ناقص بود، یا هیچ وقت بازیابی نشده بود تا معلوم شود کار می کند.

قانون 3-2-1

ساده ترین قاعده برای ساختن بکاپ قابل اعتماد:

• 3 نسخه از داده: خود داده اصلی و دو بکاپ.
• 2 نوع رسانه مختلف، مثلاً دیسک سرور و یک NAS، یا دیسک و فضای ابری.
• 1 نسخه بیرون از محل سرور، تا آتش سوزی، سرقت یا خرابی دیتاسنتر همه چیز را با هم از بین نبرد.

در برابر باج افزار یک شرط دیگر هم لازم است: دست کم یک نسخه نباید با حسابی که روی شبکه آلوده در دسترس است قابل تغییر یا حذف باشد. به این نسخه بکاپ غیرقابل تغییر (immutable) یا آفلاین می گویند. اگر بکاپ شما روی پوشه اشتراکی باشد که سرور با حساب ادمین آن را می بیند، باج افزار آن را هم رمز می کند. به همین خاطر گاهی به قانون 3-2-1-1-0 می رسند: یک نسخه آفلاین یا immutable و صفر خطا در تست بازیابی. مسیرهای ورود باج افزار را در باج افزار چیست توضیح داده ایم.

RPO و RTO

پیش از انتخاب ابزار، دو عدد را برای هر سرویس تعیین کنید:

• RPO (Recovery Point Objective) بیشترین مقدار داده ای است که می توانید از دست بدهید. اگر RPO دیتابیس فروشگاه 1 ساعت است، باید حداقل ساعتی یک بار از آن بکاپ بگیرید.
• RTO (Recovery Time Objective) بیشترین زمانی است که سرویس می تواند خاموش بماند. اگر RTO دو ساعت است، بازیابی کامل باید در این بازه ممکن باشد.

این دو عدد برنامه بکاپ را تعیین می کنند. فایل سرور که روزی یک بار عوض می شود با بکاپ شبانه کافی است، ولی دیتابیس سفارش ها برای RPO یک ساعت یا کمتر به بکاپ مکرر یا replication نیاز دارد.

انواع بکاپ

الگوی معمول این است که هفته ای یک بکاپ کامل بگیرید و بقیه روزها افزایشی. چند ابزار (مثل Veeam و restic) خودشان زنجیره را مدیریت می کنند و کاربر کمتر درگیر این تفاوت ها می شود. وجود Snapshot هم جای بکاپ را نمی گیرد، چون با خرابی ذخیره ساز هر دو با هم می روند.

چه چیزهایی را باید بکاپ گرفت

• داده برنامه: فایل های سایت، آپلودها، پوشه های اشتراکی
• دیتابیس ها، که کپی ساده فایل شان معمولاً ناسازگار است
• پیکربندی سرور، مثل فایل های nginx، تنظیمات فایروال، کرون جاب ها و گواهی ها
• برای ویندوز: System State و دامین کنترلر
• ماشین های مجازی به صورت کامل یا فقط داده درونشان
• کلیدها و رمزهای بکاپ، جدا از خود بکاپ

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

بکاپ دیتابیس در لینوکس

کپی مستقیم فایل های دیتابیس وقتی سرویس روشن است معمولاً خراب از آب در می آید. برای MySQL و MariaDB با جداول InnoDB، بکاپ سازگار این طور گرفته می شود:

mysqldump --single-transaction --routines --all-databases | gzip > /backup/db-$(date +%F).sql.gz

گزینه --single-transaction بدون قفل کردن جداول، تصویر سازگاری از داده می گیرد. برای PostgreSQL از pg_dump یا pg_basebackup استفاده کنید.

بکاپ فایل با restic یا rsync

rsync فایل ها را کپی می کند ولی نسخه قدیمی را نگه نمی دارد؛ اگر فایلی خراب یا رمز شود، نسخه خراب جایش را می گیرد. ابزارهایی مثل restic و borg نسخه های قبلی را هم نگه می دارند و داده را رمز و فشرده می کنند:

restic -r sftp:backup@backup-host:/srv/restic init
restic -r sftp:backup@backup-host:/srv/restic backup /var/www /etc
restic -r sftp:backup@backup-host:/srv/restic forget --keep-daily 7 --keep-weekly 4 --prune

برای سرور ویندوز و ماشین های مجازی VMware و Hyper-V، Veeam گزینه رایجی است. بکاپ برنامه هایی مثل SQL Server باید application-aware باشد، یعنی با سرویس VSS هماهنگ شود تا داده در لحظه بکاپ سازگار بماند.

چند نسخه را تا کی نگه داریم

نگه داشتن همه بکاپ ها برای همیشه فضا را پر می کند، و نگه نداشتن نسخه های قدیمی یعنی اگر خرابی دیر کشف شود چیزی برای برگشتن نمانده است. الگوی رایج، پدربزرگ، پدر، پسر (GFS) است که از هر دوره یک نسخه نگه می دارد. یک نمونه:

این اعداد فقط نمونه اند. اگر بدافزار یا خرابی تدریجی داده تا یک ماه نامحسوس بماند، نسخه روزانه 7 روز اخیر کمکی نمی کند. مدت نگه داری را به نوع داده و مقررات سازمان هم وصل کنید. بعضی داده ها (مثل اسناد مالی) را قانون یا قرارداد مدتی نگه می دارد.

چقدر فضا برای بکاپ لازم است

یک برآورد ساده: حجم یک بکاپ کامل، به اضافه حجم تغییرات روزانه ضرب در تعداد روزهای نگه داری. مثلاً داده 2 ترابایتی که روزی حدود 3 درصدش تغییر می کند، روزی نزدیک 60 گیگابایت بکاپ افزایشی می سازد. برای نگه داری یک ماه، حدود 1.8 ترابایت فضای افزایشی و بعلاوه بکاپ کامل لازم است. ابزارهایی که deduplication و فشرده سازی دارند (مثل restic و Veeam) معمولاً فضای کمتری از این برآورد می گیرند، ولی حساب را با بدترین حالت شروع کنید.

پهنای باند هم مهم است. ارسال 60 گیگابایت در روز به مقصد خارجی با اینترنت 20 مگابیتی کار ساعت ها طول می کشد. بکاپ بیرونی را شبانه و با محدودیت پهنای باند تنظیم کنید تا کار روزانه کارمندان را کند نکند.

یک اسکریپت ساده با هشدار شکست

برای سرور لینوکسی که از ابزار گران قیمت استفاده نمی کند، یک اسکریپت کوتاه همراه کرون کافی است. نکته اصلی آن است که اگر یکی از مراحل شکست خورد، ایمیل بفرستد:

#!/bin/bash
set -euo pipefail
trap 'echo "backup failed on $(hostname)" | mail -s "BACKUP FAILED" ops@example.com' ERR

mysqldump --single-transaction --routines --all-databases | gzip > /backup/db-$(date +%F).sql.gz
restic -r sftp:backup@backup-host:/srv/restic backup /var/www /etc /backup
restic -r sftp:backup@backup-host:/srv/restic forget --keep-daily 7 --keep-weekly 4 --prune
find /backup -name "db-*.sql.gz" -mtime +7 -delete

و در crontab:

30 2 * * * /usr/local/bin/backup.sh

رمز مخزن restic را با متغیر RESTIC_PASSWORD_FILE بدهید و فایل آن را فقط برای کاربر اجراکننده قابل خواندن کنید. اگر اسکریپت پیغام موفقیت را به مانیتورینگ هم بفرستد (مثلاً با یک curl به یک سرویس heartbeat)، نرسیدن پیام نشانه شکست است حتی اگر خود سرور خاموش باشد و ایمیل خطا نفرستد.

تست بازیابی

بکاپ بدون تست بازیابی فقط یک فرض است. برنامه ای برای تست داشته باشید:

• ماهی یک بار، چند فایل تصادفی را از بکاپ بازیابی کنید و باز شدنشان را چک کنید.
• هر سه تا شش ماه، یک سرویس کامل را روی سرور آزمایشی بازیابی کنید و زمان واقعی را اندازه بگیرید. این زمان را با RTO مقایسه کنید.
• بعد از هر تغییر بزرگ، مثل ارتقای سیستم عامل یا جابجایی دیتابیس، بکاپ را دوباره تست کنید.
• گزارش اجرای بکاپ را مانیتور کنید. بکاپی که شب ها شکست می خورد و کسی خبردار نمی شود، همان وضعیت «بکاپ نداریم» است. هشدار شکست بکاپ را به سیستم مانیتورینگ وصل کنید.

یک بازیابی کامل در عمل

برای اینکه RTO را واقعاً بدانید، مراحل بازیابی را روی سرور آزمایشی اجرا کنید و زمان بگیرید. در سناریوی بالا که فایل ها با restic و دیتابیس با mysqldump گرفته شده اند، بازیابی این است:

restic -r sftp:backup@backup-host:/srv/restic snapshots
restic -r sftp:backup@backup-host:/srv/restic restore latest --target /restore
gunzip < /restore/backup/db-2026-10-03.sql.gz | mysql

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

در ویندوز سرور، بکاپ System State دامین کنترلر، Windows Server Backup و Veeam Agent جواب می دهند. بازیابی ماشین های مجازی با Veeam هم این امکان را دارد که ماشین را مستقیم از فایل بکاپ روشن کنید، تا مدتی که دیسک اصلی دوباره ساخته می شود، سرویس برقرار بماند.

اگر ماشین های شما مجازی اند، ابزار Veeam مراحل نصب و ساخت job را دارد، و طرح کلی بازیابی بعد از حادثه در Disaster Recovery چیست آمده.

مقصد بکاپ را کجا بگذاریم

NAS داخل شبکه سریع ترین بازیابی را دارد ولی خودش در معرض همان حمله است. سرور بکاپ جدا با حساب مخصوص، دیتاسنتر دیگر یا فضای ابری برای نسخه بیرونی مناسب اند. اگر دیسک ها را در RAID گذاشته اید، یادتان باشد RAID فقط از خرابی دیسک محافظت می کند، نه از حذف اشتباهی، خرابی دیتابیس یا باج افزار. درباره انتخاب ذخیره ساز در فرق NAS و SAN نوشته ایم.

بکاپ ماشین های مجازی در نصب Proxmox آمده است.

منابع و مستندات رسمی

• مستندات رسمی PostgreSQL درباره بکاپ و بازیابی
• مستندات رسمی restic
• راهنمای NIST برای برنامه ریزی تداوم و بازیابی (SP 800-34)

اگر فقط می خواهید بدانید بکاپ فعلی شما در روز حادثه واقعاً کار می کند یا نه، بررسی رایگان بکاپ همین را می سنجد. برنامه کامل بکاپ با Veeam یا restic، نسخه غیرقابل تغییر و تست بازیابی منظم هم بخشی از بکاپ گیری سازمانی و Disaster Recovery است.

نحوه تهیه مقاله ها