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

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

چرا بکاپ در سرور اختصاصی هتزنر حیاتی است

حتی اگر بهترین تنظیمات امنیتی را داشته باشید، باز هم خطرهایی مثل موارد زیر وجود دارند:
اشتباه انسانی (حذف فایل یا دیتابیس، اجرای دستور اشتباه)
خرابی دیسک یا مشکل فایل‌سیستم
آلودگی به بدافزار یا باج‌افزار
مشکلات نرم‌افزاری بعد از آپدیت‌ها
خرابی دیتابیس یا جدول‌ها
حمله و نفوذ یا دسترسی غیرمجاز

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

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

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

استراتژی‌های رایج بکاپ برای سرور اختصاصی هتزنر

۱) بکاپ کامل (Full Backup)
همه چیز را یکجا بکاپ می‌گیرید. ساده است، ولی حجم بالایی دارد و زمان‌بر است.

۲) بکاپ افزایشی (Incremental)
فقط تغییرات نسبت به آخرین بکاپ ذخیره می‌شود. سریع‌تر و کم‌حجم‌تر است، ولی برای ریکاوری باید زنجیره بکاپ‌ها سالم باشد.

۳) بکاپ تفاضلی (Differential)
تغییرات نسبت به آخرین بکاپ کامل ذخیره می‌شود. حجمش از افزایشی بیشتر است ولی ریکاوری ساده‌تر می‌شود.

در میزبانی حرفه‌ای (Hosting)، معمولاً ترکیب بهترین حالت است: یک بکاپ کامل هفتگی + بکاپ افزایشی روزانه.

چه چیزهایی را باید بکاپ بگیریم

برای بیشتر سرورها این موارد حیاتی‌اند:
فایل‌های وب‌سایت (public_html یا مسیر پروژه)
دیتابیس‌ها (MySQL/MariaDB/PostgreSQL)
فایل‌های تنظیمات (nginx, apache, php, ssh, firewall)
فایل‌های مهم سیستم (crontab، تنظیمات سرویس‌ها، env ها)
اگر سرور ایمیل دارید: mailbox ها و تنظیمات mail server

بکاپ فایل‌ها با rsync

برای بکاپ فایل‌ها، rsync یکی از بهترین ابزارهاست چون سریع و قابل اعتماد است و فقط تغییرات را منتقل می‌کند.

rsync -aHAX –delete /var/www/ /backup/www/

اگر می‌خواهید بکاپ را روی سرور یا فضای دیگری بفرستید:

rsync -aHAX –delete -e “ssh -p 22” /var/www/ user@backupserver:/data/backups/www/

بکاپ دیتابیس MySQL/MariaDB با mysqldump

برای بکاپ گرفتن از دیتابیس:

mysqldump -u root -p –single-transaction –routines –triggers –all-databases > /backup/db/all_databases.sql

فشرده‌سازی بکاپ دیتابیس برای کاهش حجم:

gzip -c /backup/db/all_databases.sql > /backup/db/all_databases.sql.gz

یا مستقیم:

mysqldump -u root -p –single-transaction –routines –triggers –all-databases | gzip > /backup/db/all_databases.sql.gz

بکاپ دیتابیس PostgreSQL با pg_dumpall

pg_dumpall -U postgres | gzip > /backup/db/pg_all.sql.gz

رمزنگاری بکاپ‌ها برای امنیت بیشتر

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

gpg –symmetric –cipher-algo AES256 /backup/db/all_databases.sql.gz

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

اتوماتیک کردن بکاپ با cron

یک اسکریپت بکاپ بسازید:

nano /usr/local/bin/backup.sh

محتوا نمونه:

mkdir -p /backup/www
mkdir -p /backup/db
rsync -aHAX –delete /var/www/ /backup/www/
mysqldump -u root -pYOURPASSWORD –single-transaction –routines –triggers –all-databases | gzip > /backup/db/all_databases.sql.gz
find /backup/ -type f -mtime +7 -delete

به فایل اجازه اجرا بدهید:

chmod +x /usr/local/bin/backup.sh

حالا کرون‌جاب روزانه:

crontab -e

۰۲:۳۰ بامداد هر روز:

30 2 * * * /usr/local/bin/backup.sh >/dev/null 2>&1

انتقال بکاپ به فضای جدا از سرور هتزنر

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

انتقال با rsync به سرور بکاپ:

rsync -aHAX –delete -e “ssh” /backup/ user@backupserver:/data/hetzner-backups/

نکته مهم در پرداخت‌ها و سفارش سرویس هتزنر

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

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

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

ریستور MySQL:

gunzip < /backup/db/all_databases.sql.gz | mysql -u root -p

ریستور فایل‌ها:

rsync -aHAX /backup/www/ /var/www/

جمع‌بندی

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