آموزش پشتیبان‌گیری از سرور روی یک VPS مجزا

هدف پشتیبان‌گیری خارج از سایت (off-site) چیست

هدف پشتیبان‌گیری خارج از سایت، ماشینی ثانویه است که نسخه‌ای از داده‌های شما را نگهداری می‌کند و خرابی آن مستقل از سرور اصلی است. برای اکثر کاربران، یک VPS در یک ارائه‌دهنده دیگر، ارزان‌ترین گزینه ممکن است. سه ساختار واقع‌بینانه وجود دارد: اجرای Proxmox Backup Server روی VPS، استفاده از مخزن restic که از طریق SSH یا S3 در دسترس است، یا یک mirror با rsync که توسط میزبان پشتیبان‌گیری فراخوانی (pull) می‌شود. انتخاب گزینه مناسب به این بستگی دارد که چه چیزی را بازیابی می‌کنید و با چه سرعتی به آن نیاز دارید. تعیین اینکه چه کسی اجازه حذف نسخه پشتیبان را دارد، بقیه تصمیمات را مشخص می‌کند.

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

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

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

• Proxmox Backup Server (PBS): منبع آن Proxmox VE (محیط مجازی) است و آنچه بازیابی می‌کنید، یک ماشین مجازی کامل است. این ابزار در سطح image دیسک پشتیبان‌گیری می‌کند و کارهای verify آن، داده‌های موجود در مقصد را مجدداً می‌خوانند.
• مخزن restic: منبع آن یک یا چند میزبان Linux است و آنچه بازیابی می‌کنید، یک دایرکتوری یا dump پایگاه داده است. این ابزار در سمت کلاینت رمزنگاری را انجام می‌دهد و از پروتکل‌های SSH، S3 و پروتکل اختصاصی REST پشتیبانی می‌کند.
• استفاده از rsync روی SSH، که توسط میزبان پشتیبان‌گیری فراخوانی می‌شود: در این حالت، فایل‌ها در مقصد به صورت فایل‌های معمولی قرار می‌گیرند که با ls و cat قابل خواندن هستند و برای بازیابی آن‌ها نیازی به هیچ نرم‌افزار کلاینتی نیست.

اگر نمی‌توانید تصمیم بگیرید، از restic استفاده کنید. این ابزار پیش از خروج هر داده‌ای از ماشین، آن را رمزنگاری می‌کند و در مقصد تنها به یک حساب SSH و فضای دیسک نیاز دارد. راه‌اندازی پشتیبان‌گیری restic روی یک VPS سمت کلاینت را با جزئیات بیشتری بررسی می‌کند و مقایسه restic و BorgBackup در صورتی که از قبل Borg را اجرا می‌کنید، به شما در انتخاب کمک خواهد کرد.

تخمین اندازه مقصد: هزینه یک ماه نگهداری داده‌ها

دلیل کوچک‌تر بودن اعداد نسبت به انتظار کاربران، Deduplication است. ابزارهای restic و PBS هر دو فایل‌ها را به تکه‌هایی با اندازه متغیر تقسیم کرده و از هر تکه یک hash تهیه می‌کنند. هر تکه منحصربه‌فرد فقط یک بار ذخیره می‌شود. بنابراین، دومین نسخه پشتیبان از یک مجموعه داده 500 گیگابایتی، 500 گیگابایت دیگر به حجم اضافه نمی‌کند؛ بلکه فقط تکه‌های تغییریافته را ذخیره می‌کند.

در نتیجه، حجم مخزن (repository) با سن قدیمی‌ترین snapshot شما تعیین می‌شود، نه با تعداد snapshotها. فرض کنید 500 گیگابایت داده اولیه دارید و روزانه 5 گیگابایت داده جدید و منحصربه‌فرد اضافه می‌شود. مخزن در این حالت شامل 500 گیگابایت داده پایه، به‌علاوه تقریباً 5 گیگابایت برای هر روز تا قدیمی‌ترین snapshot موجود در سیاست نگهداری شما خواهد بود.

[
  {
    "label": "7 daily",
    "repo_size_gb": 535,
    "usd_at_10_per_tb": 5.35
  },
  {
    "label": "7 daily, 4 weekly",
    "repo_size_gb": 640,
    "usd_at_10_per_tb": 6.4
  },
  {
    "label": "7 daily, 4 weekly, 6 monthly",
    "repo_size_gb": "1,400",
    "usd_at_10_per_tb": 14.0
  },
  {
    "label": "7 daily, 4 weekly, 12 monthly",
    "repo_size_gb": "2,325",
    "usd_at_10_per_tb": 23.25
  }
]

ستون دلار در جدول، قیمت آن مخزن را 10 دلار آمریکا به ازای هر ترابایت در ماه محاسبه می‌کند. این عدد صرفاً یک جای‌گذار برای محاسبات است و قیمت پیشنهادی هیچ ارائه‌دهنده‌ای نیست؛ بنابراین قیمت واقعی هر ترابایت در طرحی که مد نظر دارید را جایگزین آن کنید. یک هفته نسخه پشتیبان روزانه حدود 535 گیگابایت فضا اشغال می‌کند. یک سال تاریخچه کامل، 2,325 گیگابایت فضا می‌گیرد که هزینه آن $23.25 در ماه است، در حالی که هزینه یک هفته $5.35 می‌باشد. تاریخچه ارزان است؛ شما در واقع هزینه کپی پایه را پرداخت می‌کنید.

Deduplication برای داده‌هایی که از قبل فشرده یا رمزنگاری شده‌اند، کارایی ندارد. یک dump دیتابیس که با gzip فشرده شده باشد، در هر بار اجرا کاملاً تغییر می‌کند؛ بنابراین هر dump به عنوان تکه‌های جدید ذخیره شده و مخزن هر شب به اندازه یک dump کامل رشد می‌کند. dumpها را به‌صورت فشرده‌نشده بنویسید و اجازه دهید ابزار پشتیبان‌گیری آن را فشرده کند، چرا که restic از نسخه 0.14 از مخازن فشرده پشتیبانی می‌کند و نسخه 0.19 نیز حالت‌های fastest و better zstd را اضافه کرده است. کتابخانه‌های عکس و ویدیو نیز به همین دلیل به‌خوبی dedupe نمی‌شوند؛ بنابراین حجم آن‌ها را بر اساس نرخ رشد واقعی‌شان محاسبه کنید، نه بر اساس ردیف‌های بالا.

در اینجا شما به جای CPU، دیسک بلااستفاده می‌خرید که دقیقاً همان موردی است که در آن یک storage VPS بهتر از یک VPS معمولی عمل می‌کند.

چرا پهنای باند و زمان بازیابی، تعیین‌کننده طرح هستند

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

[
  {
    "label": "40 Mbit/s home upload",
    "elapsed_h": 27.8
  },
  {
    "label": "100 Mbit/s",
    "elapsed_h": 11.1
  },
  {
    "label": "500 Mbit/s",
    "elapsed_h": 2.2
  },
  {
    "label": "1 Gbit/s VPS port",
    "elapsed_h": 1.1
  }
]

این ارقام، نرخ خط (line-rate) بدون در نظر گرفتن سربار پروتکل هستند، پس آن‌ها را به عنوان بهترین حالت در نظر بگیرید. با سرعت 100 Mbit/s، یک بازیابی کامل پیش از آنکه کسی به داده‌ها دسترسی پیدا کند، به 11.1 ساعت زمان نیاز دارد. با آپلود خانگی 40 Mbit/s، این زمان به 27.8 ساعت می‌رسد. روی یک پورت 1 Gbit/s، همان بازیابی در 1.1 ساعت انجام می‌شود. بسیاری از فایل‌های کوچک، کندتر از محاسبات ریاضی عمل می‌کنند، زیرا وقتی حجم فایل‌ها کمتر از چند صد کیلوبایت باشد، سربارِ هر فایل غالب می‌شود.

دو نتیجه حاصل می‌شود. اگر هدف زمان بازیابی (RTO) شما—یعنی قطعی که می‌توانید تحمل کنید—چهار ساعت باشد، بازیابی 500 گیگابایت روی یک لینک 100 Mbit/s از همین حالا این هدف را نقض کرده است و دیسک ارزان‌تر کمکی نمی‌کند. همچنین، اکثر طرح‌های VPS ترافیک خروجی را اندازه‌گیری می‌کنند، بنابراین یک بازیابی کامل، 0.5 ترابایت از سهمیه ماهانه میزبان پشتیبان را مصرف می‌کند. پیش از آنکه به داده‌ها نیاز پیدا کنید، آن سهمیه را بررسی کنید و ببینید وقتی از آن فراتر می‌روید، ارائه‌دهنده چه واکنشی نشان می‌دهد.

اولین پشتیبان‌گیری شامل کل مجموعه داده است و کندترین اجرایی خواهد بود که تا به حال انجام داده‌اید. آن را در روز جمعه شروع کنید و با محدود کردن نرخ (rate-limit)، از اشباع شدن لینک آپلود مبدأ جلوگیری کنید: restic از --limit-upload بر حسب KiB در ثانیه استفاده می‌کند و rsync از --bwlimit.

شکل 1: استفاده از Proxmox Backup Server به عنوان یک datastore راه دور

زمانی که منبع، Proxmox VE باشد و واحد بازیابی یک ماشین مجازی، PBS بهترین گزینه است. از آنجا که یک VPS نمی‌تواند فایل ISO مربوط به Proxmox را بوت کند، باید PBS را روی Debian نصب کنید. نسخه 4.2 که تا اوت 2026 نسخه جاری است، بر پایه Debian 13 (trixie) ساخته شده است.

wget https://enterprise.proxmox.com/debian/proxmox-archive-keyring-trixie.gpg \
  -O /usr/share/keyrings/proxmox-archive-keyring.gpg
sha256sum /usr/share/keyrings/proxmox-archive-keyring.gpg

این checksum را با مقداری که در صفحه مخازن بسته Proxmox منتشر شده است، مقایسه کنید. یک مخزن apt تنها به اندازه کلیدی که تأیید کرده‌اید قابل اعتماد است. سپس دستور /etc/apt/sources.list.d/proxmox.sources را اجرا کنید:

Types: deb
URIs: http://download.proxmox.com/debian/pbs
Suites: trixie
Components: pbs-no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg

sudo apt update && sudo apt install -y proxmox-backup-server
sudo proxmox-backup-manager datastore create offsite /mnt/datastore/offsite

برای datastore یک فایل‌سیستم یا volume مجزا در نظر بگیرید. پر شدن datastore باعث توقف عملیات پشتیبان‌گیری می‌شود و اگر datastore از فایل‌سیستم ریشه (root) استفاده کند، پر شدن آن کل سرور را از دسترس خارج می‌کند.

سپس، حسابی که منبع از آن استفاده خواهد کرد را ایجاد کنید و به جای رمز عبور، به آن یک token اختصاص دهید.

sudo proxmox-backup-manager user create backup@pbs
sudo proxmox-backup-manager user generate-token backup@pbs pve1
sudo proxmox-backup-manager acl update /datastore/offsite DatastoreBackup \
  --auth-id 'backup@pbs!pve1'

secret مربوط به token فقط یک بار نمایش داده می‌شود و دیگر قابل بازیابی نیست، بنابراین هنگام نمایش آن را ذخیره کنید. نقش (role) به اندازه خودِ token اهمیت دارد. DatastoreBackup می‌تواند پشتیبان‌های خود را ایجاد و بازیابی کند، اما فاقد دسترسی Datastore.Prune است؛ بنابراین این token نمی‌تواند snapshotهایی که قبلاً نوشته است را حذف کند.

سیاست نگهداری (Retention) در PBS دو بخش دارد که بخش دوم اغلب نادیده گرفته می‌شود. عملیات Prune، snapshotها را حذف می‌کند. عملیات Garbage collection، تکه‌هایی (chunks) که هیچ snapshot زنده‌ای به آن‌ها ارجاع نمی‌دهد را پاکسازی می‌کند. فضای آزاد پس از Garbage collection ظاهر می‌شود، نه پس از Prune.

proxmox-backup-client prune host/web1 \
  --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --dry-run
sudo proxmox-backup-manager garbage-collection start offsite
sudo proxmox-backup-manager verify offsite

پس از اینکه لیست snapshotهایی که قرار است حذف شوند را بررسی کردید، دستور --dry-run را اجرا کنید. Garbage collection در دو مرحله اجرا می‌شود: ابتدا زمان دسترسی (access time) تمام تکه‌هایی که هنوز به آن‌ها ارجاع داده شده است را به‌روزرسانی می‌کند، سپس تکه‌هایی که زمان دسترسی آن‌ها قدیمی‌تر از بازه تعیین‌شده باشد را حذف می‌کند. این بازه 24 ساعت و 5 دقیقه پیش از شروع عملیات است. این دوره تنفس (grace period) برای این است که تکه‌ای که در حال نوشته شدن توسط یک عملیات پشتیبان‌گیری فعال است، به اشتباه حذف نشود. عملیات Prune را به صورت روزانه و Garbage collection را به صورت هفتگی روی datastore زمان‌بندی کنید. همچنین یک job برای Verify اضافه کنید تا مقصد، تکه‌های خود را بازخوانی کرده و پیش از وقوع هرگونه بازیابی، خرابی‌های احتمالی روی دیسک را گزارش کند.

اگر منبع خود یک نمونه PBS باشد، سرور خارج از سایت (off-site) می‌تواند به جای دریافت داده (push)، خودش داده‌ها را بکشد (pull).

sudo proxmox-backup-manager remote create home1 \
  --host pbs.home.example --userid sync@pam --password 'SECRET' \
  --fingerprint '64:d3:ff:3a:50:38:53:5a:9b:f7:50:ab:fe'
sudo proxmox-backup-manager sync-job create home1-offsite \
  --remote home1 --remote-store main --store offsite --schedule 'Wed 02:30'

این sync job را روی VPS و در جهت پیش‌فرض (pull) اجرا کنید. VPS به datastore خانگی متصل می‌شود؛ این یعنی سرور خانگی هیچ اعتبارنامه‌ای که بتواند به نسخه خارج از سایت دسترسی داشته باشد، در اختیار ندارد.

شکل 2: مخزن restic روی SSH یا S3

توزیع‌های Debian و Ubuntu هر دو restic را در مخازن خود دارند، اما نسخه‌های آن‌ها از نسخه اصلی عقب‌تر است. نسخه 0.19.1 تا اوت 2026 نسخه جاری است. فایل باینری رسمی را روی میزبان مبدأ نصب کنید.

curl -LO https://github.com/restic/restic/releases/download/v0.19.1/restic_0.19.1_linux_amd64.bz2
bunzip2 restic_0.19.1_linux_amd64.bz2
sudo install -m 755 restic_0.19.1_linux_amd64 /usr/local/bin/restic
restic version

restic version نسخه و کامپایلر Go که با آن ساخته شده است را چاپ می‌کند. ارتقاهای بعدی با sudo restic self-update انجام می‌شود که روی فایل‌های باینری رسمی کار می‌کند و نه روی نسخه‌ای که از طریق apt نصب شده باشد.

روی VPS پشتیبان، یک حساب کاربری بسازید که هیچ دسترسی دیگری نداشته باشد، سپس کلید عمومی میزبان مبدأ را در /home/resticsrv/.ssh/authorized_keys کپی کنید.

sudo adduser --disabled-password --gecos '' resticsrv
sudo install -d -m 700 -o resticsrv -g resticsrv /srv/restic

مخزن را از سمت مبدأ و از طریق SFTP مقداردهی اولیه (Initialize) کنید.

sudo sh -c 'umask 077; head -c 32 /dev/urandom | base64 > /root/.restic-password'
export RESTIC_REPOSITORY='sftp:resticsrv@backup.example.net:/srv/restic/web1'
export RESTIC_PASSWORD_FILE=/root/.restic-password
restic init
restic backup /etc /srv /var/backups --exclude-caches

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

مدیریت نگهداری (Retention) تنها با یک دستور انجام می‌شود و نیمه دوم آن بخشی است که فضای دیسک را آزاد می‌کند.

restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
restic check --read-data-subset=10%

forget اسنپ‌شات‌ها را حذف می‌کند. prune فایل‌های pack که فقط توسط آن اسنپ‌شات‌ها ارجاع داده شده بودند را پاک می‌کند و --prune زمانی که واقعاً چیزی حذف شده باشد، این کار را به‌طور خودکار انجام می‌دهد. بدون این سوئیچ، حجم مخزن هرگز کاهش نمی‌یابد. restic check ساختار مخزن را تأیید می‌کند و --read-data-subset=10% یک‌دهم فایل‌های pack را دوباره می‌خواند و هش می‌کند، که خرابی داده‌ها در مقصد را بدون هزینه خواندن کل مخزن شناسایی می‌کند. فرم دیگر، --read-data-subset=1/10، یک دهم ثابت را بررسی می‌کند، بنابراین افزایش آن عدد اول در هر هفته، کل مخزن را در طول ده هفته پوشش می‌دهد.

اگر یک عملیات متوقف (kill) شود، عملیات بعدی با خطای repository is already locked exclusively by PID متوقف می‌شود. اطمینان حاصل کنید که هیچ پشتیبان‌گیری در حال اجرا نیست، سپس آن را با restic unlock پاکسازی کنید.

برای فضای ذخیره‌سازی شیء (Object Storage)، رشته مخزن به s3:https://s3.example.net/web1 تغییر می‌کند و اعتبارنامه‌ها در AWS_ACCESS_KEY_ID و AWS_SECRET_ACCESS_KEY قرار می‌گیرند. بقیه موارد کاملاً یکسان است؛ این همان روشی است که restic با یک سرویس ذخیره‌سازی شیء MinIO خودمیزبان که روی همان VPS اجرا می‌شود، ارتباط برقرار می‌کند.

شکل 3: استفاده از rsync روی SSH با کلید فقط‌خواندنی (pull-only)

ویژگی امنیتی این مدل، جهتِ برقراری ارتباط است. سرور پشتیبان (backup VPS) به منبع متصل شده و داده‌ها را می‌خواند. منبع هیچ کلیدی برای دسترسی به سرور پشتیبان ندارد و مسیری به آن نمی‌شناسد؛ بنابراین در صورت نفوذ به سرور منبع، مهاجم به هیچ‌وجه نمی‌تواند به نسخه‌های پشتیبان دسترسی پیدا کند.

یک جفت کلید روی سرور پشتیبان تولید کنید و سپس نیمه عمومی آن را با یک دستور اجباری (forced command) روی منبع نصب کنید.

command="rrsync -ro /srv",restrict ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA offsite-pull

ابزار rrsync در بستهٔ rsync در مسیر /usr/bin/rrsync در Debian 13 و Ubuntu 24.04 موجود است. دستور -ro فقط اجازهٔ خواندن می‌دهد و به‌طور ضمنی شامل -no-del است، بنابراین این کلید نمی‌تواند روی منبع چیزی بنویسد یا فایلی را حذف کند. دستور restrict ویژگی‌های غیرضروری SSH از جمله port forwarding و pty را غیرفعال می‌کند تا از این کلید برای ورود تعاملی (interactive login) استفاده نشود. مسیرها نسبت به دایرکتوری تعیین‌شده سنجیده می‌شوند، بنابراین مسیر راه دور / در واقع به /srv روی منبع اشاره دارد.

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

DEST=/srv/mirror/web1
TODAY=$(date +%F)
LAST=$(ls -1d "$DEST"/2* 2>/dev/null | tail -1)
LINK=""
if [ -n "$LAST" ]; then LINK="--link-dest=$LAST"; fi
rsync -aH --numeric-ids $LINK -e 'ssh -i /root/.ssh/pull_ed25519' \
  pull@web1.example.net:/ "$DEST/.$TODAY.partial/"
mv "$DEST/.$TODAY.partial" "$DEST/$TODAY"

تغییر نام در پایان عملیات، همان چیزی است که باعث می‌شود دایرکتوری‌های تاریخ‌دار قابل‌اعتماد باشند: نام دایرکتوری تنها پس از خروج موفقیت‌آمیز rsync (کد 0) ظاهر می‌شود، بنابراین انتقال‌های ناقص هرگز به شکل یک snapshot کامل دیده نمی‌شوند. درخت‌های قدیمی را با یک دستور تک‌خطی حذف کنید و 30 نسخهٔ آخر را نگه دارید.

ls -1d /srv/mirror/web1/2* | sort | head -n -30 | xargs -r rm -rf

در مورد هزینه‌های این مدل واقع‌بین باشید. hardlinkها فقط فایل‌های کامل را deduplicate می‌کنند؛ بنابراین تغییر یک بایت در یک image دیسک 4 گیگابایتی، باعث کپی شدن تمام 4 گیگابایت می‌شود، در حالی که ابزارهایی مانند restic و PBS فقط تکه‌های تغییریافته را ذخیره می‌کنند. همچنین، مقصد فایل‌های شما را به صورت متن آشکار (plaintext) نگه می‌دارد، بنابراین هر کسی که دسترسی root روی سرور پشتیبان داشته باشد، می‌تواند آن‌ها را بخواند.

رمزنگاری سمت کلاینت، به‌طوری که مقصد هرگز متن اصلی را نبیند

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

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

proxmox-backup-client key create /root/pbs-encryption.key
proxmox-backup-client backup root.pxar:/ --keyfile /root/pbs-encryption.key
proxmox-backup-client key paperkey --output-format text > qrkey.txt

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

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

جلوگیری از پاک‌سازی بک‌آپ‌ها توسط منبعِ در معرض خطر

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

PBS این مشکل را با استفاده از نقش‌ها حل می‌کند. توکنی که فقط دارای DatastoreBackup است، می‌تواند اسنپ‌شات‌های جدید بنویسد و اسنپ‌شات‌های خودش را بازیابی کند، اما نمی‌تواند عملیات پاک‌سازی (prune) را انجام دهد، زیرا حذف اسنپ‌شات نیازمند امتیاز جداگانه Datastore.Prune است. عملیات نگهداری (retention) را از سمت PBS اجرا کنید تا منبع هرگز اعتبارنامه‌ای که قادر به حذف چیزی باشد را در اختیار نداشته باشد.

ابزار restic روی SFTP چنین تفکیک امتیازی ندارد، زیرا کلید SSH که در مخزن می‌نویسد، می‌تواند از آن حذف هم انجام دهد. راه‌حل، استفاده از REST backend است. برنامه rest-server را روی VPS بک‌آپ با --append-only اجرا کنید؛ این کار اجازه ایجاد بک‌آپ‌های جدید را می‌دهد اما از حذف یا تغییر موارد موجود جلوگیری می‌کند. سپس کلاینت را با استفاده از RESTIC_REST_USERNAME و RESTIC_REST_PASSWORD به rest:https://backup.example.net:8000/web1 متصل کنید. در این حالت، یک restic forget --prune از سمت منبع با شکست مواجه می‌شود که نتیجه مطلوب است؛ بنابراین عملیات نگهداری باید از دستگاه دوم با اعتبارنامه مخصوص به خود اجرا شود. راهنمای restic همچنین توصیه می‌کند به جای سیاست‌های مبتنی بر تعداد در مخازن فقط‌-افزودنی (append-only)، از --keep-within استفاده کنید، زیرا در غیر این صورت مهاجمی که مخزن را با اسنپ‌شات‌های بی‌ارزش پر می‌کند، می‌تواند بک‌آپ‌های واقعی شما را از بازه --keep-last خارج کند.

ابزار rsync همین مشکل را به‌صورت ساختاری با روش pull حل می‌کند، زیرا منبع هیچ اعتبارنامه‌ای برای مقصد ندارد.

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

تمرین بازیابی را در تقویم خود ثبت کنید

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

restic snapshots
restic restore latest --target /var/tmp/restore-test --include /etc/nginx
diff -r /etc/nginx /var/tmp/restore-test/etc/nginx

diff -r چاپ نکردن هیچ خروجی به این معناست که درخت بازیابی‌شده با نسخه زنده مطابقت دارد. در PBS همین تمرین به صورت proxmox-backup-client restore host/web1/2026-08-13T02:30:00Z root.pxar /var/tmp/restore-test/ است، به علاوه یک job تایید زمان‌بندی‌شده که قطعات (chunks) را در مقصد دوباره می‌خواند و خرابی‌های checksum را گزارش می‌دهد.

این تمرین باید چیزی فراتر از سالم بودن بایت‌ها را اثبات کند.

• بازیابی را از یک ماشین سوم انجام دهید، نه از مبدأ؛ زیرا مبدأ دقیقاً همان چیزی است که فرض می‌کنید از دست رفته است. این یعنی رمز عبور مخزن یا کلید PBS باید بدون دسترسی به ماشین مبدأ قابل دستیابی باشد.
• زمان بازیابی را اندازه‌گیری و یادداشت کنید، سپس آن را با RTO که اعلام کرده‌اید مقایسه کنید. نمودار بالا کف نرخ انتقال را نشان می‌دهد. عدد واقعی شامل رمزگشایی، نوشتن روی دیسک و زمانی است که صرف پیدا کردن snapshot مورد نظر می‌کنید.
• چیزی که دارای وضعیت (state) است را بازیابی کنید، مانند dump پایگاه داده که سپس آن را در یک نمونه آزمایشی (scratch instance) بارگذاری می‌کنید. یک فایل tar که استخراج می‌شود، اثبات‌کننده این نیست که برنامه واقعاً اجرا می‌شود.

ارزان‌ترین دیسک دنیا تا زمانی که یک بار از روی آن بازیابی انجام نداده باشید، هیچ ارزشی ندارد.

FAQ

آیا اسنپ‌شات (snapshot) در پنل ارائه‌دهنده VPS، یک نسخه پشتیبان خارج از سایت (off-site) محسوب می‌شود؟

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

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

اندازه آن را بر اساس عمر قدیمی‌ترین اسنپ‌شات تعیین کنید، نه تعداد اسنپ‌شات‌ها. ابزارهای deduplication هر قطعه دادهٔ منحصربه‌فرد را فقط یک‌بار ذخیره می‌کنند؛ بنابراین حجم مخزن (repository) تقریباً برابر است با حجم داده‌های مبدأ به‌علاوه حاصل‌ضرب داده‌های جدیدِ روزانه در تعداد روزهای نگهداری. برای 500 گیگابایت داده که روزانه 5 گیگابایت تغییر می‌کند، یک هفته پشتیبان‌گیری روزانه حدود 535 گیگابایت و یک سال تاریخچه کامل حدود 2,325 گیگابایت فضا نیاز دارد. همیشه فضای اضافه در نظر بگیرید، زیرا پر شدن دیسک باعث شکست در پشتیبان‌گیری بعدی می‌شود و ابزاری مانند restic برای عملیات prune و بازسازی فایل‌های pack، به فضای خالی نیاز دارد تا بتواند فضا را آزاد کند.

آیا سروری که امنیت آن نقض شده (compromised) می‌تواند نسخه‌های پشتیبان خارج از سایت خود را حذف کند؟

بله، مگر اینکه سیستم را در برابر آن طراحی کرده باشید. با یک مخزن ساده SSH یا SFTP، کلیدی که اجازه نوشتن دارد، اجازه حذف نیز دارد. به ماشین مبدأ اعتبارنامه‌ای بدهید که نتواند داده‌ها را حذف کند: یک توکن API در PBS که فقط نقش DatastoreBackup را دارد و فاقد دسترسی Datastore.Prune است، یا استفاده از restic در مقابل rest-server که با پرچم --append-only اجرا شده و حذف یا تغییر نسخه‌های پشتیبان موجود را نمی‌پذیرد. طراحی مبتنی بر Pull (کشیدن داده) امنیت بیشتری دارد، زیرا در این حالت ماشین مبدأ هیچ اعتبارنامه‌ای برای دسترسی به میزبان پشتیبان ندارد. عملیات نگهداری (retention) را از سمتی اجرا کنید که ماشین مبدأ نیست.

آیا باید روی VPS پشتیبان، Proxmox Backup Server اجرا کنم یا restic؟

ابزار را بر اساس واحدی که می‌خواهید بازیابی کنید، انتخاب کنید. اگر مبدأ Proxmox VE است و می‌خواهید کل یک ماشین مجازی را بازیابی کنید، از PBS استفاده کنید؛ زیرا در سطح image دیسک پشتیبان می‌گیرد و VM را در یک مرحله بازیابی می‌کند. اگر مبدأ یک میزبان لینوکسی است و می‌خواهید فایل‌ها و dumpهای دیتابیس را بازیابی کنید، از restic استفاده کنید که تنها به یک حساب SSH در مقصد نیاز دارد و پیش از ارسال، داده‌ها را رمزنگاری می‌کند. اجرای هر دو ابزار معمول است: PBS برای هایپروایزر و restic برای سرورهایی که روی آن نیستند.

بازیابی از یک نسخه پشتیبان VPS چقدر زمان می‌برد؟

حجم داده را بر سرعت لینک تقسیم کنید تا حداقل زمان به دست آید، سپس زمان رمزگشایی و نوشتن روی دیسک را به آن اضافه کنید. 500 گیگابایت داده روی یک لینک 100 مگابیت بر ثانیه، با نرخ کامل خط، 11.1 ساعت زمان می‌برد و همان بازیابی روی پورت 1 گیگابیت بر ثانیه، 1.1 ساعت طول می‌کشد. بازیابی تعداد زیادی فایل کوچک به دلیل سربارِ هر فایل، کندتر از این محاسبات ریاضی است. یک بار بازیابی واقعی را زمان‌بندی کنید و از آن عدد اندازه‌گیری‌شده استفاده کنید، زیرا تنها عددی است که طرح بازیابی شما می‌تواند به آن تکیه کند.