قانون ۳-۲-۱ یعنی از دادههایتان همیشه سه نسخه داشته باشید، روی دو رسانهٔ متفاوت، و یک نسخه بیرون از سروری که سایت رویش زنده است. این الگو را مرجع امنیت سایبری بریتانیا (NCSC) هم در راهنمای رسمی بکاپ داده بهعنوان حداقلِ قابلقبول برای کسبوکارها توصیه میکند و تقریباً همهٔ فاجعههای «سایتم از دست رفت» که ما در پشتیبانی دیدهایم، دقیقاً از شکستن یکی از همین سه عدد شروع شدهاند. این مقاله دربارهٔ طراحی استراتژی بکاپ است: چه چیزی، چند نسخه، کجا، با چه زمانبندی، و مهمتر از همه، با چه روالِ تست بازیابی. آموزش کلیکبهکلیک گرفتن بکاپ را جداگانه داریم و در طول متن به آنها لینک دادهایم.
بکاپ سایت باید شامل چه چیزهایی باشد؟
یک بکاپ کامل پنج جزء دارد: فایلهای سایت، دیتابیس، فایلهای پیکربندی، دادهٔ ایمیل و رکوردهای DNS. بیشتر ابزارها فقط دو مورد اول را میگیرند و سه مورد بعدی همانجایی است که روز بازیابی غافلگیر میشوید.
فایلها یعنی همهٔ مسیر وبروت، شامل پوشهٔ آپلودها که در سایتهای چندساله معمولاً سنگینترین بخش است. دیتابیس یعنی خروجی کامل و سازگار، ترجیحاً با ابزاری مثل mysqldump، و همزمان با فایلها؛ بکاپ فایلِ دوشنبه با دیتابیسِ پنجشنبه، فروشگاهی تحویل میدهد که سفارشها و انبارش با هم نمیخوانند. پیکربندی یعنی چیزهایی مثل vhostهای وبسرور، فایلهای env، کرانجابها و گواهی SSL که هیچ افزونهای آنها را نمیبیند. دادهٔ ایمیل اگر روی همان هاست است، جزء بکاپ است و اگر سرویس جداست، بکاپ خودش را میخواهد؛ برای کاربران SmarterMail راهنمای جداگانه داریم. و رکوردهای DNS را یکبار در یک فایل متنی ذخیره کنید؛ روز مهاجرت اضطراری، بازسازی zone از حافظه کار نشدنی است.
قانون ۳-۲-۱ در عمل؛ برای یک سایت واقعی چه شکلی میشود؟
ترجمهٔ عملی قانون برای یک سایت وردپرسی روی هاست اشتراکی این است: نسخهٔ اول همان سایت زنده است. نسخهٔ دوم بکاپ خودکار روی فضای هاست یا پنل است که سریعترین مسیر بازگشت برای خطاهای کوچک است. نسخهٔ سوم، بستهٔ کاملی است که به بیرون از آن سرور میرود: آبجکتاستوریج، یک VPS دیگر، یا حتی هارد اکسترنال دفتر که هفتهای یکبار وصل میشود.
چرا نسخهٔ بیرونی حیاتی است؟ چون خرابیهای واقعی سرور کل سرور را میبرند: هک شدن، خطای انسانی با دسترسی روت، یا از دست رفتن خود دیسک. بکاپی که کنار سایت روی همان دیسک نشسته، در همهٔ این سناریوها همراه سایت از بین میرود. برای همین است که دلایل بکاپگیری از هاست را هرچقدر هم بدانید، تا نسخهٔ بیرونی نداشته باشید کار تمام نشده است.
چهار سطح بکاپگیری؛ مقایسه در یک جدول
| سطح | چه چیزی میگیرد | سرعت بازیابی | مناسب چه کسی |
|---|---|---|---|
| بکاپ پنل هاست (cPanel/DirectAdmin) | فایل + دیتابیس + ایمیل همان اکانت | سریع برای بازگشت کامل اکانت | هاست اشتراکی؛ خط اول دفاع |
| افزونهٔ وردپرسی | فایل و دیتابیس در سطح اپلیکیشن | ساده برای جابهجایی و بازیابی جزئی | سایتهای کوچک و متوسط وردپرسی |
| بکاپ سرور-سطح (اسکریپت یا اسنپشات) | کل سیستم شامل پیکربندیها | وابسته به سناریو؛ کاملترین پوشش | VPS و سرور اختصاصی |
| نسخهٔ آفسایت | هر بستهٔ کامل، خارج از سرور اصلی | کندتر، ولی در بدترین روز نجات میدهد | همه؛ عدد «۱» قانون |
نکتهٔ مهم جدول: این سطحها جایگزین هم نمیشوند و ترکیبشان است که قانون را کامل میکند. آموزش عملی سطح اول را در راهنمای بکاپ از هاست و سطح سرور را در راهنمای بکاپ سرور اختصاصی نوشتهایم.
زمانبندی و نگهداری نسخهها؛ RPO به زبان ساده
یک سوال ساده زمانبندی را تعیین میکند: اگر همین الان سایت از بین برود، از دست دادن دادهٔ چند ساعت برایتان قابلتحمل است؟ جواب این سوال در ادبیات فنی RPO نام دارد. برای فروشگاهی که روزی دهها سفارش دارد، جواب معمولاً «چند ساعت» است و یعنی دیتابیس باید چند بار در روز بکاپ شود. برای سایت شرکتیای که ماهی چند بار بهروزرسانی میشود، بکاپ روزانه یا حتی هفتگی کافی است.
نگهداری نسخهها هم قاعدهٔ خودش را دارد: فقط آخرین نسخه را نگه ندارید. آلودگی و خرابکاری معمولاً با تأخیر کشف میشود؛ اگر بدافزار سه هفته پیش وارد شده باشد و شما فقط بکاپ دیروز را داشته باشید، بکاپتان هم آلوده است. الگوی مرسوم و کمهزینه: هفت نسخهٔ روزانه، چهار نسخهٔ هفتگی، سه نسخهٔ ماهانه؛ نسخههای قدیمیتر خودکار حذف شوند تا دیسک پر نشود. پر شدن دیسک با بکاپهای فراموششده، خودش یکی از خرابیهای پرتکراری است که در راهنمای مانیتورینگ سرور دربارهاش نوشتهایم.
تست بازیابی؛ فرقِ بکاپ با امید
بکاپی که هرگز بازیابی نشده، فقط یک فایل فشرده است که به آن امید بستهاید. الگوی تکراری تیکتهای بحرانی پشتیبانی همین است: بکاپ خودکار ماهها با موفقیت اجرا شده، ایمیل «Backup completed» هم آمده، و روز حادثه معلوم میشود آرشیو، پوشهٔ آپلودها را بهخاطر محدودیت زمان اجرای PHP نصفه بسته یا اصلاً دیتابیس داخلش نبوده. نتیجهٔ بازیابی هم صفحهٔ سفید و پیام آشنای Error establishing a database connection است؛ درست در بدترین لحظهٔ ممکن.
روال پیشنهادی ما ماهانه است و یک ساعت هم وقت نمیگیرد: آخرین بستهٔ بکاپ را بردارید، روی یک فضای تست (سابدامنه، لوکال یا یک VPS ارزان موقت) باز کنید و سه چیز را چک کنید: صفحهٔ اصلی و چند صفحهٔ داخلی بالا میآید، ورود به پنل مدیریت کار میکند، و تاریخ آخرین رکوردها (آخرین سفارش یا آخرین مطلب) با انتظار شما میخواند. همین سه چک، اکثر بکاپهای ناقص را لو میدهد. اگر مسیر دستی را میروید، اسکلت کار روی لینوکس دو خط بیشتر ندارد:
mysqldump -u dbuser -p dbname | gzip > db-$(date +%F).sql.gz
tar -czf files-$(date +%F).tar.gz /home/user/public_htmlو خروجی هر دو باید بعد از ساخت، با یک باز کردن آزمایشی چک شود؛ آرشیو خراب هم دقیقاً مثل آرشیو ناقص، روز حادثه خودش را نشان میدهد.
اشتباهات پرتکرار در بکاپگیری
- بکاپ روی همان سرور: پوشهٔ backups کنار وبروت، در هک و خرابی دیسک همراه سایت میسوزد. عدد «۱» قانون را جدی بگیرید.
- اعتماد مطلق به بکاپ هاست: بکاپ دورهای میزبان، مکمل خوبی است ولی مسئولیت نهایی داده با شماست؛ بازه، عمق نگهداری و روال بازیابیاش را بپرسید و نسخهٔ مستقل خودتان را هم داشته باشید.
- فایل بدون دیتابیس، یا برعکس: نصف سایت عملاً هیچ سایتی است. هر بسته باید جفتِ همزمانِ فایل و دیتابیس باشد.
- بکاپ دستیِ «هر وقت یادم بود»: فاصلهٔ دو بکاپ دستی معمولاً درست همانجایی است که حادثه میافتد. زمانبندی خودکار با کران یا زمانبند پنل، قابل مذاکره نیست.
- تست نکردن تا روز حادثه: اولین بازیابی واقعیتان نباید در شرایط بحران باشد. تمرین ماهانه، هم بکاپ را ثابت میکند هم سرعت عمل شما را بالا میبرد.
- فراموش کردن بکاپ قبل از تغییرات بزرگ: قبل از بهروزرسانی هسته و افزونهها، تغییر قالب یا انتقال هاست، یک بکاپ کامل دستی بگیرید؛ ارزانترین بیمهٔ عمرتان است.
استراتژی بکاپ در هر سطح میزبانی
روی هاست اشتراکی، ترکیب برنده ساده است: بکاپ خودکار پنل بهعلاوهٔ یک افزونه یا اسکریپت که بستهٔ کامل را زمانبندیشده به فضای بیرونی بفرستد. اگر هاستتان محدودیت فضا دارد، نسخههای بیرونی را بیشتر و نسخههای روی هاست را کمتر نگه دارید؛ برای انتخاب پلنی که فضای کافی برای بکاپ محلی داشته باشد، صفحهٔ هاست را ببینید.
روی سرور مجازی، مسئولیت کامل با شماست و ابزار کامل هم در اختیارتان است: اسکریپت شبانه با mysqldump و tar یا ابزارهایی مثل restic که رمزنگاری و نسخهبندی را هم حل میکنند، بهعلاوهٔ اسنپشات دورهای در سطح مجازیساز. اسنپشات بهتنهایی کافی به حساب نمیآید؛ روی همان زیرساخت ذخیره میشود و سناریوی از دست رفتن میزبان را پوشش نمیدهد. روی سرور اختصاصی همین منطق با یک لایهٔ اضافه تکرار میشود: RAID را هم بکاپ حساب نکنید؛ RAID خرابی دیسک را جبران میکند و حذف اشتباه و هک و آتشسوزی را عیناً روی هر دو دیسک کپی میکند. جزئیات عملی این سطح را در راهنمای بکاپ سرور اختصاصی نوشتهایم.
مستند رسمی WordPress.org دربارهٔ بکاپ هم همین سلسلهمراتب را توصیه میکند: بکاپ فایل و دیتابیس با هم، چند نسخه، و ذخیره در جایی جدا از سرور اصلی.
نقشهٔ پیادهسازی؛ از امروز تا روال پایدار
استراتژی وقتی واقعی میشود که به تقویم تبدیل شود. پیشنهاد ما برای سایتی که امروز هیچ نظم بکاپی ندارد:
- همین امروز: یک بکاپ کامل دستی بگیرید (فایل + دیتابیس با هم) و روی سیستم خودتان دانلود کنید. از این لحظه، بدترین سناریو دیگر «همهچیز از دست رفت» نخواهد بود.
- همین هفته: زمانبندی خودکار را راه بیندازید و مقصد بیرونی را وصل کنید؛ با کرانجاب، زمانبند پنل، یا افزونهای که مستقیم به فضای ابری میفرستد. رکوردهای DNS را هم همین هفته در یک فایل ذخیره کنید.
- همین ماه: اولین تست بازیابی را روی فضای تست انجام بدهید و زمانش را یادداشت کنید. اولین تست تقریباً همیشه یک نقص پیدا میکند؛ بهتر که الان پیدایش کنید.
- هر ماه: حلقهٔ سهچکی بخش تست را تکرار کنید: تاریخ آخرین بسته، روند حجم، یک بازیابی آزمایشی.
- هر فصل: سیاست نگهداری نسخهها را با رشد سایت بازبینی کنید؛ سایتی که حجم آپلودش دو برابر شده، فضای بکاپ و مدت انتقالش هم عوض شده است.
سوالات متداول دربارهٔ استراتژی بکاپ سایت
هر چند وقت یکبار باید بکاپ بگیرم؟
به ضرر قابلتحملتان برگردید: فروشگاه پرسفارش، دیتابیس را چند بار در روز و فایلها را روزانه؛ سایت شرکتی کمتغییر، روزانه یا هفتگی. و مستقل از زمانبندی، قبل از هر تغییر بزرگ یک بکاپ دستی کامل بگیرید.
افزونهٔ بکاپ وردپرس کافی است؟
برای سایت کوچک، به شرط ارسال خودکار نسخه به بیرون از هاست و تست ماهانهٔ بازیابی، بله. کافی بودنش از جایی به بعد تمام میشود که حجم آپلودها از محدودیتهای اجرای PHP بزرگتر شود یا پیکربندیهای خارج از وردپرس (ایمیل، کران، SSL) مهم شوند؛ آنجا بکاپ پنل یا سرور-سطح لازم است.
اسنپشات سرور مجازی همان بکاپ است؟
خیر؛ اسنپشات تصویری از کل دیسک در یک لحظه است و برای برگشت سریع بعد از یک تغییر خراب عالی است، ولی روی همان زیرساخت ذخیره میشود و معمولاً عمق نگهداری کوتاهی دارد. جای بستهٔ بکاپ مستقل و بیرونی را نمیگیرد؛ در استراتژی درست، اسنپشات ابزار برگشت سریع است و بکاپ ۳-۲-۱ بیمهٔ اصلی.
بکاپ خود هاستینگ کافی است؟
بکاپ دورهای میزبان، لایهٔ ارزشمندی است ولی سه سوال را باید جواب بدهد: چند وقت یکبار گرفته میشود، چند نسخه نگه داشته میشود، و بازیابی چقدر طول میکشد. هر جوابی که گرفتید، باز هم نسخهٔ بیرونی خودتان را داشته باشید؛ قانون ۳-۲-۱ با «بکاپ داریم»ِ دیگران کامل نمیشود.
بکاپ را کجا نگه دارم که امن باشد؟
جایی بیرون از سرور اصلی و ترجیحاً با دسترسیِ جدا: آبجکتاستوریج، سرور دوم در دیتاسنتر دیگر، یا دیسک آفلاین دفتر. رمزنگاری بستهها قبل از ارسال هم برای دادههای مشتریان توصیهٔ جدی ماست؛ بکاپ، همان دادهٔ حساس سایت است که حالا جای دیگری هم نشسته.
چطور مطمئن شوم بکاپ خودکار واقعاً اجرا میشود؟
سه علامت حیاتی را ماهانه چک کنید: تاریخ آخرین فایل بکاپ، روند حجم بستهها (افت ناگهانی حجم یعنی چیزی جا افتاده)، و یک تست بازیابی. اگر مانیتورینگ دارید، هشدار «بکاپ امروز ساخته نشد» را هم کنار هشدارهای دیسک و آپتایم بگذارید.
برای بازگرداندن سایت از بکاپ چقدر باید وقت بگذارم؟
اگر تمرین کرده باشید، بازیابی یک سایت وردپرسی معمولی از بستهٔ کامل، در حد یک تا دو ساعت است: باز کردن آرشیو، ایمپورت دیتابیس، اصلاح مسیرها و آدرسها، و چک نهایی. بدون تمرین، همین کار در شرایط استرس چند برابر طول میکشد و خطای دستی هم اضافه میشود؛ ارزش واقعی تست ماهانه همینجاست.
