آموزش نصب و راه اندازی Proxmox Backup Server روی VPS

مزایای واقعی استفاده از Proxmox Backup Server روی یک VPS

استفاده از Proxmox Backup Server (PBS) روی یک VPS، یک مقصد خارج از سایت (offsite) فراهم می‌کند که از همان پروتکلی استفاده می‌کند که کلاستر Proxmox VE (محیط مجازی‌سازی) شما هم‌اکنون از آن بهره می‌برد. بنابراین، هر نسخه پشتیبان پس از اولین مورد، به‌صورت افزایشی (incremental) است، در میان مهمان‌ها (guests) حذف تکراری (deduplicated) می‌شود، پیش از خروج از شبکه شما رمزنگاری شده و پس از آن قابل‌تایید (verifiable) است. شما یک VPS با یک block volume اجاره می‌کنید، PBS را روی Debian 13 نصب می‌کنید، یک datastore روی آن volume می‌سازید و آن را در Proxmox VE به‌عنوان یک storage از نوع pbs اضافه می‌کنید. نصب آن ده دقیقه زمان می‌برد. هر آنچه پس از آن می‌آید، شامل namespaces، جمع‌آوری زباله (garbage collection)، نگهداری کلیدها و بازیابی (restore) که واقعاً آن را تست کرده‌اید، تعیین می‌کند که آیا این نسخه پشتیبان یک سال دیگر ارزشی خواهد داشت یا خیر.

دلیل استفاده از PBS به‌جای کپی کردن فایل‌های vzdump روی یک دیسک اجاره‌ای، chunk store است. کلاینت، دیسک هر مهمان را به قطعاتی حدود 4 MiB تقسیم می‌کند، آن‌ها را هش کرده و تنها قطعاتی را آپلود می‌کند که datastore هنوز در اختیار ندارد. برای یک ماشین مجازی در حال اجرا، QEMU پس از اولین نسخه پشتیبان، بلوک‌های تغییریافته را در یک dirty bitmap ردیابی می‌کند، بنابراین اجرای بعدی فقط همان بلوک‌ها را از دیسک محلی می‌خواند. یک مهمان 200 GB که روزانه 3 GB تغییر دارد، حدود 3 GB در روز ارسال می‌کند. این همان چیزی است که باعث می‌شود یک uplink خانگی و یک volume اجاره‌ای با هم کار کنند، و به همین دلیل است که استفاده از VPS به‌عنوان مقصد پشتیبان خارج از سایت از یک درایو یدکی در خانه یک دوست بهتر است. اگر هنوز در حال تصمیم‌گیری هستید که خودِ هایپروایزر باید کجا میزبانی شود، Proxmox در خانه در مقابل VPS اجاره‌ای این پرسش را به‌طور جداگانه بررسی می‌کند.

تعیین حجم دیسک پیش از اجاره

محاسبه حجم، یک عملیات ریاضی بر اساس اعداد واقعی شماست. فضای مصرفی واقعی هر guest را در نظر بگیرید، نه حجم دیسک مجازی آن را؛ سپس میزان تغییرات روزانه را در تعداد روزهایی که قصد نگهداری بک‌آپ‌ها را دارید، ضرب کنید. فشرده‌سازی (compression) و حذف داده‌های تکراری (deduplication) این عدد را بهبود می‌بخشند، بنابراین نتیجه نهایی را به عنوان سقف ظرفیت در نظر بگیرید، نه هدف نهایی.

[
  {
    "label": "web VM",
    "used_gb": 40,
    "daily_change_gb": 0.8,
    "store_gb": 64
  },
  {
    "label": "mail VM",
    "used_gb": 120,
    "daily_change_gb": 3.0,
    "store_gb": 210
  },
  {
    "label": "file server container",
    "used_gb": 300,
    "daily_change_gb": 1.5,
    "store_gb": 345
  }
]

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

در این مثال، guest مربوط به ایمیل از 120 گیگابایت فضا استفاده می‌کند و روزانه حدود 3.0 گیگابایت تغییر دارد؛ بنابراین برای نگهداری 30 اسنپ‌شات روزانه، به حدود 210 گیگابایت فضا نیاز است: یک کپی کامل به علاوه تغییرات 30 روزه. ستون آخر را برای تمام 3 عدد guest جمع بزنید تا به مجموع حدود 619 گیگابایت برسید. یک پنجم دیگر به این مقدار برای ایندکس‌ها، متادیتا و فضای مورد نیاز برای عملکرد garbage collection اضافه کنید که در نهایت به یک volume با ظرفیت 1 ترابایت می‌رسید.

بقیه بخش‌های این طرح کوچک است. PBS با 2 گیگابایت رم به خوبی کار می‌کند و با 4 گیگابایت کاملاً راحت است، زیرا پردازش‌های سنگین در سمت کلاستر انجام می‌شوند: نود Proxmox VE دیسک‌های guest را می‌خواند و عملیات chunking و hashing را انجام می‌دهد. کاری که VPS انجام می‌دهد، نوشتن chunkها و اجرای دو وظیفه سنگین یعنی garbage collection و verification است. datastore را به عنوان یک block volume جداگانه اجاره کنید، نه به عنوان یک دیسک روت بزرگ؛ زیرا می‌توانید حجم volume را بعداً بدون نیاز به بازسازی سرور افزایش دهید.

نصب Proxmox Backup Server روی Debian 13

از اوت 2026، ترکیب فعلی، Proxmox Backup Server 4 روی Debian 13 با نام رمز trixie است. راهنماهای قدیمی، PBS 2 را با Debian 11 جفت می‌کنند و از آنجا که نام رمز بخشی از تعریف مخزن (repository) است، کپی کردن نام suite قدیمی باعث بروز خطای apt مبنی بر نبود فایل release می‌شود. کار را با یک ایمیج خام Debian 13 شروع کنید. تمام دستورات زیر را به عنوان root یا با sudo همان‌طور که نوشته شده است، اجرا کنید.

sudo apt update && sudo apt install -y wget
sudo 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

مجموع (sum) باید 136673be77aba35dcce385b28737689ad64fd785a797e57897589aed08db6e45 باشد. اگر چنین نیست، متوقف شوید. keyring اشتباه به این معنی است که در حال نصب بسته‌هایی هستید که توسط منبعی تأیید نشده امضا شده‌اند.

فایل /etc/apt/sources.list.d/pbs.sources را با مخزن no-subscription بنویسید که برای سرورهای فاقد قرارداد پشتیبانی، گزینه مناسب است:

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

رابط وب روی پورت HTTPS 8007 پاسخ می‌دهد. با root@pam و رمز عبور root سیستم وارد شوید، زیرا PBS این کاربر را از طریق PAM (ماژول‌های احراز هویت قابل اتصال) احراز هویت می‌کند؛ همان حساب‌هایی که سیستم‌عامل استفاده می‌کند. گواهی (certificate) خودامضا است و مرورگر شما این موضوع را اعلام می‌کند. اثر انگشت (fingerprint) آن گواهی، مقداری است که Proxmox VE بعداً آن را پین می‌کند، بنابراین این هشدار مورد انتظار است و مشکلی نیست که نیاز به رفع داشته باشد.

پورت 8007 یک فرم ورود در اینترنت عمومی است، بنابراین آن را برای همه باز نگذارید. یک فایل nftables آن را پوشش می‌دهد. نوشتن /etc/nftables.conf قوانین فعلی را پاک (flush) می‌کند، بنابراین اگر چیز دیگری قبلاً فایروال این دستگاه را مدیریت می‌کند، از این مرحله صرف‌نظر کنید.

#!/usr/sbin/nft -f
flush ruleset

table inet filter {
  chain input {
    type filter hook input priority filter; policy drop;
    ct state established,related accept
    iif lo accept
    tcp dport 22 accept
    ip saddr 203.0.113.7 tcp dport 8007 accept
  }
}

آن را با sudo systemctl enable --now nftables اعمال کنید و در حین انجام این کار، یک نشست SSH دوم باز نگه دارید: policy drop به همراه یک غلط تایپی در قانون SSH، شما را از سرور خودتان قفل می‌کند. مقدار 203.0.113.7 را با آدرسی که کلاستر شما از آن خارج می‌شود، جایگزین کنید. اگر آن آدرس پویا (dynamic) است، یا قانون را به محدوده شبکه ارائه‌دهنده خود گسترش دهید یا اتصال را در یک تونل خاتمه دهید، و به یاد داشته باشید که اکثر پنل‌های VPS یک فایروال شبکه جداگانه در مقابل دستگاه دارند که باید اجازه دسترسی به همان پورت را بدهد.

قرار دادن datastore روی یک volume مجزا

نباید datastore را روی فایل‌سیستم root قرار داد. زمانی که یک datastore فایل‌سیستم مشترک root را پر می‌کند، عملیات backup شکست می‌خورد و به تبع آن، تمام سرویس‌های دیگر روی سرور، از جمله لاگ‌هایی که برای عیب‌یابی نیاز دارید، از کار می‌افتند. ابتدا block volume را متصل کنید، آن را فرمت کرده و mount کنید؛ تنها پس از آن datastore را در نقطه mount ایجاد کنید.

lsblk
sudo mkfs.ext4 -L pbsstore /dev/vdb
sudo mkdir -p /mnt/datastore/store1

نام دستگاه را از lsblk بردارید. این نام در اکثر imageهای KVM برابر با /dev/vdb و در برخی دیگر /dev/sdb است، بنابراین هرگز نباید فرض را بر نام خاصی گذاشت. mount را با استفاده از label به /etc/fstab اضافه کنید تا تغییر نام دستگاه پس از reboot، باعث نشود datastore به دیسک اشتباهی اشاره کند:

LABEL=pbsstore  /mnt/datastore/store1  ext4  defaults,relatime  0  2

sudo systemctl daemon-reload
sudo mount -a
findmnt -no SOURCE,TARGET,OPTIONS /mnt/datastore/store1

findmnt باید دستگاه، مسیر و گزینه‌ها از جمله rw,relatime را نمایش دهد. دو خطا در همین یک خط پنهان شده است. اگر mount وجود نداشته باشد و شما datastore را ایجاد کنید، PBS داده‌ها را در فایل‌سیستم root و زیر نقطه mount می‌نویسد؛ سپس با mount شدنِ موفقیت‌آمیزِ دیسک، آن داده‌ها پنهان می‌شوند بدون اینکه حذف شوند: در نتیجه datastore خالی به نظر می‌رسد و فایل‌سیستم root همچنان پر باقی می‌ماند. اگر گزینه‌ها شامل noatime باشند، PBS از کار امتناع می‌کند، زیرا هنگام ایجاد datastore و همچنین در هر مرحله از garbage collection، یک بررسی ایمنی روی access time انجام می‌دهد.

sudo proxmox-backup-manager datastore create store1 /mnt/datastore/store1
sudo proxmox-backup-manager datastore list

این کار یک دایرکتوری .chunks ایجاد می‌کند که شامل 65536 زیردایرکتوری با نام‌های 0000 تا ffff است. یک datastore شامل صدها هزار فایل کوچک است، نه چند فایل بزرگ. دو نتیجه از این موضوع حاصل می‌شود: کپی کردن یک datastore با ابزارهای معمولیِ سطح فایل آن‌قدر کند است که عملاً بی‌فایده خواهد بود، و snapshot گرفتن از volume توسط ارائه‌دهنده در حین اجرای backupها، یک کپی منسجم از آن ایجاد نمی‌کند؛ به همین دلیل است که snapshotها جایگزین backup نیستند و در هیچ جای دیگری نیز چنین نقشی ندارند.

فضاهای نام (Namespaces) از تداخل دو میزبان جلوگیری می‌کنند

یک datastore به‌صورت پیش‌فرض تخت (flat) است. فایل‌های پشتیبان با نام‌های vm/100، ct/101 و host/<name> ذخیره می‌شوند. اگر دو کلاستر که هر کدام یک guest با شناسه 100 دارند در یک گروه بنویسند، snapshotهای آن‌ها با هم ترکیب می‌شوند و یک قانون نگهداری (retention rule) که برای یکی از آن‌ها نوشته شده، snapshotهای دیگری را نیز محاسبه می‌کند. فضاهای نام (Namespaces) به هر منبع، درخت اختصاصی خودش را درون یک datastore می‌دهد.

آن‌ها را روی میزبان PBS ایجاد کنید. آرگومان --repository دارای فرمت [[auth-id@]server[:port]:]datastore است، بنابراین یک نمونه محلی به‌صورت root@pam@localhost:store1 خوانده می‌شود و دستور، رمز عبور root را درخواست می‌کند.

sudo proxmox-backup-client namespace create --repository 'root@pam@localhost:store1' pve-home
sudo proxmox-backup-client namespace create --repository 'root@pam@localhost:store1' pve-office
sudo proxmox-backup-client namespace list --repository 'root@pam@localhost:store1'

فرایند Deduplication تحت تأثیر این تفکیک قرار نمی‌گیرد. قطعات (Chunks) در کل datastore به اشتراک گذاشته می‌شوند، بنابراین ده guest مبتنی بر Debian که در سه فضای نام پخش شده‌اند، همچنان تنها یک نسخه از سیستم پایه را ذخیره می‌کنند. این همان دلیلی است که استفاده از یک datastore با فضاهای نام را به داشتن یک datastore مجزا برای هر میزبان ترجیح می‌دهیم: datastoreهای جداگانه به معنای استخرهای قطعه (chunk pools) جداگانه هستند و استخرهای جداگانه یعنی پرداخت هزینه برای ذخیره چندین‌بارهٔ یک نصب Debian مشابه.

به هر منبع یک حساب کاربری اختصاصی بدهید که محدود به فضای نام خودش باشد. یک API (رابط برنامه‌نویسی کاربردی) token، یک اعتبارنامه است که به یک کاربر تعلق دارد و مجوزهای خاص خود را حمل می‌کند؛ این دقیقاً همان چیزی است که برای ماشینی که ممکن است به سرقت برود، نیاز دارید.

sudo proxmox-backup-manager user create backup@pbs --email you@example.com
sudo proxmox-backup-manager user generate-token backup@pbs pve-home
sudo proxmox-backup-manager acl update /datastore/store1/pve-home DatastoreBackup --auth-id 'backup@pbs!pve-home'

دستور token، مقدار secret را دقیقاً یک‌بار نمایش می‌دهد:

Result: {
  "tokenid": "backup@pbs!pve-home",
  "value": "d63e505a-e3ec-449a-9bc7-1da610d4ccde"
}

همین حالا آن را کپی کنید، زیرا PBS هیچ نسخه‌ای از آن را نگه نمی‌دارد که بتواند دوباره به شما نشان دهد. به دستور کنترل دسترسی دو بار دقت کنید. این دستور token را با نام backup@pbs!pve-home مشخص می‌کند، نه کاربر را؛ زیرا مجوزهای token تنها از ورودی‌هایی محاسبه می‌شوند که نام خودِ token را ذکر کرده باشند. یک ورودی برای backup@pbs به‌تنهایی باعث می‌شود که token هیچ دسترسی نداشته باشد و در نتیجه، اولین عملیات پشتیبان‌گیری به‌دلیل خطای مجوز (permissions) شکست می‌خورد، نه به‌دلیل هرگونه مشکل قابل‌مشاهده در شبکه. مسیر (path) نیز به همان اندازه اهمیت دارد: یک token که محدود به /datastore/store1/pve-home شده است، نمی‌تواند هیچ‌چیزی را در فضای نام office بخواند یا حذف کند؛ بنابراین یک کلاسترِ نفوذپذیر نمی‌تواند تاریخچهٔ سایت دیگری را از بین ببرد.

افزودن VPS به‌عنوان فضای ذخیره‌سازی پشتیبان در Proxmox VE

ابتدا اثر انگشت (fingerprint) گواهی را روی میزبان PBS بخوانید.

sudo proxmox-backup-manager cert info | grep Fingerprint

سپس، روی هر گره (node) از کلاستر:

sudo pvesm add pbs pbs-offsite --server pbs.example.com --datastore store1
sudo pvesm set pbs-offsite --username 'backup@pbs!pve-home' --password
sudo pvesm set pbs-offsite --fingerprint 'FINGERPRINT_FROM_CERT_INFO'
sudo pvesm set pbs-offsite --namespace pve-home
sudo pvesm set pbs-offsite --prune-backups keep-all=1

مقدار cert info چاپ‌شده را به‌جای جای‌نگهدار در خط سوم قرار دهید. ارسال --password بدون مقدار باعث می‌شود pvesm آن را به‌صورت تعاملی درخواست کند، بنابراین توکن امنیتی در تاریخچه shell شما باقی نمی‌ماند. این توکن در /etc/pve/priv/storage/pbs-offsite.pw ذخیره می‌شود و تعریف خودِ فضای ذخیره‌سازی در /etc/pve/storage.cfg قرار می‌گیرد که به تمام گره‌های کلاستر تکثیر می‌شود؛ بنابراین شما این تنظیمات را تنها یک‌بار برای کل کلاستر انجام می‌دهید.

--prune-backups keep-all=1 به Proxmox VE می‌گوید که هیچ‌چیزی را حذف نکند. سیاست نگهداری (retention) در سمت PBS مدیریت می‌شود که در ادامه به آن پرداخته شده است؛ دلیلی که باید به‌صراحت بیان شود این است: توکن در این حالت نیازی به مجوز حذف ندارد، بنابراین اگر کلاستری توسط باج‌افزار رمزگذاری شود، نمی‌تواند به تاریخچه خارج از سایت که برای بازیابی در نظر گرفته شده است دسترسی پیدا کرده و آن را پاکسازی کند.

sudo pvesm status --storage pbs-offsite
sudo vzdump 100 --storage pbs-offsite --mode snapshot

pvesm status مقدار active را در ستون وضعیت به همراه فضای کل و فضای استفاده‌شده از datastore چاپ می‌کند. inactive به این معنی است که گره نتوانسته است یک نشست TLS (امنیت لایه انتقال) را با پورت 8007 برقرار کند؛ این مشکل معمولاً مربوط به فایروال یا اثر انگشت است و نه اعتبارنامه‌ها.

اولین پشتیبان‌گیری همه چیز را آپلود می‌کند، پس پیش از شروع، محاسبات لازم را انجام دهید. 200 GB معادل 1600 گیگابیت است و یک uplink با سرعت 100 Mbit، حدود 0.1 گیگابیت در ثانیه جابه‌جا می‌کند؛ بنابراین حداقل زمان حدود چهار ساعت و نیم است و در واقعیت بیشتر طول می‌کشد. این عملیات را زمانی شروع کنید که به پهنای باند نیاز ندارید. هر اجرای بعدی فقط تکه‌های جدید (chunks) را ارسال می‌کند.

رمزنگاری سمت کلاینت و محل نگهداری کلید

سرور مجازی (VPS) کامپیوتری است که مالکیت آن در اختیار شما نیست. عملیات رمزنگاری را روی کلاینت انجام دهید تا مخزن داده (datastore) فقط شامل قطعاتی (chunks) باشد که ارائه‌دهنده سرویس قادر به خواندن آن‌ها نیست.

sudo pvesm set pbs-offsite --encryption-key autogen

این دستور یک کلید جدید در /etc/pve/priv/storage/pbs-offsite.enc می‌نویسد که فقط توسط root قابل خواندن است و همراه با سایر بخش‌های /etc/pve تکثیر می‌شود. از بک‌آپ بعدی به بعد، کلاینت هر قطعه را پیش از ارسال، رمزنگاری می‌کند. سرور همچنان می‌تواند اسنپ‌شات‌ها و حجم آن‌ها را فهرست کند، اما قادر به خواندن محتوای آن‌ها نیست.

اکنون به بخشی می‌رسیم که این فرآیند را به یک «بک‌آپ» تبدیل می‌کند، نه یک «بدهی امنیتی». کلید تولیدشده فاقد رمز عبور (passphrase) است و تنها در همان کلاستری وجود دارد که از آن محافظت می‌کند. اگر آن کلاستر سرقت شود یا توسط شخص دیگری رمزنگاری شود، سرور مجازی حاوی داده‌هایی خواهد بود که هیچ‌کس قادر به باز کردن آن‌ها نیست. در همان روزی که کلید را ایجاد می‌کنید، نسخه‌ای از آن را از کلاستر خارج کنید.

sudo cp /etc/pve/priv/storage/pbs-offsite.enc /root/pbs-offsite.enc
sudo proxmox-backup-client key paperkey /root/pbs-offsite.enc

دستور key paperkey کلید را به صورت سندی چاپ می‌کند که برای چاپ روی کاغذ و نگهداری در مکانی دیگر طراحی شده است. خودِ فایل را به عنوان یک راز در نظر بگیرید، زیرا هر کسی که به آن دسترسی داشته باشد، می‌تواند تمام بک‌آپ‌های تهیه‌شده با آن را رمزگشایی کند. برای تنظیمات بزرگ‌تر، PBS از یک کلید اصلی (master key) نیز پشتیبانی می‌کند؛ یک جفت‌کلید RSA (Rivest Shamir Adleman) که با proxmox-backup-client key create-master-key ایجاد می‌شود. در این حالت، هر بک‌آپ کلید رمزنگاری مخصوص خود را دارد که با کلید عمومی رمزنگاری شده است، در حالی که کلید خصوصی برای بازیابی، به‌صورت آفلاین نگهداری می‌شود.

یک پیامد این طراحی وجود دارد که بهتر است پیش از شروع کار از آن آگاه باشید. برای بک‌آپ‌های رمزنگاری‌شده، digest قطعات بر اساس محتوای متن ساده (plain text) به همراه کلید رمزنگاری محاسبه می‌شود. بنابراین، دو قطعه یکسان که با کلیدهای متفاوت رمزنگاری شده‌اند، digestهای متفاوتی تولید می‌کنند و هرگز با یکدیگر deduplicate نمی‌شوند. تغییر کلید به این معناست که در بک‌آپ بعدی، همه داده‌ها دوباره آپلود می‌شوند و قطعات قدیمی تا زمانی که اسنپ‌شات‌های آن‌ها حذف (prune) و جمع‌آوری نشوند، در جای خود باقی می‌مانند. پیش از اولین آپلود، در مورد رمزنگاری تصمیم‌گیری کنید.

حذف نشانگرها و بازپس‌گیری فضای هرز (Garbage Collection)

این بخشی است که معمولاً نادیده گرفته می‌شود و همان عاملی است که باعث پر شدن حجم دیسک می‌گردد. عملیات Prune (هرس کردن) یک اسنپ‌شات، متادیتاهای آن شامل manifest، ایندکس‌ها، لاگ‌ها و یادداشت‌ها را حذف می‌کند، اما هیچ chunk داده‌ای را پاک نمی‌کند. از آنجا که chunkها بین اسنپ‌شات‌های مختلف به اشتراک گذاشته می‌شوند، هیچ فرآیندی نمی‌تواند تشخیص دهد که یک chunk بلااستفاده است مگر اینکه تمام ایندکس‌های باقی‌مانده بررسی شوند؛ این وظیفه بر عهده Garbage collection است. یک datastore که فقط برنامه Prune دارد و فاقد برنامه Garbage collection است، حجم آن دائماً افزایش می‌یابد.

هر دو را تنظیم کنید. ابتدا Retention (نگهداری)، یک job برای هر namespace:

sudo proxmox-backup-manager prune-job create home-daily --store store1 --ns pve-home --schedule '02:30' --keep-daily 14 --keep-weekly 8 --keep-monthly 6
sudo proxmox-backup-manager prune-job list

سپس برنامه collection را روی datastore، چند ساعت پس از job مربوط به prune و خارج از بازه زمانی پشتیبان‌گیری تنظیم کنید:

sudo proxmox-backup-manager datastore update store1 --gc-schedule 'Sun 04:27'
sudo proxmox-backup-manager datastore show store1

این تفکیک وظایف را یک‌بار روی میزبان PBS برای خودتان اثبات کنید:

df -h /mnt/datastore/store1
sudo proxmox-backup-manager garbage-collection start store1
df -h /mnt/datastore/store1

ابتدا job مربوط به prune را اجرا کنید، سپس df را چک کنید؛ خواهید دید که مقدار فضای مصرفی تغییر نمی‌کند. حالا Garbage collection را اجرا کرده و دوباره df را بررسی کنید؛ در این مرحله فضای مصرفی کاهش می‌یابد.

عملیات Garbage collection در دو فاز اجرا می‌شود. فاز اول تمام ایندکس‌های موجود در datastore را پیمایش کرده و زمان دسترسی (access time) هر chunk که توسط آن ایندکس‌ها ارجاع داده شده است را به‌روزرسانی می‌کند. فاز دوم، chunkهایی را حذف می‌کند که زمان دسترسی آن‌ها قدیمی‌تر از بازه تعیین‌شده باشد؛ این بازه برابر است با 24 ساعت و 5 دقیقه پیش از شروع عملیات، یا زمان شروع قدیمی‌ترین پشتیبان‌گیری که هنوز در حال نوشتن است (هر کدام که زودتر باشد). این حاشیه امن به این دلیل وجود دارد که لینوکس به‌صورت پیش‌فرض فایل‌سیستم‌ها را با فلگ relatime مونت می‌کند که زمان دسترسی را تقریباً یک‌بار در روز به‌روزرسانی می‌کند، نه با هر بار خواندن. بنابراین، chunkای که یک ساعت پیش نوشته شده است حتی اگر هیچ ارجاعی نداشته باشد حذف نمی‌شود و فضای آزاد شده توسط prune، در اولین عملیات collection که بیش از یک روز پس از آخرین دسترسی به chunk اجرا شود، ظاهر می‌گردد. اگر به نظر می‌رسد یک datastore هیچ فضایی را بازپس نگرفته است، اغلب به این دلیل است که هنوز در آن بازه زمانی قرار دارد.

روی یک VPS کوچک، این سنگین‌ترین jobای است که سیستم اجرا می‌کند، زیرا تمام فایل‌های chunk روی دیسک را بررسی (stat) می‌کند. لاگ این تسک با خلاصه‌ای از موارد حذف‌شده و مواردی که به دلیل دوره انتظار (grace period) همچنان باقی مانده‌اند، پایان می‌یابد. اگر حجم موارد باقی‌مانده زیاد است، روز بعد دوباره آن را اجرا کنید. PBS گزینه‌های gc-atime-safety-check و gc-atime-cutoff را به عنوان تنظیمات بهینه‌سازی datastore ارائه می‌دهد، اما هر دو باید به حالت پیش‌فرض باقی بمانند؛ این گزینه‌ها برای ذخیره‌سازهایی هستند که قابلیت ثبت زمان دسترسی را ندارند و غیرفعال کردن بررسی‌های ایمنی روی فایل‌سیستمی که با noatime مونت شده است، باعث از دست رفتن chunkهایی می‌شود که اسنپ‌شات‌های زنده هنوز به آن‌ها ارجاع دارند.

تأیید صحت، خوانا بودن قطعات داده را تضمین می‌کند

بک‌آپی که به‌درستی آپلود شده است، ممکن است یک سال بعد غیرقابل خواندن باشد. عملیات تأیید (Verification)، قطعات داده (chunks) را مجدداً می‌خواند و آن‌ها را با checksumهای ذخیره‌شده در ایندکس مقایسه می‌کند؛ بنابراین خرابی‌ها به‌جای زمان بازیابی (restore)، طبق یک برنامهٔ زمان‌بندی شناسایی می‌شوند.

sudo proxmox-backup-manager verify store1 --read-threads 1 --verify-threads 4

در یک VPS کوچک، تعداد threadها را پایین نگه دارید. عملیات تأیید توسط دیسک و CPU محدود می‌شود و در غیر این صورت با سایر فعالیت‌های سرور تداخل پیدا می‌کند. برای زمان‌بندی، از تب Verify Jobs در رابط کاربری وب datastore استفاده کنید: یک job هفتگی که snapshotهای قبلاً تأییدشده را نادیده می‌گیرد و موارد قدیمی‌تر از 30 روز را دوباره بررسی می‌کند، کل مخزن داده را در طول زمان پوشش می‌دهد بدون آنکه کارهای تکراری انجام شود.

snapshotای که در تأیید صحت شکست بخورد، در نمای datastore به‌عنوان failed علامت‌گذاری می‌شود. چنین موردی را نادیده نگیرید. قطعات داده به اشتراک گذاشته می‌شوند، بنابراین یک قطعهٔ آسیب‌دیده از یک image پایه، معمولاً باعث شکست تمام snapshotهایی می‌شود که به آن ارجاع می‌دهند. روش تعمیر این است که snapshotهای شکست‌خورده را حذف (forget) کرده و یک بک‌آپ جدید بگیرید که قطعات گمشده را دوباره آپلود کند. اگر خطاها همچنان ظاهر می‌شوند، به فضای ذخیره‌سازی زیرین datastore مشکوک شوید و پایش سلامت دیسک روی VPS را راه‌اندازی کنید تا درایو پیش از آنکه job تأیید متوجه شود، شما را مطلع کند.

تست بازیابی، سپس تست آن بدون کلاستر

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

کل مهمان (Guest)، روی کلاستر:

sudo pvesm list pbs-offsite
sudo qmrestore 'pbs-offsite:backup/vm/100/2026-08-14T22:00:00Z' 999 --storage local-lvm

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

تست دوم تستی است که هیچ‌کس انجام نمی‌دهد. فرض کنید ساختمانی که کلاستر در آن قرار دارد از بین رفته است؛ بازیابی را از ماشینی انجام دهید که هرگز بخشی از آن کلاستر نبوده است. روی هر سیستم Debian 13، مخزن مخصوص کلاینت را به صورت /etc/apt/sources.list.d/pbs-client.sources اضافه کنید:

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

sudo apt update && sudo apt install -y proxmox-backup-client
export PBS_REPOSITORY='backup@pbs!pve-home@pbs.example.com:store1'
export PBS_PASSWORD='<the token secret>'
export PBS_FINGERPRINT='<the value cert info printed>'
proxmox-backup-client snapshot list --ns pve-home
proxmox-backup-client snapshot files vm/100/2026-08-14T22:00:00Z --ns pve-home
proxmox-backup-client restore vm/100/2026-08-14T22:00:00Z 'ARCHIVE_NAME_FROM_THAT_LIST' ./restore-test --keyfile ./pbs-offsite.enc --ns pve-home

سه جای‌نگهدار (placeholder) داخل کوتیشن را با مقادیر خود پر کنید و نام آرشیو در خط آخر را از خروجی snapshot files بردارید. این کار چیزی را ثابت می‌کند که تست اول نمی‌تواند: اینکه نسخه فایل کلید شما داده‌های واقعی را رمزگشایی می‌کند و اینکه می‌توانید کلاینت را از ماشینی که هرگز پیکربندی کلاستر شما را نداشته است، مدیریت کنید. چهار مقداری که نیاز بود (رشته مخزن، توکن مخفی، اثر انگشت و فایل کلید) را یادداشت کنید و آن‌ها را در محلی که در طرح بازیابی فاجعه (disaster plan) مشخص کرده‌اید، نگهداری کنید.

عملکرد deduplication و تأثیر آن بر هزینه‌های ذخیره‌سازی

فناوری deduplication واقعی است و در کل datastore عمل می‌کند. ده ماشین مجازی Debian یک نسخه از سیستم‌عامل پایه را به اشتراک می‌گذارند، بنابراین هزینه ذخیره‌سازی برای دومین ماشین مجازی مشابه، تقریباً صفر است. این فناوری پهنای باند آپلود را نیز کاهش می‌دهد، زیرا کلاینت برای هر قطعه داده‌ای (chunk) که سرور از قبل در اختیار دارد، به‌جای ارسال خودِ داده، یک checksum می‌فرستد.

در مورد کارهایی که این فناوری انجام نمی‌دهد، باید صریح بود:

• داده‌هایی که تغییر می‌کنند، فشرده نمی‌شوند. دیتابیسی که هر شب بخش بزرگی از فایل‌های خود را بازنویسی می‌کند، هر شب قطعات (chunks) جدیدی تولید می‌کند و سیاست‌های نگهداری (retention) این حجم را چندبرابر می‌کنند.
• این فناوری از مرز کلیدهای رمزنگاری عبور نمی‌کند (همان‌طور که در بالا توضیح داده شد).
• این فناوری از مرز datastore عبور نمی‌کند، که این خود دلیل اصلی استفاده از namespaces است.
• این فناوری مانع پر شدن volume نمی‌شود. وقتی datastore پر شود، بک‌آپ‌ها با شکست مواجه می‌شوند و تنها راه‌حل، افزایش حجم volume یا کاهش دوره نگهداری است.

یک لایه deduplication دیگر در زیر آن قرار ندهید. قطعات داده توسط کلاینت از قبل deduplicate و فشرده شده‌اند؛ بنابراین استفاده از ZFS deduplication در زیر یک datastore، باعث می‌شود RAM برای یافتن تطابق‌هایی مصرف شود که پیش از نوشته شدن روی دیسک، حذف شده‌اند. استفاده از فایل‌سیستم‌های ساده مانند ext4 یا xfs روی این volume، انتخاب درستی است.

رابط وب، یک ضریب deduplication برای datastore گزارش می‌دهد. این عدد توصیف‌کننده وضعیت ماشین‌های مجازی شماست و تنها عددی است که ارزش برنامه‌ریزی دارد، زیرا نسبت‌های اعلام‌شده در منابع دیگر، مربوط به داده‌های دیگران است. اگر به بک‌آپ در سطح فایل برای ماشین‌هایی که ماشین مجازی Proxmox نیستند نیاز دارید، آن‌ها را در کنار سایر سرویس‌ها روی همان VPS اجرا کنید: PBS یک مقصد آگاه از hypervisor برای کل ماشین‌های مجازی است، در حالی که restic and BorgBackup دایرکتوری‌ها را هدف قرار می‌دهند و restic backups to a VPS برای لپ‌تاپ‌ها و سرورهای مستقلی مناسب هستند که PBS برای پوشش آن‌ها طراحی نشده است.

حالت‌های شکست و آنچه مشاهده خواهید کرد

وضعیت ذخیره‌ساز غیرفعال (inactive) نمایش داده می‌شود. دستور pvesm status --storage pbs-offsite در صورتی که نود نتواند نشست TLS را به پورت 8007 تکمیل کند، inactive را چاپ می‌کند. فایروال روی VPS، سپس فایروال شبکه مجزای ارائه‌دهنده و در نهایت fingerprint را بررسی کنید. fingerprintای که دیگر با گواهی مطابقت ندارد، دقیقاً مانند یک پورت مسدود شده باعث شکست می‌شود و با هر بار جایگزینی گواهی، تغییر می‌کند.

اولین بک‌آپ به دلیل مجوزها با شکست مواجه می‌شود. ورودی کنترل دسترسی (access control entry) باید به جای کاربر، نام توکن را ذکر کند و باید namespaceای که ذخیره‌ساز به آن اشاره دارد را پوشش دهد. پیش از بررسی هر جای دیگر، هر دو مورد را در تب مجوزهای datastore در رابط کاربری وب تأیید کنید.

Garbage collection از شروع خودداری می‌کند. بررسی ایمنی زمان دسترسی (access time safety check) شکست خورده است، که تقریباً همیشه به این معنی است که فایل‌سیستم datastore با گزینه noatime مونت شده است. برای تأیید، دستور findmnt -no OPTIONS /mnt/datastore/store1 را اجرا کنید، گزینه را در /etc/fstab اصلاح کرده و مجدداً مونت کنید. برای عبور از این وضعیت، بررسی را غیرفعال نکنید.

حجم datastore فقط افزایش می‌یابد. کارهای Prune اجرا می‌شوند اما هیچ فضایی بازیابی نمی‌شود. یا زمان‌بندی برای garbage collection وجود ندارد، یا هر عملیات جمع‌آوری در بازه زمانی 24 ساعته (grace window) قرار می‌گیرد زیرا بلافاصله پس از بک‌آپ‌ها اجرا می‌شود. زمان‌بندی را با proxmox-backup-manager datastore show store1 بررسی کنید.

بک‌آپ سریعی که قبلاً انجام می‌شد، اکنون ساعت‌ها طول می‌کشد. مهمانی (guest) که متوقف، منتقل یا بازیابی شده است، dirty bitmap خود را از دست می‌دهد؛ بنابراین اجرای بعدی، کل دیسک را در سمت کلاستر می‌خواند، حتی اگر مقدار بسیار کمی آپلود کند. لاگ وظیفه (task log) مدت زمان طولانی را با حجم آپلود کم نشان می‌دهد و اجرای بعدی دوباره سریع خواهد بود. اگر تمام وظایف روی VPS کند هستند، علت معمولاً خارج از datastore است و CPU steal time از یک همسایه پرمصرف اولین موردی است که باید اندازه‌گیری شود.

FAQ

چرا با اجرای job مربوط به prune، فضای datastore در Proxmox Backup Server همچنان در حال افزایش است؟

زیرا عملیات prune فقط متادیتای snapshotها شامل manifest، ایندکس‌ها، لاگ و یادداشت‌ها را حذف می‌کند. تکه‌های داده (chunks) تا زمانی که garbage collection آن‌هایی را که هیچ ایندکسی به آن‌ها ارجاع نمی‌دهد پاک نکند، روی دیسک باقی می‌مانند. یک زمان‌بندی برای datastore با استفاده از proxmox-backup-manager datastore update store1 --gc-schedule 'Sun 04:27' تنظیم کنید و با اجرای df -h روی مسیر datastore قبل و بعد از proxmox-backup-manager garbage-collection start store1، نتیجه را بررسی کنید. انتظار حداقل یک روز تأخیر را داشته باشید، زیرا مرحله دوم فقط تکه‌هایی را حذف می‌کند که زمان دسترسی آن‌ها بیش از 24 ساعت و 5 دقیقه باشد.

یک VPS برای Proxmox Backup Server به چه مقدار فضای دیسک نیاز دارد؟

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

کلید رمزنگاری بک‌آپ باید کجا ذخیره شود؟

در هر جایی به جز همان کلاستری که از آن محافظت می‌کند. Proxmox VE کلید را در /etc/pve/priv/storage/<storage>.enc نگه می‌دارد که به تمام نودها کپی می‌شود و در صورت از دست رفتن کلاستر، کلید نیز از بین می‌رود. در همان روز اول کلید را خارج کنید، با proxmox-backup-client key paperkey آن را چاپ کنید و نسخه چاپی را در ساختمان دیگری نگه دارید. توجه داشته باشید که کلید در تولید digest تکه‌ها نقش دارد، بنابراین جایگزینی آن در آینده به این معنی است که بک‌آپ بعدی باید تمام داده‌ها را دوباره آپلود کند.

آیا به یک datastore برای هر میزبان Proxmox نیاز دارم یا استفاده از namespaceها کافی است؟

یک datastore و یک namespace برای هر میزبان یا کلاستر منبع کافی است. Deduplication در سطح یک datastore کار می‌کند و نه بین datastoreهای مختلف، بنابراین تقسیم‌بندی بر اساس میزبان باعث می‌شود ایمیج‌های پایه چندین بار ذخیره شوند. Namespaceها گروه‌های بک‌آپ را از هم جدا نگه می‌دارند، بنابراین دو میزبان که هر دو دارای یک guest با ID 100 هستند با هم تداخل پیدا نمی‌کنند و مسیر کنترل دسترسی به فرم /datastore/store1/pve-home، توکن API هر میزبان را به namespace خودش محدود می‌کند.

آیا یک VPS کوچک می‌تواند به عنوان Proxmox backup server پاسخگو باشد؟

معمولاً برای محیط‌های آزمایشگاهی خانگی بله، زیرا عملیات chunking و hashing روی نود Proxmox VE انجام می‌شود و نه روی سرور بک‌آپ. VPS فقط تکه‌ها را می‌نویسد و دو وظیفه سنگین یعنی garbage collection و verification را اجرا می‌کند. به آن 4 GB رم اختصاص دهید و تعداد threadهای verification را پایین نگه دارید. هر دو وظیفه را خارج از بازه زمانی بک‌آپ‌گیری زمان‌بندی کنید و اگر همچنان بسیار طولانی‌تر از حد انتظار دیسک زمان می‌برند، پیش از خرید پلن بزرگ‌تر، میزان steal time را اندازه‌گیری کنید.