بکاپ‌گیری حرفه‌ای در سرور اختصاصی لینوکس با زمان‌بندی و امنیت بالا

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

مرحله اول: شناسایی سناریوهای بکاپ در سرور اختصاصی

سناریوی اول: بکاپ‌گیری در زمان فعال بودن سرویس‌ها

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

سناریوی دوم: حجم بالای داده و محدودیت منابع سرور

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

سناریوی سوم: نیاز به بکاپ‌گیری کاملا خودکار و زمان‌بندی‌شده

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

سناریوی چهارم: محدودیت شبکه و لزوم نگهداری بکاپ داخل ایران

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

سناریوی پنجم: حساسیت امنیتی فایل‌های بکاپ

در این سناریو فرض بر این است که فایل‌های بکاپ خود می‌توانند هدف دسترسی غیر مجاز قرار گیرند. بنابراین از ابتدا باید رمزگذاری محدودسازی دسترسی و جداسازی کاربر بکاپ در طراحی لحاظ شود. این نگاه باعث می‌شود امنیت بکاپ هم سطح امنیت داده‌های اصلی سرور در نظر گرفته شود.

در پایان این مرحله مدیر سرور باید بداند سرور او در کدام یک از این سناریوها یا ترکیبی از آن‌ها قرار دارد. این شناخت مبنای انتخاب ابزار، روش اجرا و تنظیمات بکاپ در مراحل بعدی مقاله خواهد بود.

📷 جای تصویر مرحله اول (نمونه جدول سناریو و هدف بکاپ)

مرحله دوم: تعیین سیاست بکاپ

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

1. اولین نسخه باید روی خود سرور نگهداری شود تا در صورت بروز مشکلات جزئی امکان بازیابی سریع بدون نیاز به انتقال داده فراهم باشد. این نسخه بیشتر برای بازیابی‌های فوری و کم ریسک استفاده می‌شود.
2. نسخه دوم باید روی فضای بکاپ اختصاصی ایران‌سرور داخل ایران نگهداری شود تا در زمان قطعی اینترنت یا محدودیت‌های شبکه همچنان دسترسی به بکاپ امکان پذیر باشد. این نسخه نقش اصلی را در سناریوهای بحرانی ایفا می‌کند که ارتباط با سرویس‌های خارجی برقرار نیست.
3. نسخه سوم باید در یک محل دیگر داخل ایران یا روی یک فضای ذخیره سازی کاملا جدا نگهداری شود تا در بدترین حالت ممکن که سرور اصلی و فضای بکاپ نزدیک به آن دچار مشکل می‌شوند یک نسخه امن و مستقل وجود داشته باشد. این تفکیک فیزیکی یا منطقی بخش مهمی از طراحی بکاپ اصولی است.

در کنار محل نگهداری بکاپ لازم است از ابتدا سیاست نگهداری نسخه‌ها مشخص شود. مدیر سرور باید بداند هر بکاپ تا چه مدت باید حفظ شود و چه زمانی حذف شود. به طور معمول نگهداری حداقل ۷ نسخه بکاپ روزانه و ۴ نسخه بکاپ هفتگی برای سایت‌ها و سرویس‌های حساس یک حداقل منطقی محسوب می‌شود و امکان بازگشت به وضعیت سالم را در بازه‌های زمانی مختلف فراهم می‌کند.

مرحله سوم: ساختار مسیر و کاربر بکاپ را روی لینوکس آماده کنید

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

مسیر پیشنهادی روی لینوکس

شما باید یک مسیر استاندارد و ثابت برای نگهداری بکاپ تعریف کنید تا مدیریت و بازیابی آن ساده و قابل پیش بینی باشد. بهتر است این مسیر روی یک دیسک جدا یا یک مانت مستقل قرار گیرد تا بکاپ‌ها از داده‌های اصلی سرور جدا باشند و در صورت بروز مشکل روی دیسک اصلی از بین نروند. برای این منظور از کد زیر استفاده کنید:

sudo mkdir -p /srv/backup/{scripts,logs,tmp}
sudo chown -R root:root /srv/backup
sudo chmod 700 /srv/backup

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

کاربر اختصاصی برای اجرای بکاپ

شما باید یک کاربر بکاپ بسازید تا همه چیز با root انجام نشود.

sudo useradd -r -m -d /home/backup -s /usr/sbin/nologin backup
sudo mkdir -p /srv/backup
sudo chown -R backup:backup /srv/backup
sudo chmod 700 /srv/backup

اگر نیاز دارید بعضی فایل‌ها فقط با root خوانده شوند باید برای اسکریپت‌ها sudo محدود تعریف کنید.

مرحله چهارم: بکاپ فایل‌ها در لینوکس

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

روش ۱: بکاپ فایل محور با rsync برای سرعت و فشار کم

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

نمونه بکاپ برای سایت وردپرسی روی سرور لینوکسی

پوشه wp-content که شامل قالب‌ها، افزونه‌ها و فایل‌های رسانه‌ای است مهم‌ترین بخش سایت وردپرسی محسوب می‌شود و حتما باید در بکاپ قرار گیرد. علاوه بر آن فایل‌های کانفیگ سایت که اطلاعات اتصال به دیتابیس و تنظیمات اصلی را نگه می‌دارند نیز باید به طور کامل بکاپ گرفته شوند زیرا بدون این فایل‌ها سایت قابل اجرا نخواهد بود.

برای بکاپ فایل‌های سایت می‌توان از rsync استفاده کرد تا داده‌ها با کمترین فشار روی سرور کپی شوند و فایل‌های غیر ضروری مانند کش و لاگ‌ها در بکاپ قرار نگیرند.

sudo rsync -aHAX --delete \
  --exclude='cache/' --exclude='tmp/' --exclude='*.log' \
  /var/www/ /srv/backup/tmp/www/

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

sudo rsync -aHAX /etc/ /srv/backup/tmp/etc/
sudo rsync -aHAX /home/ /srv/backup/tmp/home/

بکاپ آرشیوی برای نگهداری نسخه‌ها

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

DATE="$(date +%F_%H%M)"
sudo tar --xattrs --acls -czf /srv/backup/server_files_${DATE}.tar.gz \
  /srv/backup/tmp/www /srv/backup/tmp/etc /srv/backup/tmp/home

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

sha256sum /srv/backup/server_files_${DATE}.tar.gz > /srv/backup/server_files_${DATE}.tar.gz.sha256

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

مرحله پنجم: بکاپ دیتابیس در لینوکس

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

حالت A: بکاپ‌گیری از MySQL یا MariaDB با mysqldump

این روش برای دیتابیس‌های کوچک و متوسط مناسب است و در اکثر سرورهای لینوکسی به صورت پیش فرض در دسترس قرار دارد. در این حالت بکاپ به صورت منطقی گرفته می‌شود و خروجی باید حتما فشرده شود تا حجم فایل بکاپ کاهش پیدا کند و انتقال و نگهداری آن ساده‌تر شود.

نمونه دستور بکاپ‌گیری به شکل زیر است:

DATE="$(date +%F_%H%M)"
DB_NAME="dbname"
DB_USER="dbuser"

mysqldump --single-transaction --routines --triggers --events \
  -u "$DB_USER" -p "$DB_NAME" | gzip > /srv/backup/db_${DB_NAME}_${DATE}.sql.gz

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

sha256sum /srv/backup/db_${DB_NAME}_${DATE}.sql.gz > /srv/backup/db_${DB_NAME}_${DATE}.sql.gz.sha256

نکته فنی مهم:
استفاده از گزینه --single-transaction برای جدول‌های InnoDB ضروری است زیرا باعث می‌شود بکاپ بدون قفل گذاری سنگین روی دیتابیس گرفته شود. اگر دیتابیس شما شامل جدول‌های MyISAM باشد بهتر است زمان بکاپ را در ساعات کم ترافیک تنظیم کنید چون این نوع جدول‌ها هنگام بکاپ قفل می‌شوند و می‌توانند روی عملکرد سرویس اثر بگذارند.

حالت B: بکاپ‌گیری از MySQL یا MariaDB با Percona XtraBackup برای دیتابیس‌های بزرگ

برای دیتابیس‌های بسیار بزرگ که گرفتن بکاپ منطقی زمان بر یا پرریسک است استفاده از بکاپ فیزیکی گزینه مناسب‌تری محسوب می‌شود. Percona XtraBackup این امکان را فراهم می‌کند که بدون توقف سرویس از دیتابیس بکاپ فیزیکی گرفته شود.

در این روش ابتدا باید ابزار XtraBackup را نصب کنید. نوع نصب به سیستم عامل و نسخه دیتابیس شما وابسته است و باید از مخزن رسمی Percona انجام شود. پس از نصب بکاپ فیزیکی گرفته می‌شود و در مرحله بعد عملیات prepare انجام می‌گیرد تا فایل‌ها برای بازیابی آماده شوند.

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

حالت C: بکاپ‌گیری از PostgreSQL با pg_dump و pg_dumpall

در سرورهایی که از PostgreSQL استفاده می‌کنند بکاپ‌گیری باید با ابزارهای اختصاصی خود دیتابیس انجام شود. برای بکاپ گرفتن از یک دیتابیس مشخص می‌توان از دستور pg_dump استفاده کرد و خروجی را در قالب فشرده ذخیره نمود.

DATE="$(date +%F_%H%M)"
DB_NAME="dbname"

sudo -u postgres pg_dump -Fc "$DB_NAME" > /srv/backup/pg_${DB_NAME}_${DATE}.dump
sha256sum /srv/backup/pg_${DB_NAME}_${DATE}.dump > /srv/backup/pg_${DB_NAME}_${DATE}.dump.sha256

در صورتی که نیاز به بکاپ کامل از همه دیتابیس‌ها و رول‌ها وجود داشته باشد باید از pg_dumpall استفاده شود. این روش برای نگهداری نسخه جامع از ساختار PostgreSQL کاربرد دارد.

DATE="$(date +%F_%H%M)"
sudo -u postgres pg_dumpall | gzip > /srv/backup/pg_all_${DATE}.sql.gz

مرحله ششم: بکاپ کامل سیستم در لینوکس

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

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

خروجی گرفتن از لیست پکیج‌های نصب شده

نگهداری لیست پکیج‌ها به شما کمک می‌کند در سرور جدید دقیقا همان نرم افزارها و وابستگی‌ها را دوباره نصب کنید. این موضوع به خصوص در سرورهایی که تنظیمات خاص یا ماژول‌های سفارشی دارند بسیار مهم است.

در سرورهای مبتنی بر Debian یا Ubuntu می‌توانید با دستور زیر لیست کامل پکیج‌های نصب شده را ذخیره کنید:

dpkg --get-selections > /srv/backup/pkg_list_$(date +%F).txt

در سرورهای مبتنی بر CentOS یا AlmaLinux نیز باید از دستور زیر استفاده شود:

rpm -qa > /srv/backup/pkg_list_$(date +%F).txt

این فایل در زمان بازیابی به عنوان مرجع نصب مجدد پکیج‌ها استفاده می‌شود و سرعت راه‌اندازی سرور جدید را به طور قابل توجهی افزایش می‌دهد.

بکاپ‌گیری از تنظیمات سرویس‌ها

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

وب سرورهایی مانند Nginx یا Apache تنظیمات حیاتی دارند که بدون آن‌ها سایت به شکل صحیح اجرا نخواهد شد. همچنین تنظیمات PHP و SSH نقش مستقیم در عملکرد و امنیت سرور دارند. نمونه بکاپ‌گیری از این تنظیمات به شکل زیر است:

sudo rsync -aHAX /etc/nginx/ /srv/backup/tmp/etc_nginx/
sudo rsync -aHAX /etc/apache2/ /srv/backup/tmp/etc_apache/
sudo rsync -aHAX /etc/php/ /srv/backup/tmp/etc_php/
sudo rsync -aHAX /etc/ssh/ /srv/backup/tmp/etc_ssh/

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

مرحله هفتم: تفکیک بکاپ با فضای اختصاصی داخل ایران

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

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

سناریوی پیشنهادی برای نگهداری بکاپ داخل ایران

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

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

انتقال امن بکاپ از سرور لینوکسی به مقصد بکاپ داخل ایران

برای انتقال امن ابتدا باید یک کلید SSH اختصاصی برای کاربر بکاپ ساخته شود. این کلید فقط برای عملیات بکاپ استفاده می‌شود و نباید برای ورودهای عمومی به سرور به کار رود.

sudo -u backup ssh-keygen -t ed25519 -f /home/backup/.ssh/id_ed25519 -N ""

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

sudo -u backup ssh-copy-id -i /home/backup/.ssh/id_ed25519.pub backup@BACKUP_IP

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

DATE="$(date +%F_%H%M)"
sudo -u backup rsync -aHAX --partial --inplace \
  /srv/backup/server_files_${DATE}.tar.gz \
  backup@BACKUP_IP:/srv/backup_repo/linux/

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

نکته مهم درباره سرور بکاپ

روی سرور بکاپ باید حتما یک دیسک جداگانه برای نگهداری مخزن بکاپ در نظر گرفته شود. این دیسک نباید با سرویس‌های دیگر مشترک باشد تا ریسک از دست رفتن داده کاهش یابد. همچنین دسترسی به مسیر بکاپ باید فقط به کاربر بکاپ محدود شود و سایر کاربران یا سرویس‌ها امکان مشاهده یا تغییر فایل‌های بکاپ را نداشته باشند.

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

مرحله هشتم: تنظیم زمان‌بندی بکاپ در لینوکس

بعد از مشخص شدن روش بکاپ‌گیری لازم است اجرای بکاپ به صورت منظم و خودکار انجام شود. بکاپی که به اجرای دستی وابسته باشد در عمل قابل اعتماد نیست. در سرورهای لینوکسی زمان بندی بکاپ معمولا با cron یا systemd انجام می‌شود. اگر سیستم عامل از systemd پشتیبانی می‌کند استفاده از Timer توصیه می‌شود چون امکان لاگ گیری دقیق‌تر، کنترل بهتر خطا و مدیریت ساده‌تر را فراهم می‌کند.

روش اول: زمان بندی بکاپ روزانه با cron

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

مسیر پیشنهادی اسکریپت به شکل زیر است:

/srv/backup/scripts/backup_daily.sh

محتوای نمونه اسکریپت می‌تواند به شکل زیر باشد:

#!/usr/bin/env bash
set -euo pipefail

DATE="$(date +%F_%H%M)"
LOG="/srv/backup/logs/backup_${DATE}.log"

echo "Start backup at $DATE" | tee -a "$LOG"

# 1) DB backup example (MySQL)
# mysqldump --single-transaction -u dbuser -p'PASSWORD' dbname | gzip > "/srv/backup/db_dbname_${DATE}.sql.gz"

# 2) Files backup
rsync -aHAX --delete /var/www/ /srv/backup/tmp/www/ >> "$LOG" 2>&1
tar --xattrs --acls -czf "/srv/backup/server_files_${DATE}.tar.gz" /srv/backup/tmp/www >> "$LOG" 2>&1
sha256sum "/srv/backup/server_files_${DATE}.tar.gz" > "/srv/backup/server_files_${DATE}.tar.gz.sha256"

echo "Done" | tee -a "$LOG"

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

sudo chmod 700 /srv/backup/scripts/backup_daily.sh
sudo chown root:root /srv/backup/scripts/backup_daily.sh

در مرحله بعد باید cron تنظیم شود تا اسکریپت در زمان مشخص اجرا گردد. برای مثال اجرای بکاپ هر روز ساعت ۳:۳۰ صبح به شکل زیر انجام می‌شود:

sudo crontab -e

و اضافه کردن خط زیر در فایل cron:

30 3 * * * /srv/backup/scripts/backup_daily.sh

با این تنظیم اسکریپت بکاپ به صورت روزانه و بدون نیاز به دخالت دستی اجرا خواهد شد.

روش دوم: استفاده از systemd timer برای کنترل بهتر

در سیستم‌هایی که از systemd استفاده می‌کنند تعریف Timer روش استانداردتر و حرفه‌ای‌تری برای زمان بندی بکاپ است. در این روش ابتدا باید یک Service برای اجرای اسکریپت بکاپ ایجاد شود.

فایل سرویس در مسیر زیر ساخته می‌شود:

/etc/systemd/system/backup-daily.service

محتوای فایل سرویس به شکل زیر است:

[Unit]
Description=Daily Backup Job

[Service]
Type=oneshot
ExecStart=/srv/backup/scripts/backup_daily.sh

سپس باید یک Timer برای اجرای این سرویس در زمان مشخص ایجاد شود.

/etc/systemd/system/backup-daily.timer

محتوای فایل Timer به شکل زیر است:

[Unit]
Description=Run Daily Backup at 03:30

[Timer]
OnCalendar=*-*-* 03:30:00
Persistent=true

[Install]
WantedBy=timers.target

بعد از ساخت این فایل‌ها لازم است systemd بازخوانی و Timer فعال شود.

sudo systemctl daemon-reload
sudo systemctl enable --now backup-daily.timer
sudo systemctl list-timers --all | grep backup

گزینه Persistent باعث می‌شود اگر سرور در زمان اجرای بکاپ خاموش بوده است بکاپ بعد از روشن شدن سیستم اجرا شود. این ویژگی برای سرورهایی که ممکن است ریبوت شوند بسیار مهم است.

مرحله نهم: تست بکاپ و اطمینان از قابلیت بازیابی

در این مرحله باید مطمئن شوید بکاپ‌هایی که تهیه شده‌اند واقعا قابل استفاده هستند. بررسی حجم فایل یا وجود فایل بکاپ به تنهایی کافی نیست و هیچ تضمینی برای سالم بودن داده‌ها ایجاد نمی‌کند. تنها روش مطمئن برای ارزیابی بکاپ انجام بازیابی واقعی در یک محیط تست است. اگر این مرحله نادیده گرفته شود در زمان بحران امکان دارد بکاپ‌ها عملا غیر قابل استفاده باشند.

تست اول: بررسی سلامت فایل بکاپ در لینوکس

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

sha256sum -c /srv/backup/server_files_2026-02-02_0827.tar.gz.sha256

بعد از تایید هش لازم است محتوای آرشیو بدون استخراج کامل بررسی شود. این کار مشخص می‌کند ساختار فایل سالم است و امکان باز کردن آن وجود دارد.

tar -tzf /srv/backup/server_files_2026-01-28_0330.tar.gz | head

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

sudo mkdir -p /srv/restore_test
sudo tar -xzf /srv/backup/server_files_2026-01-28_0330.tar.gz -C /srv/restore_test
ls -la /srv/restore_test | head

تست دوم: تست بازیابی دیتابیس MySQL یا MariaDB

برای اطمینان از سلامت بکاپ دیتابیس باید عملیات بازیابی روی یک دیتابیس تست انجام شود. ابتدا یک دیتابیس جدید برای تست ایجاد می‌شود و سپس بکاپ روی آن بازگردانی می‌گردد.

mysql -u root -p -e "CREATE DATABASE restore_test_db;"
gunzip -c /srv/backup/db_dbname_2026-01-28_0330.sql.gz | mysql -u root -p restore_test_db

بعد از اتمام بازیابی باید بررسی شود که جدول‌ها به درستی ایجاد شده‌اند و داده‌ها در دسترس هستند.

mysql -u root -p -e "SHOW TABLES FROM restore_test_db;" | head

اگر این مرحله انجام نشود در زمان بروز مشکل واقعی، ممکن است با دیتابیسی مواجه شوید که قابل بازگردانی نیست و این موضوع معمولا در بدترین زمان ممکن مشخص می‌شود.

تست سوم: تست بازیابی PostgreSQL

در سرورهایی که از PostgreSQL استفاده می‌کنند نیز باید بازیابی واقعی تست شود. ابتدا یک دیتابیس تست ایجاد می‌شود و سپس فایل بکاپ روی آن بازگردانی می‌گردد.

sudo -u postgres createdb restore_test_db
sudo -u postgres pg_restore -d restore_test_db /srv/backup/pg_dbname_2026-01-28_0330.dump

بعد از پایان بازیابی باید ساختار دیتابیس بررسی شود تا مطمئن شوید جدول‌ها به درستی ایجاد شده‌اند.

sudo -u postgres psql -d restore_test_db -c "\dt" | head

مرحله دهم: تنظیم موارد امنیتی بکاپ

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

امنیت بکاپ در لینوکس با تنظیم مالکیت و سطح دسترسی

در سرور لینوکسی دسترسی به مسیر بکاپ باید به شدت محدود شود. فقط کاربر بکاپ یا کاربر root باید امکان مشاهده و تغییر فایل‌های بکاپ را داشته باشد و سایر کاربران یا سرویس‌ها نباید هیچ دسترسی‌ای به این مسیر داشته باشند.

برای انجام این کار، ابتدا مالکیت پوشه بکاپ به کاربر مربوط به بکاپ داده می‌شود. سپس سطح دسترسی به شکلی تنظیم می‌شود که فقط همان کاربر بتواند به آن دسترسی داشته باشد.

sudo chown -R backup:backup /srv/backup
sudo chmod -R 700 /srv/backup

با این تنظیم هیچ کاربر دیگری حتی امکان لیست کردن محتویات مسیر بکاپ را نخواهد داشت و ریسک دسترسی ناخواسته به حداقل می‌رسد.

در برخی سناریوها ممکن است لازم باشد فایل‌های بکاپ بعد از ساخته شدن به هیچ وجه قابل تغییر نباشند. در این حالت می‌توان از ویژگی immutable استفاده کرد. این روش برای فایل‌های هش یا فایل‌هایی که نباید دستکاری شوند بسیار مفید است.

sudo chattr +i /srv/backup/*.sha256

با فعال بودن این ویژگی حتی کاربر root هم بدون حذف immutable قادر به تغییر فایل نخواهد بود.

رمزگذاری بکاپ قبل از انتقال

برای افزایش امنیت بکاپ لازم است فایل‌ها قبل از انتقال به مقصد رمزگذاری شوند. در این حالت حتی اگر فایل بکاپ در مسیر انتقال یا روی سرور بکاپ در اختیار فرد غیر مجاز قرار بگیرد امکان استفاده از آن وجود نخواهد داشت.

یکی از روش‌های ساده و قابل اعتماد برای رمزگذاری استفاده از gpg با الگوریتم متقارن است.

gpg --symmetric --cipher-algo AES256 /srv/backup/server_files_2026-01-28_0330.tar.gz

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

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

shred -u /srv/backup/server_files_2026-01-28_0330.tar.gz

این کار باعث می‌شود فایل اصلی به طور کامل از دیسک حذف شود و امکان بازیابی آن وجود نداشته باشد.

امنیت انتقال بکاپ با SSH و محدودسازی کلید

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

روی سرور بکاپ باید در فایل authorized_keys محدودیت‌هایی تعریف شود تا این کلید فقط برای انتقال بکاپ و اجرای rsync قابل استفاده باشد. این محدودسازی باید با دقت انجام شود تا هیچ دسترسی اضافه‌ای به سیستم ایجاد نشود. رعایت این موضوع از سوءاستفاده احتمالی از کلید بکاپ جلوگیری می‌کند.

مرحله یازدهم: خودکارسازی پاکسازی و نگهداری نسخه‌های بکاپ

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

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

نمونه حذف خودکار بکاپ‌های قدیمی در لینوکس

در سرورهای لینوکسی می‌توان با استفاده از دستور find فایل‌هایی که از بازه نگهداری مشخص عبور کرده‌اند را شناسایی و حذف کرد. برای مثال اگر سیاست شما نگهداری بکاپ‌ها به مدت ۱۴ روز باشد می‌توانید فایل‌های قدیمی‌تر از این بازه را به شکل زیر حذف کنید.

find /srv/backup -type f -name "*.tar.gz.gpg" -mtime +14 -delete
find /srv/backup -type f -name "*.sql.gz" -mtime +14 -delete
find /srv/backup/logs -type f -mtime +30 -delete

در این مثال فایل‌های بکاپ رمزگذاری شده و بکاپ‌های دیتابیس که بیش از ۱۴ روز از زمان ایجاد آن‌ها گذشته است حذف می‌شوند. همچنین فایل‌های لاگ قدیمی‌تر از ۳۰ روز نیز پاکسازی می‌گردند تا فضای اضافی اشغال نشود.

ادغام پاکسازی با فرایند بکاپ

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

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