فهرست راهنما
محدوده و ابزار تمرین
Bash، GNU tar، sha256sum و OpenSSH روی Ubuntu یا مشتری Linux/WSL لازماند. یک ترمینال سرور و یک ترمینال روی رایانه جدا را باز نگه دارید تا متغیرها باقی بمانند. پس از هر خطای فرمان توقف کنید.
این آرشیو نمونه، بکاپ کل ماشین، پایگاه داده یا همه وابستگیهای سایت نیست. مسیرها، فایلهای اضافه، DNS، گواهی و نیاز بازیابی واقعی را جدا فهرست کنید.
دو فایل آزمایشی روی سرور بسازید
فرمان زیر پوشه خصوصی و فایلهای تمرین را میسازد. تنظیم Nginx داخل آن فقط یک فایل برای آرشیو است و فعال نمیشود.
umask 077
backup_lab=$(mktemp -d "$HOME/ubuntu-vps-backup.XXXXXX")
mkdir -p "$backup_lab/payload/site" "$backup_lab/payload/nginx" "$backup_lab/export"
printf '%s\n' '<!doctype html><html lang="en"><title>Restore drill</title><h1>Recovered static page</h1></html>' > "$backup_lab/payload/site/index.html"
printf '%s\n' 'server {' ' listen 8080;' ' server_name example.test;' ' root /var/www/first-site;' '}' > "$backup_lab/payload/nginx/first-site.conf"
printf 'Practice directory: %s\n' "$backup_lab"اگر تمرین را با نمونهها انجام میدهید بخش بعد را رد کنید. برای استفاده از دو فایل واقعی راهنمای سایت HTTPS، فقط کپیهای داخل پوشه تمرین را جایگزین کنید. منبع باید خواندنی، فاقد راز و متعلق به یک انتشار ثابت باشد؛ هنگام جمعآوری انتشار تازه انجام ندهید.
install -m 600 /var/www/first-site/index.html "$backup_lab/payload/site/index.html"
install -m 600 /etc/nginx/sites-available/first-site "$backup_lab/payload/nginx/first-site.conf"این فرمانها فایل اصلی را تغییر نمیدهند. کلید خصوصی گواهی یا پوشههای کامل سیستم را به این نمونه اضافه نکنید.
آرشیو و دو مرحله بررسی صحت
روی سرور، فایلهای نمونه را در طول این مرحله ثابت نگه دارید. ابتدا فهرست هش فایلها، سپس آرشیو و هش خود آرشیو ساخته میشود.
(
cd "$backup_lab/payload" &&
sha256sum site/index.html nginx/first-site.conf > SHA256SUMS
)
tar -czf "$backup_lab/export/static-site.tar.gz" -C "$backup_lab/payload" site nginx SHA256SUMS
(
cd "$backup_lab/export" &&
sha256sum static-site.tar.gz > static-site.tar.gz.sha256
)
tar -tzf "$backup_lab/export/static-site.tar.gz"
printf 'Server export directory: %s\n' "$backup_lab/export"فهرست باید شامل site، nginx، دو فایل انتخابشده و SHA256SUMS باشد. هش آرشیو تغییر حین انتقال و فهرست داخلی تغییر فایل استخراجشده را آشکار میکند. اگر کسی هم داده و هم هش مورد انتظار را عوض کند، این روش بهتنهایی اصالت نسخه را ثابت نمیکند.
نسخه را روی رایانه جدا دریافت کنید
فرمان زیر روی رایانه شما اجرا میشود. remote_backup را برابر مسیر دقیق export چاپشده روی سرور بگذارید. REPLACE نام واقعی پوشه تولیدشده نیست؛ حساب، آدرس و نام کلید را هم جایگزین کنید.
umask 077
recovery_dir=$(mktemp -d "$HOME/ubuntu-vps-restore.XXXXXX")
remote_backup=/home/deploy/ubuntu-vps-backup.REPLACE/export
scp -i ~/.ssh/ubuntu_vps "deploy@203.0.113.10:$remote_backup/static-site.tar.gz" "$recovery_dir/"
scp -i ~/.ssh/ubuntu_vps "deploy@203.0.113.10:$remote_backup/static-site.tar.gz.sha256" "$recovery_dir/"اثر انگشت SSH را پیش از نخستین اتصال از مسیر معتبر تأیید کنید. در صورت خطای اتصال، راهنمای SSH را ببینید. SCP انتقال را محافظت میکند، اما tar.gz رمزگذاریشده نیست؛ امنیت حساب و فضای مقصد را هم تأمین کنید. پوشه دوم روی همان VPS نسخه خارج از سرور محسوب نمیشود.
فقط در پوشه تازه و خالی بازیابی کنید
روی رایانه، نخست هش آرشیو را بررسی کنید. تنها پس از OK ادامه دهید؛ هش مورد انتظار را برای پنهان کردن شکست عوض نکنید.
(
cd "$recovery_dir" &&
sha256sum -c static-site.tar.gz.sha256
)
tar -tzf "$recovery_dir/static-site.tar.gz"آرشیو مورد اعتماد را در پوشه تازه باز کنید. مقصد را / قرار ندهید و از sudo استفاده نکنید. گزینه keep-old-files از جایگزینی فایل موجود و no-same-owner از بازگرداندن مالکیت آرشیو جلوگیری میکند.
restore_dir=$(mktemp -d "$recovery_dir/restored.XXXXXX")
tar -xzf "$recovery_dir/static-site.tar.gz" -C "$restore_dir" --keep-old-files --no-same-owner
(
cd "$restore_dir" &&
sha256sum -c SHA256SUMS
)
cat "$restore_dir/site/index.html"برای هر دو فایل باید OK ببینید و عنوان صفحه بازیابیشده را بخوانید. این نتیجه صحت همان فایلهاست؛ مالکیت تولید، ACL یا فعال بودن سرویس را ثابت نمیکند.
بازیابی فایل با بازگشت سرویس فرق دارد
تنظیم استخراجشده هنوز فایل غیرفعال است. روی ماشین جایگزین جدا، مسیرها، ماژولها، مجوزها و گواهی را بررسی و پیکربندی کامل Nginx را آزمایش کنید؛ سپس HTTP/HTTPS بیرونی را بسنجید. بررسی تنظیمات سرور اصلی، کپی بازیابیشده را آزمایش نمیکند.
کلیدهای خصوصی TLS عمداً در این نمونه نیستند؛ صدور مجدد گواهی یا بکاپ محافظتشده جداگانه لازم است. فایلهای پایگاه داده فعال را با این دستور tar کپی نکنید؛ از روش سازگار پشتیبانگیری همان پایگاه داده استفاده کنید.
نتیجه و هدف بازیابی را ثبت کنید
RPO زمان قابل قبول از دست رفتن داده و RTO زمان هدف برای بازگشت سرویس است. مثلاً 24 ساعت و 60 دقیقه میتوانند هدف فرضی کسبوکار باشند؛ نتیجه اندازهگیری این تمرین نیستند. زمان ساخت ماشین، دسترسی، تنظیمات، گواهی و DNS را هم در آزمایش کامل حساب کنید.
برای دیدن همه ستونها، جدول را بهصورت افقی جابهجا کنید.
| مورد ثبت | هدف |
|---|---|
| زمان بکاپ و شناسه انتشار | نسخه قابل بازیابی |
| مقصد مستقل و مدت نگهداری | محل بقا و تعداد نقاط بازیابی |
| نتیجه هش و فایلهای مفقود | صحت نسخه و شکافهای فهرست |
| شروع و پایان بازیابی | زمان واقعی مراحل تعریفشده |
| بررسی HTTPS روی جایگزین | بازگشت سرویس از نگاه بیرونی |
چند نقطه بازیابی مناسب نگه دارید و شکست کارهای بکاپ را پایش کنید. شرایط نگهداری و کمک به بازیابی را در انتخاب میزبانی هم لحاظ کنید.
فرمانهای این تمرین از نسخه انگلیسی گرفته شدهاند. آزمایش فایلهای نمونه، جای آزمون انتقال SSH، گواهی، فعالسازی Nginx یا بازیابی کل برنامه را نمیگیرد.
پرسشهای رایج
برای آزمایش باید سایت اصلی را حذف کنم؟
خیر. پوشه خالی و محیط جایگزین، امکان بررسی نسخه را بدون ایجاد قطعی میدهند.
موفقیت SHA-256 یعنی همه سایت بکاپ دارد؟
فقط فایلهای ثبتشده را بررسی میکند. فایل، راز، پایگاه داده یا تنظیم DNS جاافتاده را کشف نمیکند.
اسنپشات کافی است؟
به محل نگهداری، وابستگی و روش بازیابی بستگی دارد. وجود اسنپشات بهتنهایی قابل بازیابی بودن فایلها در میزبان جایگزین را ثابت نمیکند.