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

در این آموزش، از فایل‌های سایت و تنظیمات Nginx با Restic بکاپ می‌گیریم، نسخه‌ها را روی یک سرور جدا نگه می‌داریم و اجرای روزانه را خودکار می‌کنیم. آخر کار هم یک فایل را برمی‌گردانیم؛ چون دیدن پیام «بکاپ موفق بود» به‌تنهایی کافی نیست.

قبل از شروع، مشخص کنید چه چیزی باید برگردد

بکاپ خوب از یک سؤال ساده شروع می‌شود: اگر همین الان VPS از دسترس خارج شود، برای راه‌اندازی دوباره سایت به چه چیزهایی نیاز داریم؟

بخش	نمونه مسیر	نکته مهم
فایل‌های سایت	`/var/www`	مسیر واقعی پروژه و فایل‌های آپلودی را بررسی کنید.
تنظیمات وب‌سرور	`/etc/nginx`	فایل‌های Virtual Host و تنظیمات مشترک را فراموش نکنید.
دیتابیس	خروجی ابزار خود دیتابیس	کپی فایل‌های دیتابیسِ در حال اجرا، جای بکاپ سازگار را نمی‌گیرد.
تنظیمات پروژه	فایل‌های پیکربندی و Secrets	دسترسی محدود و ذخیره رمزگذاری‌شده لازم دارند.

سناریوی فرمان‌های این مقاله فایل سایت و تنظیمات Nginx است. اگر سایت شما MySQL، PostgreSQL یا داده داخل Docker دارد، مرحله تهیه خروجی سازگار آن سرویس را جدا اضافه کنید. این اسکریپت به‌تنهایی بکاپ کامل وردپرس یا یک دیتابیس زنده نیست.

[!IMPORTANT]
🚨 هشدار: بکاپ روی همان دیسک VPS، با حذف یا خرابی آن دیسک از بین می‌رود. مقصد این آموزش یک حساب SSH/SFTP روی ماشینی مستقل است.

۱. پیش‌نیازها و نصب Restic

به Ubuntu با دسترسی sudo، یک حساب روی مقصد پشتیبان، فضای کافی و اتصال SSH نیاز دارید. در مثال‌ها backup.example.com و backupuser جایگزین هستند؛ آن‌ها را با مقصد خودتان عوض کنید.

sudo apt update
sudo apt install restic openssh-client cron util-linux
sudo systemctl enable --now cron
restic version

ادامه تنظیمات را در نشست root انجام می‌دهیم تا دسترسی خواندن فایل‌های سایت و اجرای زمان‌بندی یکسان باشد:

sudo -i
install -d -m 700 /root/.ssh /etc/restic
ssh-keygen -t ed25519 -f /root/.ssh/netzo_backup

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

کلید عمومی را روی حساب مقصد نصب کنید:

ssh-copy-id -i /root/.ssh/netzo_backup.pub backupuser@backup.example.com
nano /root/.ssh/config

این بخش را به تنظیمات SSH اضافه کنید:

Host netzo-backup
    HostName backup.example.com
    User backupuser
    IdentityFile /root/.ssh/netzo_backup
    IdentitiesOnly yes
    BatchMode yes

chmod 600 /root/.ssh/config
ssh netzo-backup 'mkdir -p restic/netzo'

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

۲. ساخت مخزن رمزگذاری‌شده

رمز مخزن را داخل فایل اختصاصی بگذارید:

nano /etc/restic/password
chmod 600 /etc/restic/password
nano /etc/restic/env

محتوای فایل env:

export RESTIC_REPOSITORY='sftp:netzo-backup:restic/netzo'
export RESTIC_PASSWORD_FILE='/etc/restic/password'

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

chmod 600 /etc/restic/env
source /etc/restic/env
restic init

[!NOTE]
ℹ️ نکته: رمز مخزن را در یک محل امن و مستقل هم نگه دارید. اگر سرور اصلی و تنها نسخه رمز را با هم از دست بدهید، دسترسی به فایل‌های بکاپ مشکل شما را حل نمی‌کند.

۳. اولین بکاپ و بررسی نتیجه

اول مطمئن شوید مسیرهای مثال همان مسیرهای واقعی شما هستند:

ls -ld /var/www /etc/nginx
restic backup /var/www /etc/nginx --tag netzo-files
restic snapshots --tag netzo-files

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

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

۴. اجرای روزانه بدون اجرای هم‌زمان

فایل زیر را بسازید:

nano /usr/local/sbin/netzo-backup

#!/bin/bash
set -euo pipefail
umask 077
export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
source /etc/restic/env
restic backup /var/www /etc/nginx --tag netzo-files

chmod 700 /usr/local/sbin/netzo-backup
/usr/local/sbin/netzo-backup
crontab -e

به Crontab کاربر root اضافه کنید:

0 3 * * * /usr/bin/flock -n /run/lock/netzo-restic.lock /bin/bash -c 'umask 077; /usr/local/sbin/netzo-backup >> /var/log/netzo-backup.log 2>&1'

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

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

۵. نگهداری نسخه‌ها؛ ابتدا پیش‌نمایش، بعد حذف

برای نمونه، سیاست نگهداری هفت نسخه روزانه، چهار نسخه هفتگی و سه نسخه ماهانه را پیش‌نمایش کنید:

source /etc/restic/env
restic forget --tag netzo-files --keep-daily 7 --keep-weekly 4 --keep-monthly 3 --dry-run

خروجی را بخوانید. اگر نسخه‌های باقی‌مانده با نیاز شما همخوانی داشتند، همان فرمان را بدون --dry-run و همراه --prune اجرا کنید. این مرحله نسخه‌های مشمول حذف را واقعاً حذف می‌کند؛ در نمونه زمان‌بندی بالا عمداً خودکار نشده است.

۶. بازیابی را همین حالا امتحان کنید

شناسه Snapshot موردنظر را از فهرست بردارید و به جای SNAPSHOT_ID بگذارید:

restic snapshots --tag netzo-files
restic check
install -d -m 700 /root/restore-test
restic restore SNAPSHOT_ID --target /root/restore-test

فایل‌های /var/www در مسیر /root/restore-test/var/www قرار می‌گیرند. یک فایل آشنا را باز و با نسخه اصلی مقایسه کنید. فضای آزاد مقصد بازیابی را هم قبل از شروع بررسی کنید.

restic check به‌تنهایی معادل خواندن تمام محتوای بکاپ نیست. برای بررسی کامل داده‌ها، restic check --read-data در نظر گرفته شود؛ این کار می‌تواند زمان و ترافیک قابل توجهی مصرف کند.

[!TIP]
💡 پیشنهاد عملی: تاریخ آخرین بکاپ موفق، تاریخ آخرین بازیابی آزمایشی و محل نگهداری رمز را در یادداشت عملیاتی تیم ثبت کنید. روز حادثه وقت پیدا کردن این اطلاعات نیست.

پرسش‌های رایج

اگر اینترنت قطع شود، بکاپ چه می‌شود؟

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

Snapshot ارائه‌دهنده جای این بکاپ را می‌گیرد؟

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

رمز مخزن را می‌توان روی همان سرور نگه داشت؟

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

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

منابع و مطالعه بیشتر

# بکاپ سرور

آموزش بکاپ‌گیری خودکار از VPS اوبونتو با Restic؛ از ذخیره تا بازیابی