بکاپ سایت: چه چیزی، هر چند وقت، و کجا نگه داریم
بکاپ درست یعنی نسخهای کامل از فایلها و دیتابیس سایت که هر دو از یک لحظه گرفته شدهاند، بیرون از سرور اصلی نگهداری میشود، و دستکم یک بار بازگردانیاش را آزمایش کردهاید. اگر یکی از این سه شرط نباشد، چیزی که دارید یک فایل است، نه یک بکاپ. کسانی که سایتشان را از دست میدهند دو دستهاند: دستهٔ اول اصلاً بکاپ نداشتند، و دستهٔ دوم — که پرشمارتر است — بکاپ داشتند و در لحظهٔ لازم به کارشان نیامد.
این راهنما بر پایهٔ چیزی نوشته شده که در پلنهای واقعی بازار ایران دیده میشود: ۱۱۲۸ پلن هاست از ۳۳ شرکت که در همین سایت رصد میشوند. آخرین بررسی قیمت و مشخصات: ۱۸ شهریور ۱۴۰۵.
بکاپ سایت دقیقاً شامل چه چیزهایی است
یک سایت پویا از دو تکهٔ کاملاً جدا ساخته شده و بکاپ گرفتن از فقط یکی از آنها عملاً بیفایده است.
فایلها. هستهٔ سیستم مدیریت محتوا، قالب، افزونهها، تصاویر و هر چیزی که آپلود کردهاید، بهعلاوهٔ فایلهای تنظیمات مثل wp-config.php و .htaccess. اینها معمولاً داخل پوشهٔ public_html جمعاند.
دیتابیس. نوشتهها، صفحهها، کاربران، سفارشها، دیدگاهها و تنظیمات همهٔ افزونهها. متن سایت شما در فایلها نیست؛ در دیتابیس است. اگر فقط از public_html بکاپ بگیرید، سایتی را برمیگردانید که ظاهرش هست و محتوایش نیست.
دو چیز هم معمولاً از قلم میافتد چون در بکاپ عادی نمیآیند: صندوقهای ایمیل، اگر ایمیل سازمانیتان روی همان هاست است، و کرونجابها که تعریفشان در کنترلپنل ذخیره شده و در پوشهٔ سایت اثری از آنها نیست. یک بار عکس صفحهٔ کرونجابها را بگیرید و کنار بکاپ نگه دارید؛ کار پنج دقیقهای است و روز بازگردانی نجاتتان میدهد.
فایل و دیتابیس باید از یک لحظه باشند
این نکتهای است که تقریباً هیچجا نوشته نمیشود و بیشترین بازگردانیهای خراب از آن میآید. فرض کنید فایلها را ساعت ده صبح میگیرید و دیتابیس را ساعت دو بعدازظهر. بین این چهار ساعت، مشتری سفارشی ثبت کرده که ردش در دیتابیس هست ولی فایل پیوستش در بکاپ فایلها نیست. یا افزونهای بهروزرسانی شده که ساختار جدولش عوض شده، در حالی که کد قدیمی افزونه در بکاپ فایلها مانده. نتیجه سایتی است که بالا میآید ولی درست کار نمیکند، و اشکالش هم دیر پیدا میشود.
راهحل ساده است: هر دو را در یک عملیات بگیرید. بکاپ کامل کنترلپنل همین کار را میکند. اگر دستی میگیرید، فاصله را به چند دقیقه برسانید و در آن فاصله سایت را در حالت تعمیر بگذارید.
دو اشتباهی که بیشترین ضرر را میزند
اشتباه اول: «میزبان که خودش بکاپ میگیرد»
بکاپ میزبان برای میزبان است، نه برای شما. شرکتها از کل سرور بکاپ میگیرند تا اگر سختافزار خراب شد بتوانند سرویس را برگردانند. اینکه شما هم از آن سود ببرید یک اثر جانبی است، نه تعهد. در شرایط استفادهٔ شرکتهای میزبانی — چه ایرانی، چه خارجی — معمولاً جملهای هست که میگوید مسئولیت نهایی داده با مشترک است. بخوانیدش.
سه حالت واقعی که بکاپ میزبان به دردتان نمیخورد: حسابتان به دلیل تسویهنشدن یا نقض قوانین معلق و بعد حذف شده و بکاپش هم با آن رفته؛ فاصلهٔ بکاپ هفتگی است و شما ده روز بعد فهمیدهاید سایت خراب شده، پس تنها نسخهٔ موجود هم خراب است؛ یا بازگردانی فقط با تیکت انجام میشود و شما جمعه شب گرفتار شدهاید.
اشتباه دوم: تنها نسخه روی همان سرور
پوشهٔ backups کنار خود سایت، روی همان دیسک، بکاپ نیست؛ نسخهٔ دوم است. اگر دیسک بسوزد، حساب حذف شود، یا کسی به هاست نفوذ کند، هر دو با هم میروند. بدتر اینکه در هاست اشتراکی این فایلها از سهمیهٔ فضای خودتان کم میشوند و بعد از چند ماه ناگهان میبینید فضا پر شده و سایت خطای نوشتن میدهد.
قاعدهٔ ذهنی ساده: بکاپی که با یک اتفاق واحد همراه اصلش از بین میرود، بکاپ نیست.
قاعدهٔ ۳-۲-۱ به زبان ساده
این قاعده در دنیای نگهداری داده قدیمی و جاافتاده است و برای یک سایت شخصی هم به همان اندازه معنا دارد: سه نسخه از داده، روی دو نوع رسانهٔ متفاوت، که یکی از آنها جای دیگری باشد.
ترجمهٔ عملیاش برای یک سایت ایرانی این است:
- نسخهٔ اول: خود سایت روی هاست. این اصل است، نه بکاپ.
- نسخهٔ دوم: بکاپ خودکاری که میزبان یا افزونه روی همان فضا یا فضای بکاپ شرکت میسازد. برای بازگشت سریع از یک اشتباه کوچک عالی است.
- نسخهٔ سوم: یک کپی که از سرور بیرون میآید — روی کامپیوتر خودتان، هارد اکسترنال، فضای ابری، یا یک سرور مجازی ایران ارزان که فقط نقش انبار را دارد.
یک نکتهٔ ریز که زیاد اشتباه گرفته میشود: «سرور دیگری از همان شرکت در همان دیتاسنتر» نسخهٔ بیرونی حساب نمیشود. اگر مشکل در سطح حساب کاربری یا دیتاسنتر باشد، هر دو با هم از دسترس خارج میشوند.
بکاپ میزبان، بکاپ دستی، یا افزونه؟
هیچکدام جای آن دو تای دیگر را نمیگیرد. ترکیب درست معمولاً «بکاپ خودکار میزبان + یک نسخهٔ ماهانهٔ دستی که خودتان دانلود میکنید» است.
| روش | کنترل با کیست | نقطهٔ قوت | نقطهٔ ضعف |
|---|---|---|---|
| بکاپ خودکار میزبان | شرکت | بدون زحمت، معمولاً کل حساب | فاصله و مدت نگهداری را شما تعیین نمیکنید |
| بکاپ دستی از کنترلپنل | شما | نسخهٔ واقعاً بیرونی، قابل آرشیو | یادتان میرود؛ باید در تقویم بگذارید |
| افزونهٔ بکاپ (وردپرس) | شما | زمانبندی و ارسال خودکار به فضای ابری | روی سایت هکشده یا خراب اجرا نمیشود |
| اسکریپت و کرون روی سرور مجازی | شما | دقیق، قابل تنظیم، بدون بار روی سایت | دانش فنی میخواهد |
نکتهٔ ضعف افزونهها را جدی بگیرید. افزونهٔ بکاپ کدی است که داخل خود وردپرس اجرا میشود؛ اگر سایت پایین باشد یا مهاجم فایلها را دستکاری کرده باشد، همان افزونه هم از کار افتاده است. برای همین حتی روی هاست وردپرس که افزونههای بکاپ راحت اجرا میشوند، یک نسخهٔ سطح کنترلپنل هم لازم دارید.
در cPanel و DirectAdmin چطور بکاپ بگیریم
هر دو کنترلپنل ابزار بکاپ دارند و کارشان مشابه است، ولی یک تفاوت مهم دارند که موقع بازگردانی معلوم میشود. اگر هنوز بین این دو مردد هستید، مقایسهٔ cPanel و DirectAdmin را جدا نوشتهایم.
در cPanel
در بخش Backup دو چیز متفاوت میبینید. «بکاپ کامل حساب» یک آرشیو از همهچیز میسازد و لینک دانلودش را میدهد — این همان نسخهای است که باید هر ماه بگیرید و روی کامپیوترتان نگه دارید. اما در اکثر هاستهای اشتراکی بازگردانی این فایل کامل را خودتان نمیتوانید انجام دهید و باید تیکت بزنید.
پایینتر، «بکاپ جزئی» هست: پوشهٔ خانه، و هر دیتابیس بهصورت جداگانه. اینها را هم میشود گرفت و هم خودتان بازگرداند. برای کار روزمره — مثلاً قبل از بهروزرسانی یک افزونه — همین جزئی کافی و سریعتر است.
در DirectAdmin
در بخش «ساخت و بازگردانی بکاپ» انتخاب میکنید چه چیزهایی داخل آرشیو باشد: پوشهٔ سایت، دیتابیسها، ایمیلها، رکوردهای DNS. فایل ساختهشده در پوشهٔ backups حساب شما مینشیند؛ حتماً دانلودش کنید و بعد از سرور پاکش کنید تا فضا اشغال نشود. بازگردانی از همان صفحه و بدون تیکت انجام میشود، که مزیت واقعی این پنل است.
خروجی گرفتن از دیتابیس
سادهترین راه phpMyAdmin است: دیتابیس را انتخاب کنید، سربرگ Export، حالت Quick و قالب SQL. اگر دیتابیس بزرگ است حتماً خروجی فشرده (gzip) بگیرید، وگرنه میان راه به سقف زمان اجرا میخورید و فایل ناقص و بیمصرف تحویل میگیرید — که از قضا خطای بیسروصدایی است و تا روز بازگردانی معلوم نمیشود.
اگر دسترسی SSH دارید، mysqldump راه بهتر و مطمئنتری است و میشود آن را در کرون گذاشت. روی هاست لینوکس اشتراکی معمولاً SSH ندارید؛ روی سرور مجازی دارید و این یکی از دلایل واقعی ارتقا است.
هر چند وقت یک بار، و چند نسخه نگه داریم؟
پاسخ به یک سؤال برمیگردد: چند ساعت کارِ ازدسترفته را میتوانید تحمل کنید؟ اگر جواب «یک هفته» است، بکاپ هفتگی کافی است. اگر سایت فروشگاهی دارید و جواب «هیچ»، باید سراغ بکاپ روزانه و ترجیحاً بکاپ جداگانه و مکررِ دیتابیس بروید، چون سفارشها آنجا ثبت میشوند.
| نوع سایت | فاصلهٔ منطقی | چند نسخه نگه دارید |
|---|---|---|
| وبلاگ یا سایت شرکتی کمتغییر | هفتگی | چهار نسخهٔ هفتگی و یک ماهانه |
| سایت خبری یا محتوایی فعال | روزانه | هفت نسخهٔ روزانه و دو ماهانه |
| فروشگاه ووکامرس | روزانهٔ کامل و دیتابیس چندبار در روز | هفت روزانه، چهار هفتگی، سه ماهانه |
| سایت در حال توسعه | قبل از هر تغییر، دستی | تا وقتی تغییر تثبیت شود |
چرا نسخهٔ ماهانه؟ چون خرابی همیشه فوری معلوم نمیشود. کد مخربی که هفتهٔ پیش تزریق شده یا جدولی که بیسروصدا خالی شده، ممکن است سه هفته بعد پیدا شود. اگر فقط هفت نسخهٔ روزانه داشته باشید، هر هفتتا آلودهاند. یک نسخهٔ قدیمیتر همیشه باید در آرشیو باشد، حتی اگر محتوایش عقبتر باشد.
و یک قانون بیاستثنا: قبل از هر بهروزرسانی هستهٔ سیستم مدیریت محتوا، هر تغییر قالب، و هر انتقال هاست، یک بکاپ دستی بگیرید. پنج دقیقه وقت میبرد.
بکاپی که تست نشده، فرضیه است نه بکاپ
این را جدی بگیرید: تا وقتی یک بکاپ را واقعاً بازنگرداندهاید، فقط حدس میزنید که کار میکند. تجربهٔ دردناک اکثر افراد اینجا اتفاق میافتد — فایل هست، دانلودش هم شده، ولی روز حادثه معلوم میشود کار نمیکند.
خطاهایی که در تست پیدا میشوند و بدون تست پیدا نمیشوند:
- فایل SQL که بهخاطر سقف زمان اجرا نصفه مانده و آخرین جدولهایش نیست.
- فایلهای مخفی مثل
.htaccessکه نرمافزار FTP نشانشان نداده و در بکاپ نیامدهاند. - ناسازگاری کدگذاری کاراکتر، که سایت را با حروف فارسی بههمریخته برمیگرداند.
- بکاپ افزونهای که فقط پوشهٔ آپلودها را ذخیره کرده و دیتابیس در آن نیست.
- آرشیوی که اصلاً باز نمیشود، چون دانلود ناقص بوده و کسی حجمش را چک نکرده.
تست لازم نیست پیچیده باشد. یک زیردامنه یا یک هاست ارزان موقت بگیرید، بکاپ را روی آن بالا بیاورید و پنج چیز را ببینید: صفحهٔ اصلی، ورود به پنل مدیریت، یک صفحهٔ داخلی، جستوجوی داخلی، و اگر فروشگاه است یک سفارش قدیمی. سالی دو بار و بعد از هر تغییر جدی در ساختار سایت این کار را تکرار کنید.
قبل از خرید، این چهار سؤال را از میزبان بپرسید
این چهار سؤال را در تیکت پیش از خرید بپرسید و جوابشان را نگه دارید. جدول مشخصات پلن معمولاً فقط مینویسد «بکاپگیری منظم» که هیچ معنایی ندارد.
- هر چند وقت یک بار بکاپ میگیرید؟ روزانه، هفتگی، یا «دورهای»؟ اگر جواب مبهم بود، یعنی تعهدی نیست.
- چند وقت نگهش میدارید؟ اگر فقط آخرین نسخه نگه داشته میشود، عملاً در برابر خرابیهایی که دیر پیدا میشوند محافظتی ندارید.
- بازگردانی را خودم از پنل انجام میدهم یا باید تیکت بزنم؟ و اگر تیکت است، در ساعت غیراداری چقدر طول میکشد؟
- بازگردانی هزینه دارد؟ این همان سؤالی است که کسی نمیپرسد و بعداً غافلگیر میشود. بعضی شرکتها بکاپ را رایگان میگیرند ولی برای بازگردانی مبلغ جداگانه میگیرند، مخصوصاً وقتی نسخهٔ قدیمیتر از چند روز بخواهید.
پلنهایی که در بازار موجودند را میتوانید کنار هم ببینید و سیاست بکاپشان را در صفحهٔ رسمی هر شرکت چک کنید:
| شرکت | پلن | فضا | قیمت ماهانه |
|---|---|---|---|
| زند هاست | سی پنل اقتصادی - 200 مگ (آلمان) | ۲۰۰ مگابایت | ۲۰٬۴۰۸ تومان |
| زند هاست | سی پنل اقتصادی - 500 مگ (آلمان) | ۵۰۰ مگابایت | ۲۷٬۰۷۵ تومان |
| زند هاست | سی پنل ایران 200 مگ | ۲۰۰ مگابایت | ۲۹٬۴۰۰ تومان |
| دی هاستینگ | P3 | ۲۰۰ مگابایت | ۳۱٬۶۶۷ تومان |
| ای هاست | GSH-5 | ۵ گیگابایت | ۳۲٬۲۳۶ تومان |
اگر هنوز مطمئن نیستید چه پلنی مناسب شماست، یابندهٔ هاست با چند سؤال ساده گزینهها را محدود میکند و همهٔ دستهها هم در جدول هاست قابل فیلتر کردن است.
پرسشهای متداول
بکاپ سایت چقدر فضا میگیرد؟
تقریباً هماندازهٔ خود سایت، و بعد از فشردهسازی کمی کمتر — البته تصاویر و ویدیوها تقریباً فشرده نمیشوند. اگر چند نسخه نگه میدارید، فضای لازم را چند برابر حساب کنید. برای برآورد دقیقتر راهنمای فضای هاست را ببینید.
بکاپ روی هاست از سهمیهٔ فضای من کم میشود؟
در اکثر هاستهای اشتراکی بله، اگر فایل بکاپ داخل حساب شما ساخته شود. بکاپهای خودکارِ خودِ شرکت که روی زیرساخت جدا نگهداری میشوند معمولاً از سهمیه کم نمیشوند. این را جدا بپرسید، چون تفاوتش در پلنهای کمفضا زیاد است.
اگر سایت هک شد، بکاپ بهتنهایی کافی است؟
خیر. بازگردانی بکاپ سایت را به حالت قبل برمیگرداند ولی راه ورود مهاجم را نمیبندد. اگر همان افزونهٔ آسیبپذیر دوباره برگردد، ظرف چند روز دوباره هک میشوید. اول بکاپی را انتخاب کنید که مطمئنید قبل از نفوذ است، بعد بهروزرسانیها را کامل کنید و همهٔ رمزها را عوض کنید.
بکاپ ایمیلها چه میشود؟
بکاپ کامل کنترلپنل معمولاً صندوقها را هم دارد، ولی اگر بکاپ جزئی میگیرید احتمالاً ندارد. مطمئنترین راه برای ایمیلهای مهم این است که یک بار با IMAP همه را در نرمافزار ایمیل روی کامپیوتر خودتان دانلود کنید.
روی سرور مجازی هم همین ماجراست؟
بله، با یک تفاوت مهم: آنجا هیچکس جز خودتان بکاپ نمیگیرد مگر اینکه سرویس بکاپ یا اسنپشات را جداگانه خریده باشید. اسنپشات هم بکاپ کامل نیست؛ برای برگشت سریع بعد از یک تغییر خوب است، اما جای آرشیو بیرونی را نمیگیرد.
جمعبندی: مسیر تصمیم
- مشخص کنید حداکثر چند ساعت داده را میتوانید از دست بدهید. فاصلهٔ بکاپ از همین عدد درمیآید.
- بکاپ خودکار میزبان را روشن نگه دارید، ولی رویش حساب باز نکنید.
- ماهی یک بار یک نسخهٔ کامل از کنترلپنل بگیرید و از سرور بیرون بیاورید.
- برای فروشگاهها، بکاپ دیتابیس را جدا و مکررتر تنظیم کنید.
- سالی دو بار یک بازگردانی آزمایشی انجام دهید. بدون این مرحله بقیهٔ کارها فقط شبیه بکاپ گرفتن است.
- پیش از خرید یا تمدید، چهار سؤال بالا را از میزبان بپرسید و جواب کتبی بگیرید.
بکاپ سایتپشتیبانگیریبازگردانیهاست
مطالب مرتبط
آپتایم و SLA هاست: عدد ۹۹٫۹ درصد واقعاً یعنی چه؟
آپتایم بدون سند SLA فقط یک شعار تبلیغاتی است. اینجا حساب دقیق هر عدد، چیزی که یک SLA واقعی باید داشته باشد، و راه اندازهگیری مستقل را میبینید.
امنیت هاست و سایت: چه چیزی کار میزبان است و چه چیزی کار شما
بیشتر سایتهایی که هک میشوند از سمت سرور نفوذ نشدهاند. این راهنما مرز مسئولیت میزبان و شما را روشن میکند و میگوید سهم خودتان را چطور انجام دهید.
واژهنامهٔ هاست: ۵۲ اصطلاحی که موقع خرید هاست میبینید
هر اصطلاحی که در جدول مشخصات هاست میبینید، با یک تعریف کوتاه و یک نکتهٔ عملی برای وقتی که میخواهید بین دو پلن انتخاب کنید.
انتقال هاست بدون قطعی سایت: چکلیست عملی
راز انتقال بیدردسر این است که سایت را روی هاست جدید کامل راه بیندازید و فقط در آخرین مرحله DNS را عوض کنید. ایمیل را هم از اول جدی بگیرید، نه آخر.