بکاپ خودکار سرور مجازی؛ چه چیزی، کجا و هر چند وقت یک بار؟

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

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

چی رو بکاپ بگیرم و چی رو نه؟

فهرست حداقلی اینه:

• دیتابیس: سفارش ها، کاربرها، محتوا. مهم ترین بخشه و جایگزین نداره.
• فایل های آپلود شده: عکس محصول ها، فایل های ضمیمه، مدارک کاربرها.
• کد برنامه: اگه همه اش توی گیت هست، اون مخزن خودش یه نسخه حساب می شه. ولی فایل هایی که روی سرور دستی عوض کردی رو هم یادت نره.
• تنظیمات: کانفیگ وب سرور، تنظیمات PHP، کرون ها، فایل .env، و گواهی ها اگه خودت مدیریت شون می کنی.
• ایمیل: اگه ایمیل سازمانی روی همین سرور هست، پوشه صندوق ها هم باید تو بکاپ باشه.

چیزهایی که همیشه یادمون می ره

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

چیزهایی که لازم نیست

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

دیتابیس رو چطور بگیرم؟

وقتی سایت فعاله، کپی کردن مستقیم پوشه دیتابیس ممکنه نسخه ای بسازه که موقع بازگردانی بالا نیاد. چون بخشی از فایل ها مال یه لحظه ست و بخش دیگه مال لحظه بعد. بهتره از خروجی منطقی (dump) یا ابزار رسمی خود دیتابیس استفاده کنی. اگه هنوز بین دو دیتابیس مردد هستی، مقایسه PostgreSQL یا MySQL برای سایت و اپلیکیشن کمک می کنه، چون روش بکاپ هم کمی فرق داره.

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

اگه از Docker استفاده می کنی

حجم های داده (volumes) رو فراموش نکن. یه نکته هم که تو ایران جدی تره: روی سرور داخل ایران، دریافت ایمیج از Docker Hub و بعضی بسته ها ممکنه به خاطر محدودیت IP ایران جواب نده. ما معمولاً ایمیج ها رو روی سیستم توسعه می سازیم و با SSH به سرور می فرستیم. برای بکاپ یعنی بازسازی روی سرور جدید هم همین مسیر رو لازم داری. پس Dockerfile و سورس ساخت ایمیج ها رو جای امن نگه دار، یا از خود ایمیج ها یه خروجی داشته باش. اگه ساختار پروژه ات هنوز ساده است، نوشته Docker Compose برای پروژه کوچک کمک می کنه بدونی کدوم قطعه ها رو باید کنار هم نگه داری.

بکاپ رو کجا نگه دارم؟

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

قاعده ۳-۲-۱ رو شنیده ای؟ یعنی سه نسخه از داده، روی دو نوع رسانه یا محل متفاوت، و یکی از اون ها بیرون از محل اصلی. نیازی نیست پیچیده اش کنی. برای یه کسب و کار کوچیک همین کافیه: یه نسخه روی خود سرور (برای بازگردانی سریع)، یه نسخه توی یه دیتاسنتر دیگه، و یه نسخه روی دیسک یا سیستم خودت.

گزینه ها توی شرایط ایران

• سرور یا فضای دیگه توی یه دیتاسنتر دیگه داخل ایران: معمولاً سریع و ارزون تره، پرداخت اش تومانیه و پهنای باند داخلی مشکلی نداره. بیشتر کسب و کارها از همین شروع می کنن.
• فضای ذخیره سازی اشیا (سازگار با S3) داخلی: برای حجم های بزرگ تر و بکاپ هایی که باید مدت طولانی بمونن، مرتب تره.
• سرویس های خارجی: به خاطر محدودیت پرداخت، دسترسی یا پهنای باند بین المللی ممکنه ناپایدار باشن. قبل از اینکه همه چیز رو بهشون بسپاری، آپلود، دانلود و زمان بازگردانی رو امتحان کن. قیمت و شرایط هم عوض می شه، پس از خود سرویس دهنده بپرس.
• یه نسخه آفلاین: برای داده های واقعاً حیاتی، یه نسخه روی دیسک یا سیستم خودت داشته باش که به شبکه وصل نباشه. اگه کسی به حساب هات نفوذ کنه، این نسخه دست نخورده می مونه.

رمزگذاری رو جدی بگیر

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

بکاپ خودکار سرور رو هر چند وقت یک بار بگیرم؟

جواب ثابت نداره، ولی یه سؤال همیشه کمک می کنه: اگه سرور همین الان خراب بشه و به آخرین بکاپ برگردم، چقدر کار از دست می ره و می تونم تحملش کنم؟

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

یه راهنمای ساده:

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

چند نسخه نگه دارم؟

فقط آخرین نسخه کافی نیست. گاهی مشکل (حذف اشتباهی محصول ها، یه بدافزار) چند روز بعد پیدا می شه و اون موقع آخرین بکاپ هم خرابه. یه الگوی معقول: نسخه های روزانه برای حدود یک هفته، هفتگی برای حدود یک ماه، و ماهانه برای چند ماه. هر چی بیشتر نگه داری فضای بیشتری می خوای. برای همین از یه ابزار افزایشی (مثل restic یا borg) استفاده کن تا فقط تغییرات ذخیره بشه.

ساعت اجرا هم مهمه

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

چطور خودکارش کنم؟

ساده ترین حالت یه اسکریپت شل و یه کرون ه. این فقط یه نمونه ست و مسیرها و اسم ها رو باید با پروژه خودت تطبیق بدی:

#!/bin/bash
set -euo pipefail

DATE=$(date +%F-%H%M)
DIR=/var/backups/site
mkdir -p "$DIR"

# دیتابیس (MySQL؛ نام کاربری و رمز در ~/.my.cnf)
mysqldump --single-transaction --routines mydb | gzip > "$DIR/db-$DATE.sql.gz"

# برای PostgreSQL به جای خط بالا:
# pg_dump -Fc mydb > "$DIR/db-$DATE.dump"

# فایل ها و تنظیمات
tar -czf "$DIR/files-$DATE.tar.gz" /var/www/site/uploads /etc/nginx /var/www/site/.env

# ارسال به سرور دیگر
rsync -a "$DIR/" backup@backup-host:/backups/site/

# پاک کردن نسخه های محلی قدیمی
find "$DIR" -type f -mtime +7 -delete

و برای اجرای هر شب ساعت ۳:۳۰ توی کرون:

30 3 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1

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

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

اگه استقرار سایتت رو هم خودکار کرده ای، بکاپ قبل از هر استقرار بزرگ رو به همون خط لوله اضافه کن. نوشته استقرار خودکار سایت با CI/CD نشون می ده این کار کجای مسیر جا می گیره.

از کجا بفهمم بکاپ سالمه؟

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

روش کار ساده است:

1. یه سرور آزمایشی تمیز بگیر. می تونه ارزون و کوتاه مدت باشه.
2. بکاپ رو از همون مقصد بیرونی بگیر، نه از روی سرور اصلی. چون روز بحران باید از همین مسیر بگیری.
3. دیتابیس و فایل ها رو بازگردانی کن و سایت رو بالا بیار.
4. چک کن: صفحه اصلی، ورود کاربر، یه سفارش آزمایشی، نمایش عکس ها.
5. زمان کل رو یادداشت کن. این عدد رو باید بدونی، چون می گه خرابی واقعی چقدر طول می کشه.

چیزهایی که فقط موقع بازگردانی دیده می شن

یکی از اون ها آدرس IP جدیده. بعضی درگاه های پرداخت فقط از IP هایی درخواست قبول می کنن که قبلاً ثبت شده. اگه سرور جدیدی که بکاپ روش برمی گرده IP متفاوتی داشته باشه، ممکنه با خطایی مثل نامعتبر بودن آدرس سرور روبه رو بشی. راهش هم تغییر کد نیست؛ باید IP جدید رو به بانک یا شرکت درگاه اعلام کنی. پس توی برنامه بازگردانی ات بنویس که IP جدید باید ثبت بشه و زمان این کار رو هم حساب کن. اگه بعد از بازگردانی سفارش ها ثبت نمی شن، مشکل بازگشت از درگاه پرداخت راهنمای خوبی برای پیدا کردن علته.

هر چند وقت امتحان کنم؟

دست کم یه بار بعد از راه اندازی بکاپ، بعدش هر چند ماه یه بار، و هر بار که ساختار سرور یا دیتابیس تغییر بزرگی کرد. برنامه پیچیده ای نمی خواد، یه یادآور توی تقویم کافیه.

اشتباه هایی که زیاد می بینیم

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

سوالات متداول

بکاپ خودکار پنل هاستینگ یا اسنپ شات سرویس دهنده برای من کافیه؟

برای شروع خوبه، ولی معمولاً کافی نیست. این نسخه ها اغلب توی همون زیرساخت یا همون حساب نگهداری می شن و اگه مشکل از خود حساب باشه، از دست می رن. بهتره یه نسخه مستقل بیرون از اون سرویس هم داشته باشی و بازگردانی شون رو امتحان کنی.

بکاپ خودکار سرور چقدر فضا لازم داره؟

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

بکاپ حجیم رو با اینترنت ایران چطور بفرستم؟

ارسال به مقصد داخلی معمولاً مشکل خاصی نداره. برای مقصد خارجی، پهنای باند بین المللی ممکنه کند یا ناپایدار باشه. از ابزاری استفاده کن که ارسال نیمه کاره رو ادامه بده (مثل rsync با گزینه --partial)، بکاپ افزایشی بگیر و ارسال رو توی ساعت کم ترافیک انجام بده.

اگه سایت وردپرس ساده دارم، باز هم این همه کار لازمه؟

اصولش همونه، ولی ابزارش ساده تر می شه: بکاپ دیتابیس، پوشه wp-content و فایل wp-config.php با افزونه یا اسکریپت، و یه نسخه بیرون از هاست. فقط بازگردانی رو یه بار امتحان کن. ورود دو مرحله ای برای وردپرس و سی پنل هم کمک می کنه کسی راحت به پنل و بکاپ ها دست پیدا نکنه.

فردا صبح از کجا شروع کنم؟

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

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