بکاپگیری حرفهای از سایت
بکاپگیری حرفهای از سایت یعنی تهیه نسخه پشتیبان منظم، چندلایه و قابل بازیابی از فایلها، دیتابیس و اطلاعات مهم سایت. در این مقاله با انواع Backup، قانون 3-2-1، ذخیره Off-site، بکاپ وردپرس و cPanel، مفاهیم RPO و RTO، تست Restore و روشهای افزایش امنیت و اطمینان از سلامت نسخههای پشتیبان آشنا میشوید.
بکاپگیری حرفهای از سایت فقط به این معنا نیست که هر چند وقت یکبار یک فایل ZIP از هاست دانلود کنیم. نسخه پشتیبان زمانی ارزش واقعی دارد که منظم، چندلایه، خارج از سرور اصلی، قابل بازیابی و متناسب با میزان تغییرات سایت باشد. یک Backup اصولی میتواند در زمان هک، حذف اطلاعات، خرابی سرور یا خطای انسانی سایت را در کوتاهترین زمان ممکن به وضعیت سالم بازگرداند.
خرابی وبسایت ممکن است در چند ثانیه اتفاق بیفتد؛ یک بهروزرسانی ناسازگار، حذف اشتباه دیتابیس، نفوذ مهاجم، خرابی دیسک سرور یا حتی یک دستور اشتباه کافی است تا اطلاعاتی که طی سالها جمع شدهاند در معرض خطر قرار بگیرند.
بااینحال، مشکل اصلی بسیاری از وبسایتها نداشتن Backup نیست؛ بلکه داشتن بکاپی است که هنگام بحران قابل استفاده نیست.
ممکن است نسخه پشتیبان:
- ناقص باشد؛
- دیتابیس را شامل نشود؛
- روی همان سرور اصلی ذخیره شده باشد؛
- ماهها قدیمی باشد؛
- آلوده به بدافزار باشد؛
- یا هیچوقت فرآیند Restore آن آزمایش نشده باشد.
در این راهنما بهصورت کامل بررسی میکنیم که بکاپ سایت چیست، از چه بخشهایی باید نسخه پشتیبان تهیه شود، چه زمانی Backup بگیریم، بهترین محل ذخیره نسخه پشتیبان کجاست، قانون 3-2-1 چیست و چگونه مطمئن شویم نسخههای تهیهشده واقعاً قابل بازیابی هستند.
بکاپ سایت چیست؟
Backup یا نسخه پشتیبان، کپی جداگانهای از اطلاعات سایت است که در صورت خرابی، حذف، نفوذ یا تغییر اشتباه بتوان از آن برای بازیابی سایت استفاده کرد.
یک وبسایت معمولاً فقط از فایلهای قابل مشاهده در File Manager تشکیل نشده است.
بسته به نوع سایت، اطلاعات ممکن است شامل موارد زیر باشند:
- فایلهای سایت؛
- دیتابیس؛
- تصاویر و فایلهای رسانهای؛
- افزونهها؛
- قالبها؛
- تنظیمات؛
- اطلاعات کاربران؛
- سفارشهای فروشگاه؛
- محصولات؛
- ایمیلها؛
- SSL و تنظیمات امنیتی؛
- Cron Jobها؛
- DNS یا تنظیمات مرتبط با سرویسها.
بنابراین وقتی درباره بکاپگیری حرفهای از سایت صحبت میکنیم، ابتدا باید مشخص شود چه اطلاعاتی برای بازسازی کامل سرویس ضروری هستند.
برای مثال، داشتن یک کپی از پوشه public_html یک سایت وردپرسی بدون دیتابیس معمولاً برای بازگردانی کامل سایت کافی نیست.
چرا بکاپگیری از سایت اهمیت دارد؟
بسیاری از مدیران سایت تا زمانی که مشکلی اتفاق نیفتاده است Backup را هزینه یا کار اضافی میدانند.
اما زمانی ارزش آن مشخص میشود که سایت از دسترس خارج شده باشد.
محافظت در برابر هک سایت
مهاجم ممکن است:
- فایلهای اصلی را تغییر دهد؛
- بدافزار نصب کند؛
- صفحات را حذف کند؛
- دیتابیس را دستکاری کند؛
- Backdoor ایجاد کند؛
- اطلاعات کاربران را تغییر دهد.
اگر نسخه سالمی از قبل از نفوذ وجود داشته باشد، فرآیند Recovery بسیار سادهتر خواهد شد.
البته Restore کردن Backup بهتنهایی مشکل امنیتی را حل نمیکند؛ نقطه ورود مهاجم نیز باید پیدا و اصلاح شود.
محافظت در برابر خطای انسانی
همیشه مهاجم عامل خرابی نیست.
گاهی مدیر سایت خودش اشتباه میکند.
برای مثال:
- جدول دیتابیس حذف میشود؛
- فایل اشتباهی پاک میشود؛
- تنظیمات مهم تغییر میکند؛
- افزونهای باعث خرابی سایت میشود؛
- محصول یا نوشتهای بهاشتباه حذف میشود.
در بسیاری از پروژهها خطای انسانی یکی از مهمترین دلایل نیاز به بازیابی اطلاعات است.
محافظت در برابر خرابی سرور
حتی زیرساختهای حرفهای نیز بدون احتمال خرابی نیستند.
مشکلات ممکن است شامل:
- خرابی Storage؛
- Corruption فایلها؛
- مشکل سیستمعامل؛
- خرابی RAID؛
- خطای دیتاسنتر؛
- مشکل Provider
باشند.
داشتن نسخهای خارج از همان زیرساخت باعث میشود مشکل فیزیکی سرور به معنی از دست رفتن اطلاعات نباشد.
بازیابی بعد از آپدیت ناموفق
یکی از کاربردهای بسیار مهم Backup مربوط به قبل از:
- آپدیت وردپرس؛
- آپدیت قالب؛
- تغییر PHP؛
- نصب افزونه؛
- تغییرات برنامهنویسی؛
- مهاجرت سرور
است.
قبل از هر تغییر مهم باید یک Restore Point جدید داشته باشید.
بکاپ کامل سایت شامل چه چیزهایی است؟
پاسخ به این سؤال به معماری سایت بستگی دارد.
اما برای اکثر سایتها چند بخش اصلی وجود دارد.
فایلهای سایت
این بخش شامل:
- PHP؛
- JavaScript؛
- CSS؛
- تصاویر؛
- ویدئوها؛
- قالبها؛
- افزونهها؛
- فایلهای Configuration
میشود.
در وردپرس، مسیرهایی مانند:
wp-content
اهمیت بسیار زیادی دارند.
دیتابیس
در سیستمهای مدیریت محتوا بخش بزرگی از اطلاعات اصلی داخل Database ذخیره میشود.
برای مثال وردپرس معمولاً اطلاعات زیر را داخل MySQL یا MariaDB نگهداری میکند:
- نوشتهها؛
- کاربران؛
- تنظیمات؛
- محصولات ووکامرس؛
- سفارشها؛
- دستهبندیها؛
- کامنتها؛
- تنظیمات افزونهها.
بنابراین Backup فقط از فایلها نمیتواند جای بکاپ دیتابیس را بگیرد.
فایلهای Upload
سایتهای محتوایی و فروشگاهی ممکن است چندین گیگابایت فایل رسانهای داشته باشند.
تصاویر محصول، فایل PDF، فایلهای قابل دانلود و سایر Mediaها باید در سیاست Backup در نظر گرفته شوند.
فایلهای تنظیمات
فایلهایی مانند:
wp-config.php
.htaccess
تنظیمات Nginx یا سایر Configurationها نیز در Recovery اهمیت دارند.
تفاوت بکاپ کامل و بکاپ دیتابیس
دو اصطلاح رایج در سرویسهای Hosting عبارتاند از:
Full Backup
و:
Database Backup
این دو یکسان نیستند.
Database Backup
فقط اطلاعات موجود در پایگاه داده را ذخیره میکند.
Full Backup
میتواند شامل:
- فایلها؛
- دیتابیس؛
- ایمیلها؛
- تنظیمات حساب؛
- سایر اطلاعات هاست
باشد.
نوع دقیق Full Backup به کنترلپنل و Provider بستگی دارد.

انواع بکاپ سایت
برای طراحی یک سیستم حرفهای باید انواع Backup را بشناسیم.
Full Backup
در این روش تمام اطلاعات انتخابشده در هر نوبت دوباره کپی میشوند.
مزیت:
بازیابی ساده.
عیب:
مصرف فضای ذخیرهسازی و زمان بیشتر.
Incremental Backup
بعد از Full Backup اولیه، فقط تغییرات ایجادشده نسبت به آخرین Backup ذخیره میشوند.
برای مثال:
روز اول: Full Backup
روز دوم: تغییرات روز دوم
روز سوم: تغییرات جدید
مزیت این روش مصرف فضای کمتر است.
Differential Backup
در این روش تغییرات نسبت به آخرین Full Backup ذخیره میشوند.
هرچه از Full Backup فاصله بگیریم، حجم Differential افزایش پیدا میکند.
کدام نوع بکاپ بهتر است؟
پاسخ واحدی وجود ندارد.
یک معماری متداول ممکن است چنین باشد:
- Full Backup هفتگی؛
- Incremental روزانه؛
- Database Backup چند بار در روز.
برای فروشگاه بسیار فعال ممکن است حتی این مقدار نیز کافی نباشد.
مهم این است که Backup Strategy براساس میزان تغییر اطلاعات تنظیم شود.

مفهوم RPO در بکاپ چیست؟
یکی از مهمترین مفاهیم در طراحی Backup حرفهای:
Recovery Point Objective یا RPO
است.
RPO مشخص میکند حداکثر چه مقدار اطلاعات قابل از دست رفتن است.
فرض کنید فروشگاه شما هر ساعت ۲۰ سفارش دارد.
اگر Backup فقط روزی یک بار گرفته شود و سرور درست قبل از Backup بعدی خراب شود، احتمال از دست دادن تقریباً یک روز اطلاعات وجود دارد.
اگر این مقدار قابل قبول نیست، باید فاصله Backup کاهش پیدا کند.
برای مثال:
RPO = 1 Hour
یعنی حداکثر یک ساعت اطلاعات قابل از دست رفتن است.
مفهوم RTO چیست؟
اصطلاح دوم:
Recovery Time Objective یا RTO
است.
RTO تعیین میکند سایت بعد از Incident باید حداکثر در چه مدت دوباره فعال شود.
برای مثال:
RTO = 2 Hours
یعنی باید بتوان سرویس را حداکثر ظرف دو ساعت بازیابی کرد.
وجود Backup بهتنهایی RTO پایین ایجاد نمیکند.
اگر Restore کردن نسخه پشتیبان ۱۲ ساعت طول بکشد، داشتن بکاپ روزانه برای یک فروشگاه بزرگ کافی نیست.
هر چند وقت یک بار باید از سایت بکاپ بگیریم؟
این یکی از رایجترین سؤالها است.
پاسخ به میزان تغییر سایت بستگی دارد.
سایت شرکتی کمتغییر
اگر فقط هر چند هفته یک محتوا منتشر میشود:
Backup روزانه یا چندبار در هفته معمولاً مناسب است.
سایت خبری
به دلیل انتشار مداوم محتوا:
Backup روزانه ممکن است کافی نباشد.
در سایتهای پرتولید، Database میتواند هر چند ساعت Backup شود.
فروشگاه اینترنتی
فروشگاه حساستر است.
زیرا دائماً:
- سفارش؛
- پرداخت؛
- کاربر؛
- موجودی؛
- وضعیت سفارش
تغییر میکند.
برای WooCommerce فعال، Backup دیتابیس با فاصله کوتاهتر اهمیت بسیار زیادی دارد.
انجمن یا سایت کاربرمحور
اگر کاربران دائماً:
- پیام؛
- نظر؛
- محتوا
ایجاد میکنند، RPO باید پایینتر باشد.

قانون 3-2-1 در بکاپ چیست؟
یکی از شناختهشدهترین اصول Backup:
قانون 3-2-1
است.
این قانون بهصورت ساده میگوید:
۳ نسخه از اطلاعات داشته باشید.
روی حداقل ۲ نوع Storage متفاوت نگهداری کنید.
حداقل ۱ نسخه در محل دیگری قرار داشته باشد.
برای مثال:
نسخه اصلی روی سرور سایت.
Backup دوم روی Storage مستقل.
Backup سوم روی Cloud Storage یا سرور دیگری.
این معماری احتمال از دست رفتن همزمان تمام نسخهها را کاهش میدهد.
چرا بکاپ روی همان هاست کافی نیست؟
فرض کنید Website و Backup هر دو روی یک Server قرار دارند.
اگر:
- Disk خراب شود؛
- حساب Hosting هک شود؛
- Provider اطلاعات را حذف کند؛
- Ransomware اطلاعات را رمزگذاری کند
ممکن است Backup نیز همزمان از بین برود.
به همین دلیل حداقل یک نسخه باید Off-site باشد.
Off-site Backup چیست؟
Off-site Backup نسخهای است که خارج از زیرساخت اصلی سایت نگهداری میشود.
برای مثال:
- Object Storage؛
- Cloud Storage؛
- سرور دیگر؛
- NAS در محل دیگر.
هدف این است که یک Failure واحد نتواند هم سایت و هم تمام Backupها را نابود کند.
بکاپ ابری سایت چیست؟
Cloud Backup به معنی ذخیره نسخه پشتیبان روی زیرساخت Cloud است.
مزایای آن شامل:
- دسترسی از نقاط مختلف؛
- مقیاسپذیری؛
- نگهداری مستقل از سرور اصلی؛
- امکان Automation
است.
اما Cloud بهخودیخود مساوی Backup امن نیست.
Access Key، Permission، Versioning و Retention Policy باید درست تنظیم شوند.
بکاپ وردپرس چگونه انجام میشود؟
برای سایت WordPress چند روش اصلی وجود دارد.
بکاپ توسط Hosting
بسیاری از Hosting Providerها Backup خودکار ارائه میکنند.
مزیت:
نیازی به پردازش داخل WordPress نیست.
اما باید بدانید:
- چند نسخه نگهداری میشود؟
- Backup کجا ذخیره میشود؟
- Restore هزینه دارد؟
- دیتابیس چند بار Backup میشود؟
- نسخهها تا چند روز باقی میمانند؟
بکاپ توسط افزونه وردپرس
Pluginهای Backup میتوانند فرآیند را از داخل WordPress مدیریت کنند.
امکانات رایج:
- Schedule؛
- Database Backup؛
- File Backup؛
- Cloud Upload؛
- Restore؛
- Migration.
بکاپ دستی
میتوانید فایلها را با:
- File Manager؛
- FTP/SFTP؛
- SSH
کپی کنید.
Database نیز از طریق:
- phpMyAdmin؛
- mysqldump؛
- ابزارهای مدیریت سرور
قابل Backup است.
روش دستی برای Backupهای قبل از تغییرات مهم بسیار مفید است، اما برای برنامه دائمی بهتر است Automation داشته باشید.

بهترین افزونههای بکاپ وردپرس چه ویژگیهایی دارند؟
بهجای تمرکز صرف روی نام Plugin، باید قابلیتها بررسی شوند.
یک ابزار مناسب بهتر است:
- Backup خودکار داشته باشد؛
- فایل و Database را پوشش دهد؛
- Remote Storage پشتیبانی کند؛
- امکان Restore ساده داشته باشد؛
- Incremental Backup ارائه دهد؛
- Retention قابل تنظیم داشته باشد؛
- Log مناسب تولید کند.
بکاپگیری از وردپرس با cPanel
اگر هاست از cPanel استفاده میکند، معمولاً ابزارهایی برای Backup وجود دارند.
بسته به تنظیم Provider ممکن است بتوانید:
- Full Account Backup؛
- Home Directory Backup؛
- Database Backup
ایجاد کنید.
Full Account Backup برای مهاجرت یا Disaster Recovery مناسب است.
اما اگر فایل خروجی روی همان Account باقی بماند، بهتر است آن را به محل دیگری منتقل کنید.
آیا Full Backup سیپنل برای بکاپ دائمی کافی است؟
نه الزاماً.
Full cPanel Backup بسیار مفید است، اما معمولاً برای اجرای دستی یا مهاجرت استفاده میشود.
برای سیستم حرفهای باید:
- زمانبندی خودکار؛
- انتقال Off-site؛
- Retention؛
- تست Restore
نیز وجود داشته باشد.
بکاپ دیتابیس سایت چگونه انجام میشود؟
در MySQL یکی از روشهای شناختهشده استفاده از ابزار:
mysqldump
است.
این ابزار میتواند خروجی SQL ایجاد کند که بعداً قابل Import باشد.
برای سایتهای کوچک بسیار مناسب است.
در Databaseهای بسیار بزرگ ممکن است روشهای دیگری برای Backup و Snapshot مناسبتر باشند.
بکاپ لحظهای یا Snapshot چیست؟
Snapshot وضعیت Storage یا Machine را در یک نقطه زمانی ثبت میکند.
Snapshot در محیطهای:
- VPS؛
- Cloud Server؛
- Virtual Machine
بسیار رایج است.
مزیت اصلی سرعت بالای ایجاد و Restore است.
اما Snapshot را نباید همیشه جایگزین Backup مستقل دانست.
اگر Snapshot روی همان Infrastructure وابسته باشد، مشکل Provider میتواند هر دو را تحت تأثیر قرار دهد.
Snapshot و Backup چه تفاوتی دارند؟
Snapshot برای بازگشت سریع به وضعیت قبلی بسیار مناسب است.
Backup برای نگهداری طولانیتر و Disaster Recovery مناسبتر است.
بهترین معماری میتواند از هر دو استفاده کند.
برای مثال:
Snapshot قبل از Update.
Backup Off-site روزانه.
بکاپ قبل از آپدیت سایت
یکی از مهمترین عادتهایی که هر مدیر سایت باید داشته باشد:
Backup Before Change
است.
قبل از:
- Update؛
- نصب Plugin؛
- تغییر Theme؛
- PHP Upgrade؛
- Migration؛
- ویرایش Database
یک Restore Point ایجاد کنید.
اگر تغییر خراب شد، بازگشت بسیار سریعتر خواهد بود.
آیا باید قبل از هر آپدیت وردپرس بکاپ بگیریم؟
برای Updateهای خودکار مداوم، Backup System باید از قبل در حال اجرا باشد.
برای تغییرات بزرگ یا Upgrade مهم بهتر است یک Backup جدید درست قبل از انجام کار وجود داشته باشد.
این کار بهخصوص در:
- WooCommerce؛
- سایتهای سفارشی؛
- سایتهای دارای Plugin زیاد
اهمیت بیشتری دارد.
نگهداری چند نسخه بکاپ ضروری است؟
فقط یک Backup آخر خطرناک است.
فرض کنید Malware سه هفته قبل وارد سایت شده و شما امروز آن را کشف کردهاید.
اگر فقط Backup دیشب را داشته باشید، احتمالاً همان نسخه نیز آلوده است.
به همین دلیل باید چند Restore Point نگه داشت.
برای مثال:
- ۷ نسخه روزانه؛
- ۴ نسخه هفتگی؛
- چند نسخه ماهانه.
این ساختار به نام:
Retention Policy
شناخته میشود.
Retention Policy چیست؟
Retention مشخص میکند Backupها چه مدت نگهداری شوند.
برای مثال:
Daily: 14 Days
Weekly: 8 Weeks
Monthly: 6 Months
نوع سیاست باید به:
- فضای Storage؛
- حساسیت سایت؛
- قوانین کسبوکار
وابسته باشد.
بکاپ آلوده؛ خطری که کمتر دیده میشود
Backup همیشه سالم نیست.
اگر سایت امروز هک شده ولی نفوذ یک ماه قبل اتفاق افتاده باشد، چندین Backup اخیر میتوانند حاوی Backdoor باشند.
در چنین شرایطی انتخاب نسخه Restore باید با بررسی Timeline انجام شود.
بنابراین هنگام Incident امنیتی صرفاً جدیدترین Backup را Restore نکنید.
ابتدا زمان تقریبی نفوذ را مشخص کنید.

چگونه بفهمیم بکاپ سایت سالم است؟
چند مرحله مهم وجود دارد.
بررسی Log
مطمئن شوید Job بکاپ با Error تمام نشده است.
بررسی حجم فایل
اگر Backup معمولاً ۱۰ گیگابایت بوده و نسخه جدید فقط ۲۰ مگابایت است، احتمال مشکل وجود دارد.
بررسی Database
اطمینان حاصل کنید Dump دیتابیس ایجاد شده است.
Test Restore
مهمترین مرحله همین است.
یک Backup تا زمانی که Restore نشده، فقط یک فایل امیدوارکننده است.
تست بازیابی بکاپ چیست؟
در Test Restore نسخه پشتیبان روی محیط جداگانه بازیابی میشود.
برای مثال:
staging.example.com
یا Local Environment.
سپس بررسی میکنید:
- سایت باز میشود؟
- Database سالم است؟
- تصاویر وجود دارند؟
- Login کار میکند؟
- محصولات موجود هستند؟
- تنظیمات درست هستند؟
این کار باید بهصورت دورهای انجام شود.
چرا تست Restore از خود Backup مهمتر است؟
ممکن است Backup بدون Error ساخته شده باشد اما هنگام Restore متوجه شوید:
- Archive خراب است؛
- Database ناقص است؛
- Permission اشتباه است؛
- Key لازم وجود ندارد؛
- Version نرمافزار ناسازگار است.
اگر اولین بار در روز بحران Restore را امتحان کنید، ممکن است زمان زیادی از دست بدهید.
بکاپ فروشگاه ووکامرس چگونه باید باشد؟
WooCommerce نسبت به سایت معمولی حساستر است.
اطلاعات دائماً تغییر میکنند.
برای مثال طی یک ساعت ممکن است:
- سفارش جدید؛
- پرداخت؛
- ثبتنام؛
- تغییر موجودی؛
- تغییر وضعیت سفارش
اتفاق بیفتد.
بنابراین Full Backup روزانه ممکن است RPO مناسبی ایجاد نکند.
راهکار بهتر میتواند شامل Backup مکرر Database باشد.
هنگام Restore ووکامرس چه مشکلی ممکن است ایجاد شود؟
فرض کنید Backup ساعت ۱۰ صبح را ساعت ۵ عصر Restore کنید.
تمام سفارشهایی که بین ساعت ۱۰ تا ۵ ثبت شدهاند ممکن است از Database بازیابیشده حذف شوند.
به همین دلیل Restore فروشگاه باید با برنامه دقیق انجام شود.
گاهی لازم است اطلاعات جدید قبل از Restore Extract شده و بعد دوباره Merge شوند.
بکاپ ایمیلهای هاست را فراموش نکنید
اگر ایمیل شرکت روی همان Hosting قرار دارد، Full Website Backup الزاماً همیشه شامل تمام Mailboxها نیست.
باید بررسی کنید.
در Migration یا Disaster Recovery، از دست دادن Email ممکن است حتی از خرابی سایت نیز مهمتر باشد.
امنیت فایلهای بکاپ
Backup حاوی حساسترین اطلاعات سایت است.
ممکن است داخل آن:
- Database Password؛
- اطلاعات کاربران؛
- API Key؛
- ایمیل؛
- اطلاعات سفارشها
وجود داشته باشد.
بنابراین Backup باید به اندازه Production محافظت شود.
رمزگذاری بکاپ
در صورت امکان Backupهای حساس را Encrypt کنید.
بهخصوص نسخههایی که:
- روی Storage خارجی؛
- Cloud؛
- دستگاه قابل حمل
نگهداری میشوند.
اما Encryption یک مشکل جدید نیز ایجاد میکند:
اگر Key را گم کنید، Backup قابل استفاده نخواهد بود.
بنابراین Key Management نیز اهمیت دارد.
دسترسی به بکاپ را محدود کنید
همه اعضای تیم نباید امکان دانلود Full Backup را داشته باشند.
از اصل:
Least Privilege
استفاده کنید.
فردی که فقط محتوا منتشر میکند نیازی به دسترسی به Database Backup ندارد.
بکاپ را داخل public_html نگه ندارید
یکی از اشتباهات خطرناک این است که فایلی مانند:
backup.zip
یا:
site-backup.tar.gz
داخل Public Web Root باقی بماند.
اگر URL آن قابل حدس باشد یا Server اشتباه تنظیم شده باشد، مهاجم ممکن است آن را دانلود کند.
Backup باید در مسیر محافظتشده ذخیره شود.
نام فایل بکاپ نیز مهم است
نامهای ساده مانند:
backup.zip
database.sql
قابل حدس هستند.
هرچند مخفی کردن نام جایگزین Permission مناسب نیست، ولی نباید فایل حساس را با URL عمومی و نام واضح در دسترس قرار داد.
بکاپ آفلاین چیست؟
Offline Backup نسخهای است که بهصورت دائمی به سیستم اصلی متصل نیست.
برای مثال Storage فیزیکی که پس از Backup Disconnect میشود.
مزیت آن در برابر:
- Ransomware؛
- حذف عمدی؛
- Compromise حساب Cloud
است.
برای پروژههای بسیار مهم میتوان یک نسخه Offline نیز نگه داشت.
بکاپ Immutable چیست؟
Immutable Backup نسخهای است که برای مدت مشخص قابل تغییر یا حذف نیست.
این ویژگی برای مقابله با Ransomware بسیار مهم است.
اگر مهاجم به حساب Backup دسترسی پیدا کند اما نسخهها Immutable باشند، نمیتواند بلافاصله آنها را پاک کند.
Versioning چه کمکی میکند؟
Versioning اجازه میدهد چند نسخه از یک Object نگهداری شود.
اگر یک Backup اشتباه Overwrite شود، نسخه قبلی ممکن است همچنان قابل بازیابی باشد.
این قابلیت در بسیاری از Object Storageها مفید است.
تفاوت Sync و Backup
یکی از اشتباهات رایج استفاده از Sync بهجای Backup است.
فرض کنید پوشه سایت با Cloud Sync میشود.
اگر فایلها روی Server حذف شوند، Sync ممکن است حذف را نیز روی Cloud اعمال کند.
Backup باید History و Version جداگانه داشته باشد.
بنابراین:
Sync ≠ Backup
بکاپ دستی بهتر است یا خودکار؟
برای سیستم دائمی، خودکار بهتر است.
انسان ممکن است:
- فراموش کند؛
- دیر Backup بگیرد؛
- فایل ناقص بسازد.
Automation باعث میشود Backup طبق Schedule مشخص انجام شود.
اما Backup دستی همچنان قبل از تغییرات مهم بسیار کاربردی است.
بکاپ خودکار چگونه باید مانیتور شود؟
Automation بدون Monitoring خطرناک است.
ممکن است Job سه ماه Fail شده باشد و مدیر سایت متوجه نشده باشد.
سیستم خوب باید در صورت:
- Failure؛
- Storage Full؛
- Upload Error؛
- Archive Error
هشدار ارسال کند.
آیا بکاپ هاست کافی است؟
این سؤال پاسخ کوتاهی دارد:
نباید تنها نسخه شما باشد.
Backup Hosting بسیار مفید است، اما کنترل کامل آن در اختیار شما نیست.
ممکن است:
- Retention کوتاه باشد؛
- همه سرویسها را پوشش ندهد؛
- در Incident گسترده Provider مشکل ایجاد شود.
بنابراین یک نسخه مستقل نیز داشته باشید.
قبل از خرید هاست چه سؤالاتی درباره بکاپ بپرسیم؟
بهتر است بدانید:
- هر چند وقت Backup گرفته میشود؟
- چند نسخه نگهداری میشود؟
- فایل و Database شامل میشوند؟
- Backup روی سرور جداست؟
- Restore رایگان است؟
- کاربر میتواند Restore کند؟
- Backupها Encrypt هستند؟
- Retention چند روز است؟
عبارت «بکاپ روزانه» بهتنهایی اطلاعات کافی نمیدهد.
فضای موردنیاز برای بکاپ چقدر است؟
به حجم سایت و Retention بستگی دارد.
فرض کنید سایت شما ۲۰ گیگابایت است.
اگر ۳۰ Full Backup نگه دارید، در بدترین حالت به صدها گیگابایت Storage نیاز خواهید داشت.
Incremental Backup میتواند حجم را به شکل قابل توجهی کاهش دهد.
فایلهایی که نیازی به بکاپ ندارند
همیشه لازم نیست هر فایل Temporary ذخیره شود.
برای مثال:
- Cache؛
- Temporary Files؛
- بعضی Logهای موقت
ممکن است از Backup حذف شوند.
این کار حجم و زمان را کاهش میدهد.
اما قبل از Exclude مطمئن شوید فایل واقعاً قابل بازسازی است.
بکاپ Logها
Security Log و Audit Log میتوانند بعد از Incident بسیار مهم باشند.
اگر تمام Logها همراه با هک حذف شوند، تحلیل حادثه سختتر میشود.
برای سایتهای مهم بهتر است Logها نیز به سیستم مستقلی ارسال شوند.
بکاپ DNS
DNS معمولاً کمتر مورد توجه قرار میگیرد.
اگر Zone شامل تعداد زیادی Record باشد، نگه داشتن Export تنظیمات میتواند Recovery را سریعتر کند.
بهخصوص در Migration یا حذف اشتباه DNS Record.
مستندسازی فرآیند بازیابی
در پروژه حرفهای فقط Backup کافی نیست.
باید مشخص باشد:
- Backup کجاست؟
- چه کسی دسترسی دارد؟
- Encryption Key کجاست؟
- Restore چگونه انجام میشود؟
- DNS چگونه تغییر میکند؟
- چه کسی تصمیم Restore میگیرد؟
این اطلاعات در یک:
Disaster Recovery Plan
ثبت میشوند.
Disaster Recovery چیست؟
Disaster Recovery یا DR مجموعه اقداماتی است که برای بازگرداندن سرویس بعد از حادثه طراحی میشود.
Backup یکی از بخشهای DR است.
یک برنامه DR ممکن است شامل:
- تشخیص Incident
- ایزوله کردن سرور
- انتخاب Backup سالم
- ایجاد Environment جدید
- Restore
- تست
- تغییر DNS
- Monitoring
باشد.
بکاپ و امنیت سایت چه ارتباطی دارند؟
Backup یکی از اجزای امنیت است.
امنیت فقط جلوگیری از حمله نیست.
مدل امنیتی معمولاً بر سه مفهوم تکیه دارد:
Confidentiality
Integrity
Availability
Backup مستقیماً به Availability و Integrity کمک میکند.
اگر اطلاعات حذف یا خراب شوند، نسخه سالم امکان Recovery را فراهم میکند.
نقش بکاپ در حملات باجافزاری
در Ransomware هدف مهاجم میتواند رمزگذاری یا از دسترس خارج کردن اطلاعات باشد.
اگر Backup:
- مستقل؛
- Immutable؛
- Offline
باشد، سازمان قدرت بیشتری برای Recovery خواهد داشت.
اما اگر Backup به همان Credential و Storage متصل باشد، مهاجم ممکن است آن را نیز حذف کند.
بکاپ سایت هکشده را حذف کنیم؟
نه فوراً.
نسخه آلوده ممکن است برای:
- Forensic Analysis؛
- پیدا کردن Backdoor؛
- تعیین زمان نفوذ؛
- شناسایی فایل تغییرکرده
ارزش داشته باشد.
آن را از Backup سالم جدا و با برچسب آلوده نگهداری کنید.
بعد از هک سایت کدام بکاپ را Restore کنیم؟
جدیدترین نسخه لزوماً بهترین نسخه نیست.
باید زمان Incident مشخص شود.
اگر نفوذ ۱۰ روز قبل اتفاق افتاده باشد، Backup مربوط به سه روز قبل نیز آلوده است.
بهتر است Timeline با استفاده از:
- Log؛
- File Modification Time؛
- Security Alert؛
- Search Console
بررسی شود.
آیا Restore کردن Backup هک سایت را حل میکند؟
نه بهتنهایی.
اگر Vulnerability اصلی همچنان وجود داشته باشد، مهاجم دوباره وارد میشود.
بعد از Restore باید:
- Plugin آسیبپذیر Update شود؛
- Passwordها تغییر کنند؛
- Backdoorها بررسی شوند؛
- Accessها کنترل شوند؛
- Security Keys تغییر کنند.
بکاپ و سئو چه ارتباطی دارند؟
خرابی سایت میتواند روی SEO تأثیر بگذارد.
اگر Site برای مدت طولانی:
- Down باشد؛
- خطای 500 بدهد؛
- صفحات حذف شوند؛
- Redirect اشتباه ایجاد شود
تجربه کاربر و Crawl موتورهای جستجو تحت تأثیر قرار میگیرد.
Backup و Recovery سریع کمک میکند Downtime کوتاهتر شود.
بازیابی اشتباه چه آسیبی به سئو میزند؟
فرض کنید Backup بسیار قدیمی را Restore کنید.
ممکن است:
- مقالات جدید حذف شوند؛
- URLهای جدید از بین بروند؛
- Redirectها برگردند؛
- Sitemap قدیمی شود.
بنابراین بعد از Restore باید بخش SEO نیز بررسی شود.
بعد از بازیابی سایت چه چیزهایی را تست کنیم؟
Restore پایان کار نیست.
باید حداقل موارد زیر بررسی شوند:
- Home Page؛
- Login؛
- صفحات مهم؛
- تصاویر؛
- لینکها؛
- فرمها؛
- Search؛
- SSL؛
- Email؛
- Sitemap؛
- Robots.txt.
در WooCommerce:
- Cart؛
- Checkout؛
- Payment؛
- Order؛
- Inventory
نیز باید تست شوند.
چکلیست بکاپگیری حرفهای از سایت
برای اینکه مشخص شود سیستم Backup شما حرفهای است، موارد زیر را بررسی کنید:
- [ ] بکاپ بهصورت خودکار انجام میشود.
- [ ] فایلها و دیتابیس هر دو پوشش داده میشوند.
- [ ] حداقل یک نسخه Off-site وجود دارد.
- [ ] فقط به Backup هاست وابسته نیستید.
- [ ] چند Restore Point نگهداری میشود.
- [ ] Retention Policy تعریف شده است.
- [ ] Backupها بهصورت دورهای تست Restore میشوند.
- [ ] Backupهای حساس رمزگذاری شدهاند.
- [ ] دسترسی به Backup محدود است.
- [ ] در صورت Failure هشدار دریافت میکنید.
- [ ] Backup قبل از تغییرات مهم گرفته میشود.
- [ ] نسخه آلوده و سالم از یکدیگر مشخص هستند.
- [ ] RPO سایت تعیین شده است.
- [ ] RTO مشخص است.
- [ ] فرآیند Disaster Recovery مستند شده است.
اگر چند مورد از این موارد رعایت نمیشوند، سیستم Backup شما هنوز جای بهبود دارد.
برنامه پیشنهادی بکاپ برای سایت معمولی
یک برنامه ساده میتواند چنین باشد:
روزانه
Database Backup
روزانه یا یک روز در میان
Incremental File Backup
هفتگی
Full Backup
ماهانه
نسخه آرشیوی
همیشه
حداقل یک نسخه Off-site
این فقط نمونه است و باید بر اساس سایت تنظیم شود.
برنامه پیشنهادی برای فروشگاه اینترنتی
برای یک WooCommerce فعال:
هر ۱ تا چند ساعت
Database Backup
روزانه
File Backup
هفتگی
Full Backup
Off-site
فعال
Restore Test
دورهای
فاصله دقیق براساس تعداد سفارشها تعیین میشود.
بکاپگیری حرفهای برای سایتهای مهم
اگر سایت برای کسبوکار حیاتی است، بهتر است از چند لایه استفاده کنید:
لایه اول: Snapshot سریع
لایه دوم: Backup روزانه
لایه سوم: Off-site Backup
لایه چهارم: Immutable Backup
لایه پنجم: Offline Archive
لزومی ندارد هر سایت تمام این لایهها را داشته باشد، اما سایتهای Critical ارزش چنین ساختاری را دارند.
اشتباهات رایج در بکاپگیری از سایت
فقط یک نسخه نگه داشتن
اگر همان نسخه خراب یا آلوده باشد، Recovery ممکن نیست.
نگهداری بکاپ روی همان سرور
Server Failure میتواند هر دو را نابود کند.
تست نکردن Restore
بکاپ تستنشده تضمین بازیابی نیست.
بکاپ نکردن دیتابیس
برای CMSها معمولاً اشتباه بزرگی است.
Backup دستی نامنظم
در روز بحران احتمالاً نسخه مناسب ندارید.
نادیده گرفتن Security
Backup بدون Encryption و Access Control میتواند باعث Data Leak شود.
استفاده از Sync بهجای Backup
حذف فایل ممکن است همزمان Sync شود.
نگهداری backup.zip در public_html
یکی از بدترین روشهای ذخیره نسخه پشتیبان است.
آیا بکاپ رایگان کافی است؟
هزینه ابزار تعیینکننده کیفیت Backup نیست.
حتی با ابزارهای رایگان میتوان سیستم مناسبی ساخت.
آنچه اهمیت دارد:
- Automation؛
- Off-site Storage؛
- Retention؛
- Restore Test؛
- Monitoring
است.
سرویس پولی ممکن است مدیریت این موارد را آسانتر کند.
بهترین روش بکاپگیری از سایت چیست؟
اگر بخواهیم یک نسخه عمومی ارائه کنیم:
Backup خودکار + چند نسخه + ذخیره Off-site + تست Restore
بهترین چارچوب است.
برای سایتهای حساستر:
Immutable Backup
و:
RPO/RTO مشخص
نیز اضافه میشوند.
سوالات متداول درباره بکاپگیری حرفهای از سایت
هر چند وقت یک بار از سایت بکاپ بگیریم؟
به میزان تغییر سایت بستگی دارد. سایت شرکتی ممکن است با Backup روزانه کاملاً ایمن باشد، اما فروشگاه پرتراکنش ممکن است به Backup دیتابیس ساعتی یا کوتاهتر نیاز داشته باشد.
آیا بکاپ روزانه هاست کافی است؟
بهتر است تنها نسخه شما نباشد. حداقل یک Backup مستقل و خارج از همان Hosting نگهداری کنید.
از فایل سایت بکاپ بگیریم یا دیتابیس؟
در بیشتر CMSها به هر دو نیاز دارید. فایل بدون Database معمولاً سایت کامل را بازسازی نمیکند.
بهترین محل ذخیره بکاپ کجاست؟
Storage مستقل از Server اصلی. برای پروژههای مهم ترکیبی از Cloud، Off-site و در صورت نیاز Offline مناسبتر است.
چند نسخه Backup نگه داریم؟
بسته به Retention Policy. حداقل چند نسخه روزانه و هفتگی داشته باشید تا در صورت دیر شناسایی شدن مشکل بتوان به تاریخ قدیمیتر بازگشت.
آیا افزونه Backup وردپرس کافی است؟
میتواند بخش مهمی از سیستم باشد، اما بهتر است Backup در Storage خارجی ذخیره شود و فرآیند Restore نیز تست شود.
Backup و Snapshot چه تفاوتی دارند؟
Snapshot برای Recovery سریع یک سیستم بسیار مناسب است، درحالیکه Backup معمولاً برای نگهداری مستقل و بلندمدت طراحی میشود.
آیا میتوان از سایت هکشده Backup گرفت؟
بله. حتی ممکن است برای تحلیل امنیتی مفید باشد؛ اما نسخه آلوده باید از Backupهای سالم جدا نگهداری شود.
آیا Restore آخرین Backup همیشه بهترین کار است؟
خیر. اگر سایت مدتها قبل هک شده باشد، آخرین نسخه نیز آلوده خواهد بود.
از کجا بفهمیم Backup سالم است؟
مطمئنترین روش Test Restore روی محیط جداگانه است.
آیا Backup روی کامپیوتر شخصی کافی است؟
میتواند یک نسخه اضافه باشد، اما بهتر است تنها محل ذخیره نباشد. خرابی Disk یا Malware کامپیوتر میتواند آن نسخه را نیز از بین ببرد.
بکاپگیری حرفهای از سایت چقدر هزینه دارد؟
به حجم داده، دفعات Backup، Retention و Storage بستگی دارد. برای یک سایت کوچک هزینه میتواند بسیار کم باشد، درحالیکه فروشگاه بزرگ با Backup لحظهای و Retention طولانی Storage بیشتری نیاز دارد.
جمعبندی
بکاپگیری حرفهای از سایت فقط ساختن یک فایل ZIP یا فعال کردن گزینه Backup در کنترلپنل نیست. نسخه پشتیبان زمانی ارزش واقعی دارد که هنگام Incident بتوان با اطمینان از آن استفاده کرد.
یک سیستم Backup مناسب باید حداقل چهار ویژگی داشته باشد:
منظم باشد، چند نسخه نگه دارد، خارج از سرور اصلی ذخیره شود و Restore آن آزمایش شده باشد.
برای سایتهای حساستر باید موارد دیگری مانند:
RPO، RTO، Encryption، Immutable Storage و Disaster Recovery
نیز تعریف شوند.
همچنین هیچگاه صرفاً به Backup شرکت Hosting وابسته نباشید. ممکن است سرویسدهنده سیستم Backup بسیار خوبی داشته باشد، اما داشتن یک نسخه مستقل کنترل شما روی Recovery را بیشتر میکند.
مهمتر از همه، هر Backup باید واقعاً قابل بازیابی باشد. وجود هزار نسخه پشتیبان که هیچکس نمیداند چگونه Restore شوند ارزش بسیار کمتری از چند نسخه سالم، مستند و تستشده دارد.
اگر سایت وردپرسی دارید، علاوه بر فایلها حتماً Database، Uploadها، قالبها و تنظیمات مهم را در برنامه Backup قرار دهید. در فروشگاههای اینترنتی نیز به دلیل تغییر دائمی سفارشها و موجودی، فاصله Backup دیتابیس باید براساس میزان تراکنش تعیین شود.
در نهایت Backup را باید بخشی از امنیت سایت در نظر گرفت؛ نه فقط ابزاری برای آرشیو اطلاعات. حمله سایبری، خطای انسانی یا خرابی سختافزار ممکن است قابل پیشگیری نباشد، اما داشتن یک سیستم بازیابی اصولی تعیین میکند حادثه به یک وقفه کوتاه تبدیل شود یا یک بحران جدی.