بک‌آپ خودکار سرور با Restic روی فضای ذخیره‌سازی ابری

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

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

در این راهنما Restic را روی Ubuntu 24.04/26.04 یا Debian 13 نصب می‌کنیم، یک مخزن رمزنگاری‌شده روی فضای ذخیره‌سازی سازگار با S3 می‌سازیم، بک‌آپ روزانه را با تایمر systemd خودکار می‌کنیم و مهم‌تر از همه، بازیابی را تمرین می‌کنیم.

پیش‌نیازها

• یک سرور ابری با دسترسی root.
• یک فضای ذخیره‌سازی سازگار با S3 (باکت، آدرس endpoint، access key و secret key). می‌توانید از مسیر SFTP یا یک سرور دوم هم استفاده کنید؛ فرمان‌ها یکسان‌اند و فقط آدرس مخزن فرق می‌کند.
• یک رمز عبور قوی برای مخزن که آن را جایی بیرون از سرور نگه دارید.

قاعده‌ی ۳-۲-۱ را در ذهن داشته باشید: سه نسخه از داده، روی دو رسانه‌ی متفاوت، که یکی از آن‌ها خارج از سرور اصلی باشد. اسنپ‌شات کنترل پنل ابر سپهر نسخه‌ی سریع و در-دسترس شماست؛ آنچه در این مقاله می‌سازیم، همان نسخه‌ی خارج از سرور است.

گام ۱: نصب Restic

apt update
apt install -y restic
restic version

اگر نسخه‌ی مخزن توزیع برای شما قدیمی است، Restic یک باینری تک‌فایلی هم منتشر می‌کند و پس از نصب می‌تواند خودش را به‌روز کند:

restic self-update

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

گام ۲: ساخت فایل تنظیمات محیطی

Restic آدرس مخزن، رمز و کلیدهای دسترسی را از متغیرهای محیطی می‌خواند. آن‌ها را در یک فایل جدا می‌گذاریم تا هم در ترمینال و هم در سرویس systemd قابل‌استفاده باشند:

nano /root/.restic-env

با این محتوا:

RESTIC_REPOSITORY=s3:https://s3.example.com/my-backup-bucket
RESTIC_PASSWORD_FILE=/root/.restic-password
AWS_ACCESS_KEY_ID=YOUR_ACCESS_KEY
AWS_SECRET_ACCESS_KEY=YOUR_SECRET_KEY

سپس رمز مخزن را در فایل جداگانه بگذارید و دسترسی هر دو فایل را ببندید:

openssl rand -base64 32 > /root/.restic-password
chmod 600 /root/.restic-password /root/.restic-env

chmod 600 یعنی فقط root می‌تواند این فایل‌ها را بخواند. اگر روی سرور کاربران دیگری دارید، این خط را جدی بگیرید: هر کسی که این دو فایل را بخواند، به کل تاریخچه‌ی بک‌آپ‌های شما دسترسی دارد.

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

گام ۳: ساخت مخزن

متغیرها را در نشست فعلی بارگذاری و مخزن را بسازید:

set -a && . /root/.restic-env && set +a
restic init

set -a باعث می‌شود متغیرهای فایل به‌صورت خودکار export شوند. restic init ساختار مخزن را روی باکت می‌سازد و کلید اصلی رمزنگاری را با رمز شما محافظت می‌کند. اگر پیام خطای دسترسی گرفتید، معمولاً یا نام باکت اشتباه است یا کلید دسترسی مجوز نوشتن ندارد.

گام ۴: اولین بک‌آپ

restic backup /etc /root /var/www /opt \
  --exclude-caches \
  --exclude '/var/www/*/cache' \
  --one-file-system \
  --tag system

معنی سوئیچ‌های مهم:

• --exclude-caches پوشه‌هایی را که استاندارد CACHEDIR.TAG دارند رد می‌کند؛ بک‌آپ کش هیچ ارزشی ندارد و فقط حجم و زمان می‌برد.
• --one-file-system جلوی رفتن به مسیرهای mount‌شده مثل /proc یا فضای شبکه را می‌گیرد.
• --tag برچسبی است که بعداً برای فیلتر کردن و سیاست نگه‌داری به کار می‌آید.

اجرای اول کل داده را می‌فرستد و ممکن است طول بکشد؛ اجراهای بعدی فقط بخش‌های تغییرکرده را می‌فرستند و معمولاً چند ثانیه بیشتر طول نمی‌کشند. برای دیدن نتیجه:

restic snapshots

اگر پهنای باند سرور محدود است یا نمی‌خواهید بک‌آپ روی سرویس‌های زنده اثر بگذارد، سرعت آپلود را محدود کنید:

restic backup /var/www --limit-upload 5120

عدد بر حسب کیلوبایت بر ثانیه است؛ مقدار بالا یعنی سقف ۵ مگابایت بر ثانیه.

گام ۵: بک‌آپ پایگاه داده به‌روش درست

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

runuser -u postgres -- pg_dumpall | \
  restic backup --stdin --stdin-filename postgres-all.sql --tag db

--stdin به Restic می‌گوید ورودی را از خروجی دستور قبلی بگیرد و --stdin-filename نامی است که این نسخه در مخزن خواهد داشت. مزیت این روش نسبت به ساختن فایل موقت این است که dump هیچ‌وقت روی دیسک سرور نوشته نمی‌شود؛ نه فضا مصرف می‌کند و نه ردی از داده‌ی بی‌رمز باقی می‌گذارد.

برای MariaDB و MySQL همین الگو برقرار است:

mysqldump --all-databases --single-transaction | \
  restic backup --stdin --stdin-filename mysql-all.sql --tag db

سوئیچ --single-transaction باعث می‌شود dump یک تصویر یکدست از داده بگیرد بدون آن‌که جدول‌ها را قفل کند. اگر PostgreSQL شما تازه راه‌اندازی شده، جزئیات کاربر و دسترسی‌ها در راهنمای نصب PostgreSQL روی اوبونتو آمده است.

بک‌آپ داده‌های کانتینرهای داکر

اگر سرویس‌هایتان با داکر اجرا می‌شوند، داده‌ی مهم در یکی از این دو جاست: پوشه‌هایی که با bind mount به کانتینر داده‌اید (مثل /opt/npm/data در Nginx Proxy Manager) یا والیوم‌های نام‌دار داکر. پوشه‌ها را کافی است در فهرست مسیرهای بک‌آپ بگذارید، اما والیوم‌ها زیر /var/lib/docker/volumes/ قرار دارند و بک‌آپ مستقیم از آن‌ها در حالی که کانتینر در حال نوشتن است، همان ریسک پایگاه داده‌ی زنده را دارد.

امن‌ترین کار برای سرویس‌های حساس، توقف کوتاه کانتینر پیش از بک‌آپ است:

docker stop npm
restic backup /opt/npm --tag docker
docker start npm

برای سرویس‌هایی که توقفشان ممکن نیست، ابتدا از پایگاه داده‌ی داخل کانتینر dump بگیرید (همان الگوی بالا با docker exec) و سپس فایل‌ها را بک‌آپ کنید.

گام ۶: اسکریپت بک‌آپ و زمان‌بندی با systemd

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

nano /usr/local/bin/restic-backup.sh

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

restic backup /etc /root /var/www /opt \
  --exclude-caches --one-file-system --tag system

runuser -u postgres -- pg_dumpall | \
  restic backup --stdin --stdin-filename postgres-all.sql --tag db

restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

خط set -euo pipefail مهم‌تر از چیزی است که به‌نظر می‌رسد: با آن، اگر هر مرحله شکست بخورد اسکریپت متوقف می‌شود و systemd خطا را ثبت می‌کند. بدون آن، یک بک‌آپ شکست‌خورده ممکن است ماه‌ها بی‌سروصدا ادامه پیدا کند.

اسکریپت را اجرایی کنید و سرویس systemd را بسازید:

chmod +x /usr/local/bin/restic-backup.sh
nano /etc/systemd/system/restic-backup.service

[Unit]
Description=Restic backup
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
EnvironmentFile=/root/.restic-env
ExecStart=/usr/local/bin/restic-backup.sh

و تایمر آن:

nano /etc/systemd/system/restic-backup.timer

[Unit]
Description=Daily restic backup

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

[Install]
WantedBy=timers.target

Persistent=true یعنی اگر سرور در ساعت مقرر خاموش بوده، اجرا در اولین فرصت پس از روشن شدن انجام می‌شود؛ RandomizedDelaySec هم از هجوم هم‌زمان چند سرور به فضای ذخیره‌سازی جلوگیری می‌کند. حالا تایمر را فعال کنید:

systemctl daemon-reload
systemctl enable --now restic-backup.timer
systemctl list-timers restic-backup.timer

برای یک اجرای آزمایشی فوری و دیدن لاگ:

systemctl start restic-backup.service
journalctl -u restic-backup.service -n 50

گام ۷: سیاست نگه‌داری و سلامت مخزن

دستور forget در اسکریپت، سیاست نگه‌داری شما را اعمال می‌کند: هفت نسخه‌ی روزانه، چهار نسخه‌ی هفتگی و شش نسخه‌ی ماهانه. --prune هم داده‌هایی را که دیگر به هیچ نسخه‌ای تعلق ندارند از مخزن پاک می‌کند و فضا آزاد می‌کند.

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

set -a && . /root/.restic-env && set +a
restic check --read-data-subset=10%

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

اگر اجرای قبلی نیمه‌کاره قطع شده باشد، ممکن است مخزن قفل بماند:

restic unlock

گام ۸: تمرین بازیابی

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

restic snapshots
restic restore latest --target /tmp/restore-test

latest آخرین نسخه است و می‌توانید به‌جای آن شناسه‌ی هر نسخه را بگذارید. بازیابی در مسیر موقت (نه روی /) کاری امن است که هر ماه می‌توانید انجامش دهید.

برای بازیابی فقط یک مسیر مشخص:

restic restore latest --target /tmp/restore-test --include /var/www/site

و برای بازگرداندن پایگاه داده:

restic dump latest postgres-all.sql | runuser -u postgres -- psql

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

نگهداری: به‌روزرسانی و بک‌آپ

Restic خودش ابزار نگهداری است، اما دو عادت آن را قابل‌اعتماد می‌کند: مرور ماهانه‌ی لاگ تایمر و یک تمرین بازیابی. اگر سرور را جابه‌جا یا بازسازی کردید، فراموش نکنید که فایل /root/.restic-env و رمز مخزن باید دوباره ساخته شوند.

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

جمع‌بندی

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

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

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