VPS ला off-site backup target म्हणून कसे वापरावे

प्रत्यक्षात off-site backup target म्हणजे काय

off-site backup target म्हणजे दुसरे मशीन, ज्यावर तुमच्या डेटाची प्रत ठेवली जाते आणि जे मूळ मशीनपासून स्वतंत्रपणे निकामी होऊ शकते. बहुतेक वाचकांना मिळू शकणारा सर्वात स्वस्त पर्याय म्हणजे दुसऱ्या provider कडील VPS. यासाठी तीन रचना व्यवहार्य आहेत: VPS वर चालणारा Proxmox Backup Server, SSH किंवा S3 द्वारे उपलब्ध असलेले restic repository, किंवा backup host स्वतः pull करत असलेला rsync mirror. कोणता पर्याय योग्य आहे हे तुम्ही काय restore करणार आहात आणि ते किती लवकर परत उपलब्ध हवे आहे यावर अवलंबून असते. प्रत कोणाला delete करण्याची परवानगी आहे, यावर उर्वरित सुरक्षा ठरते.

off-site म्हणजे वेगळा failure domain. याचा अर्थ वेगळा provider आणि तुमचा server चालवणाऱ्या account सोबत कोणतेही login share न करणारे account. त्याच provider च्या दुसऱ्या region मधील दुसरे server एका इमारतीतील आगीपासून सुरक्षित राहू शकते. पण ते compromised control panel login पासून सुरक्षित राहत नाही, कारण एकाच account वरून दोन्ही प्रती नियंत्रित करता येतात.

तुमच्या provider कडील snapshot ही ती दुसरी प्रत नाही. ती त्याच panel password मागे असते. त्यामुळे तो password मिळवणारी व्यक्ती एकाच session मध्ये server आणि त्याचे snapshots delete करू शकते. Snapshot services साठी plain disk च्या तुलनेत प्रति gigabyte प्रति महिना खूप जास्त शुल्क आकारले जाते. त्यामुळे 90 दिवसांचे snapshots महाग पडतात. VPS snapshots आणि backups मधील फरक यापैकी कोणत्याही पर्यायावर अवलंबून राहण्यापूर्वी वाचणे उपयुक्त ठरेल.

तुमच्यासाठी कोणता पर्याय योग्य आहे

• Proxmox Backup Server (PBS): स्रोत Proxmox VE (virtual environment) असतो आणि पुनर्संचयित करायची गोष्ट संपूर्ण virtual machine असते. यामध्ये disk-image स्तरावर backup घेतला जातो आणि त्याची verify jobs target वर साठवलेला data पुन्हा वाचतात.
• restic repository: स्रोत एक किंवा अधिक Linux hosts असतात आणि पुनर्संचयित करायची गोष्ट directory किंवा database dump असते. हे client वरच encryption करते. तसेच ते SSH आणि S3, तसेच स्वतःच्या REST protocol द्वारे काम करते.
• backup host कडून pull केलेले rsync over SSH: target वरील files सामान्य files म्हणून हव्या असतात. त्या ls आणि cat वापरून वाचता येतात. त्या परत मिळवण्यासाठी client software आवश्यक नसते.

निर्णय घेता येत नसेल, तर restic वापरा. मशीनमधून कोणताही data बाहेर जाण्यापूर्वी ते encryption करते. Target वर SSH account आणि disk शिवाय इतर काहीही आवश्यक नसते. VPS वर restic backups सेट करणे येथे client बाजूची अधिक सविस्तर माहिती आहे. तुम्ही आधीच Borg चालवत असाल, तर restic आणि BorgBackup ची तुलनात्मक मांडणी येथे पर्याय निवडण्याची माहिती आहे.

लक्ष्याचा आकार ठरवणे: एका महिन्याच्या retention साठी किती खर्च येतो

Deduplication मुळे हे आकडे अपेक्षेपेक्षा कमी असतात. restic आणि PBS दोन्ही फाइल्सना variable-size chunks मध्ये विभाजित करतात आणि प्रत्येक chunk चा hash तयार करतात. प्रत्येक unique chunk एकदाच साठवला जातो. 500 GB dataset च्या दुसऱ्या backup मुळे आणखी 500 GB जोडले जात नाही. त्यात बदललेले chunks जोडले जातात.

म्हणून repository चा आकार snapshots च्या संख्येऐवजी सर्वात जुन्या snapshot च्या वयावर अवलंबून असतो. 500 GB data आणि दररोज 5 GB नवीन unique data असेल, तर repository मध्ये 500 GB चा base आणि policy मध्ये ठेवलेल्या सर्वात जुन्या snapshotपर्यंतच्या प्रत्येक दिवसासाठी अंदाजे 5 GB साठवले जातील.

[
  {
    "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
  }
]

Dollar column मध्ये त्या repository ची किंमत दर TB प्रति महिना 10 US dollars धरली आहे. हा फक्त गणनेसाठी वापरलेला placeholder आहे. तो कोणत्याही provider कडून दिलेला दर नाही. त्यामुळे तुम्ही विचारात असलेल्या plan चा वास्तविक per-TB दर वापरा. एका आठवड्याच्या daily backups मध्ये अंदाजे 535 GB असतील. एका पूर्ण वर्षाचा history 2,325 GB असेल. त्याची किंमत दर महिन्याला $23.25 असेल, तर आठवड्याच्या history साठी $5.35 लागतील. History स्वस्त असतो. तुम्ही मुख्यतः base copy साठी पैसे देत असता.

आधीच compressed किंवा encrypted स्वरूपात आलेल्या data वर deduplication उपयोगी ठरत नाही. gzipped database dump प्रत्येक run मध्ये पूर्णपणे बदलतो. त्यामुळे प्रत्येक dump नवीन chunks म्हणून साठवला जातो आणि repository मध्ये दर रात्री पूर्ण dump एवढी वाढ होते. Dump uncompressed स्वरूपात लिहा आणि तो compress करण्याचे काम backup tool वर सोडा. restic ने 0.14 पासून compressed repositories ला समर्थन दिले आहे आणि version 0.19 मध्ये fastest आणि better zstd modes जोडले आहेत. याच कारणामुळे photo आणि video libraries वर deduplication कमी प्रभावी असते. त्यामुळे वरील rows ऐवजी त्यांच्या वास्तविक growth rate नुसार त्यांचा आकार ठरवा.

इथे तुम्ही CPU पेक्षा वापरात नसलेली disk capacity खरेदी करत आहात. अशा परिस्थितीत storage VPS नियमित VPS पेक्षा अधिक योग्य ठरतो.

बँडविड्थ आणि पुनर्संचयित वेळ यांवर योजना का ठरते

डिस्क हा स्वस्त भाग आहे. पहिला upload आणि नंतरचा restore हे खर्चिक भाग आहेत. 500 GB म्हणजे 4 trillion bits. त्यामुळे link speed ने भागल्यावर पूर्ण restore साठी लागणाऱ्या किमान वेळेचा अंदाज मिळतो.

[
  {
    "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 आकडेवारीमध्ये protocol overhead धरलेला नाही. त्यामुळे ती सर्वोत्तम परिस्थितीतील आकडेवारी समजा. 100 Mbit/s वेगावर कोणीही data वापरण्यापूर्वी पूर्ण restore साठी 11.1 तास लागतात. घरच्या 40 Mbit/s upload वेगावर 27.8 तास लागतात. 1 Gbit/s port वर त्याच restore साठी 1.1 तास लागतात. अनेक लहान files असतील, तर हा arithmetic पेक्षा कमी वेगाने होतो. Files काहीशे kilobytes पेक्षा लहान झाल्यावर प्रत्येक file चा overhead प्रमुख ठरतो.

यातून दोन गोष्टी स्पष्ट होतात. तुमचे recovery time objective (RTO), म्हणजे तुम्ही सहन करू शकणारा outage, चार तास असल्यास 100 Mbit/s link वर 500 GB restore आधीच त्या मर्यादेपेक्षा जास्त वेळ घेतो. स्वस्त disk यावर उपाय करत नाही. तसेच बहुतेक VPS plans मध्ये outbound transfer मोजला जातो. त्यामुळे एका पूर्ण restore साठी backup host च्या मासिक allowance मधील 0.5 TB वापरले जाते. Data आवश्यक होण्यापूर्वी तो allowance तपासा. मर्यादा ओलांडल्यावर provider काय करतो, हेही तपासा.

पहिला backup संपूर्ण dataset चा असतो आणि तुम्ही कधीही करणार असलेला तो सर्वांत धीमा run असतो. तो Friday ला सुरू करा आणि source चा uplink पूर्णपणे व्यापला जाणार नाही यासाठी rate-limit करा: restic --limit-upload KiB per second घेतो, तर rsync --bwlimit घेतो.

आकार 1: दूरस्थ datastore म्हणून Proxmox Backup Server

मूळ स्रोत Proxmox VE असेल आणि restore चे एकक virtual machine असेल, तेव्हा PBS योग्य ठरते. VPS वर Proxmox ISO boot करता येत नाही, त्यामुळे Debian वर PBS install करा. August 2026 पर्यंत Version 4.2 current आहे आणि ते 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 package repositories page वर प्रकाशित केलेल्या मूल्याशी करा. तुम्ही पडताळलेल्या key इतकाच apt repository विश्वासार्ह असतो. त्यानंतर /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 साठी स्वतंत्र filesystem किंवा स्वतंत्र volume वापरा. datastore पूर्ण भरल्यास backups थांबतात. datastore ने root filesystem share केला असेल, तर तो भरल्यावर संपूर्ण server बंद पडतो.

यानंतर source वापरणार असलेले account तयार करा आणि password ऐवजी त्याला 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'

token secret फक्त एकदाच दाखवले जाते आणि नंतर पुन्हा वाचता येत नाही. त्यामुळे ते दिसताच जतन करा. token इतकीच role देखील महत्त्वाची आहे. DatastoreBackup स्वतःचे backups create आणि restore करू शकते. तिच्याकडे Datastore.Prune privilege नसल्यामुळे त्या token ने त्याने आधी लिहिलेला snapshot delete करता येत नाही.

PBS मधील retention चे दोन भाग आहेत. त्यातील दुसरा भाग अनेक जण वगळतात. Prune snapshots काढते. कोणत्याही उरलेल्या snapshot कडून reference न केलेले chunks garbage collection काढते. Free space prune नंतर नव्हे, तर garbage collection नंतर उपलब्ध होते.

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

काढून टाकायच्या snapshots ची यादी योग्य दिसत असल्याची खात्री झाल्यावर --dry-run काढा. Garbage collection दोन phases मध्ये चालते. प्रथम अजून reference केलेल्या प्रत्येक chunk ची access time update केली जाते. त्यानंतर run सुरू झाल्याच्या वेळेपासून 24 hours आणि 5 minutes पेक्षा जुनी access time असलेले chunks delete केले जातात. Backup अद्याप चालू असताना लिहिला जाणारा chunk मध्येच delete होऊ नये, यासाठी हा grace period असतो. datastore वर prune दररोज आणि garbage collection दर आठवड्याला schedule करा. तसेच verify job जोडा, जेणेकरून target स्वतःचे chunks पुन्हा वाचेल आणि restore करण्यापूर्वी disk वरील corruption कळवेल.

Source स्वतः PBS instance असेल, तर off-site box वर 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 वर default pull direction मध्ये चालवा. VPS home datastore मध्ये प्रवेश करते. त्यामुळे off-site copy ला स्पर्श करू शकणारे कोणतेही credential home box वर ठेवावे लागत नाही.

Shape 2: SSH किंवा S3 वरील restic repository

Debian आणि Ubuntu दोन्ही restic चे package देतात; मात्र दोन्ही upstream आवृत्तीपेक्षा मागे आहेत. August 2026 पर्यंत 0.19.1 ही सध्याची आवृत्ती आहे. Source host वर अधिकृत binary install करा.

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 compiler ने build केला आहे तो compiler दाखवते. पुढील upgrades साठी sudo restic self-update वापरा. हे official binaries वर कार्य करते; apt मधून install केलेल्या copy वर कार्य करत नाही.

Backup VPS वर इतर कोणतीही मालमत्ता own न करणारे account तयार करा. त्यानंतर source host ची public key /home/resticsrv/.ssh/authorized_keys मध्ये copy करा.

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

SFTP द्वारे source host वरून repository initialise करा.

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

हा password या server वर किंवा backup target वर नसलेल्या ठिकाणी साठवा. तो हरवल्यास repository वाचता येणार नाही. त्यासाठी कोणताही recovery path नाही. Client-side encryption ची हीच अट आहे.

Retention साठी एक command पुरेसा आहे. त्याचा दुसरा भाग disk space मोकळी करतो.

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

forget snapshots delete करते. prune फक्त त्या snapshots ने संदर्भित केलेल्या pack files delete करते आणि प्रत्यक्षात काही delete झाल्यावर --prune ते आपोआप चालवते. --prune शिवाय repository कधीही लहान होत नाही. restic check repository structure पडताळते. --read-data-subset=10% pack files पैकी एक दशांश पुन्हा read करून त्यांचे hash तयार करते. त्यामुळे सर्व files read करण्याचा खर्च न करता target वरील corruption सापडते. दुसरा प्रकार, --read-data-subset=1/10, प्रत्येक वेळी तोच निश्चित एक दशांश तपासतो. त्यामुळे दर आठवड्याला पहिल्या number मध्ये 1 ने वाढ केल्यास दहा आठवड्यांत संपूर्ण repository तपासली जाते.

एखादा run जबरदस्तीने बंद झाल्यास पुढचा run repository is already locked exclusively by PID मुळे थांबतो. कोणताही backup चालू नाही याची खात्री करा. त्यानंतर restic unlock वापरून तो lock काढा.

Object storage साठी repository string s3:https://s3.example.net/web1 अशी होते. Credentials AWS_ACCESS_KEY_ID आणि AWS_SECRET_ACCESS_KEY मध्ये ठेवा. बाकी सर्व समान राहते. याच पद्धतीने restic त्याच VPS वर चालणाऱ्या self-hosted MinIO object store शी संवाद साधते.

रचना 3: pull-only key सह SSH वरून rsync

या रचनेचे सुरक्षा वैशिष्ट्य म्हणजे दिशा. Backup VPS source शी कनेक्ट होतो आणि डेटा वाचतो. Source वर कोणतीही key किंवा backup host कडे जाणारा route नसतो. त्यामुळे source चा भंग झाला तरी backup पर्यंत अजिबात पोहोचता येत नाही.

Backup VPS वर key pair तयार करा. त्यानंतर forced command वापरून public key चा भाग source वर स्थापित करा.

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

Debian 13 आणि Ubuntu 24.04 वर rrsync हे rsync package मध्ये /usr/bin/rrsync येथे उपलब्ध असते. -ro मुळे फक्त वाचन करता येते आणि त्यात -no-del अभिप्रेत असते. त्यामुळे ही key source वर लिहू किंवा तेथील काहीही हटवू शकत नाही. restrict येथे आवश्यक नसलेली SSH वैशिष्ट्ये बंद करते. त्यात port forwarding आणि pty यांचा समावेश आहे. त्यामुळे ही key interactive login साठी वापरता येत नाही. त्यानंतर paths तुम्ही नमूद केलेल्या directory च्या सापेक्ष असतात. त्यामुळे remote path / म्हणजे source वरील /srv.

Pull प्रक्रियेत hardlinks वापरून इतिहास राखला जातो. नवीन tree मधील न बदललेल्या files मागील tree कडे निर्देश करणाऱ्या hardlinks असतात. त्यामुळे दुसरी प्रत तयार करण्याऐवजी त्यांना एक directory entry एवढीच जागा लागते.

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"

शेवटी केलेले rename dated directory विश्वसनीय बनवते. rsync ने 0 status सह समाप्त झाल्यानंतरच हे नाव दिसते. त्यामुळे मध्येच थांबलेला transfer पूर्ण snapshot असल्याचे दिसत नाही. एका ओळीत जुने trees expire करा आणि तीस trees ठेवा.

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

या रचनेची किंमत स्पष्टपणे समजून घ्या. Hardlinks फक्त संपूर्ण files deduplicate करतात. त्यामुळे 4 GB disk image मध्ये एक byte बदलला तरी संपूर्ण 4 GB पुन्हा copy केले जातात. याउलट restic आणि PBS काही बदललेले chunks साठवतील. तसेच target वर तुमच्या files plaintext स्वरूपात असतात. त्यामुळे backup VPS वर root access असलेली कोणतीही व्यक्ती त्या वाचू शकते.

क्लायंट-साइड encryption, त्यामुळे target ला plaintext कधीही दिसत नाही

backup VPS वर तुमचे पूर्ण नियंत्रण नाही, असे गृहीत धरा. त्याचा provider असतो. त्या provider कडे कर्मचारी असतात. इमारतीबाहेर नेल्या जाणाऱ्या निकामी disks देखील असतात.

restic प्रत्येक chunk source वरच encrypt करून पाठवते. त्यामुळे repository मध्ये ciphertext आणि आकार व वेळेबाबतचा metadata असतो. PBS मध्ये encryption opt-in असते. Key तयार करा आणि प्रत्येक backup वेळी तो द्या.

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

Paper key print करून तो सुरक्षित physical ठिकाणी ठेवा. Proxmox documentation मध्ये जोखीम स्पष्टपणे सांगितली आहे: key शिवाय backed up files access करता येत नाहीत. Key backup target पासून वेगळा ठेवा. Ciphertext च्या शेजारी ठेवलेला key कोणाचेही संरक्षण करत नाही.

rsync mirrors मध्ये यासाठी समतुल्य सुविधा नाही. Files थेट files म्हणून साठवल्या जातात. Data sensitive असल्यास target ते वाचू शकतो हे स्वीकारा, किंवा इतर दोनपैकी एखादी पद्धत वापरा.

तडजोड झालेल्या स्रोताला त्याचे स्वतःचे बॅकअप पुसण्यापासून रोखा

आक्रमणकर्ता स्रोत मशीनचा ताबा घेतल्यानंतर पुढे बॅकअप शोधतो. बॅकअप अपलोड करणारे credential त्याच मशीनवर असते. त्या credential ला delete करण्याची परवानगी असल्यास, आक्रमणकर्ता ती वापरतो.

PBS मध्ये roles वापरून याचे निराकरण केले जाते. फक्त DatastoreBackup असलेला token नवीन snapshots लिहू शकतो आणि स्वतःचे snapshots restore करू शकतो. तो prune करू शकत नाही, कारण snapshot delete करण्यासाठी स्वतंत्र Datastore.Prune privilege आवश्यक असतो. Retention PBS कडून चालवा. त्यामुळे स्रोत मशीनवर कोणतेही हटवणारे credential राहत नाही.

SFTP वरील restic मध्ये अशी विभागणी नाही. Repository मध्ये लिहिणारी SSH key त्यातील डेटा delete देखील करू शकते. यासाठी REST backend वापरा. Backup VPS वर --append-only सह rest-server चालवा. यामुळे नवीन backups तयार करता येतात, पण विद्यमान backups delete किंवा modify करता येत नाहीत. त्यानंतर RESTIC_REST_USERNAME आणि RESTIC_REST_PASSWORD वापरून client ला rest:https://backup.example.net:8000/web1 कडे निर्देशित करा. स्रोत मशीनवरून केलेला restic forget --prune अयशस्वी होईल. हेच अपेक्षित परिणाम आहे. त्यामुळे retention दुसऱ्या मशीनवर, तिच्या स्वतंत्र credential सह चालवा. Append-only repositories साठी count-based policies ऐवजी --keep-within वापरण्याची शिफारस restic manual मध्येही केली आहे. अन्यथा आक्रमणकर्ता junk snapshots मोठ्या प्रमाणात तयार करून तुमचे वास्तविक snapshots --keep-last window मधून बाहेर ढकलू शकतो.

rsync हीच समस्या रचनात्मक पद्धतीने सोडवते, कारण ते pull पद्धतीने काम करते. त्यामुळे स्रोत मशीनवर target साठी कोणतेही credential राहत नाही.

या तिन्ही रचनांना एकच नियम लागू होतो: backups delete करू शकणारे credential, ज्याचा backup घेतला जात आहे त्या मशीनऐवजी दुसऱ्या मशीनवर असावे.

पुनर्संचय चाचणीचे वेळापत्रक ठरवा

ज्या बॅकअपमधून तुम्ही कधीही पुनर्संचय केलेला नाही, तो केवळ एक गृहीतक आहे. प्रत्येक तिमाहीत एक तास राखून ठेवा आणि त्याची चाचणी करा.

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 काहीही मुद्रित न झाल्यास, पुनर्संचयित केलेले tree live tree शी जुळते. PBS मध्ये हीच चाचणी proxmox-backup-client restore host/web1/2026-08-13T02:30:00Z root.pxar /var/tmp/restore-test/ आहे. यासोबत target वरील chunks पुन्हा वाचणारे आणि checksum failures कळवणारे scheduled verify job देखील असते.

या चाचणीने bytes अखंड असल्याचे सिद्ध करण्यापेक्षा अधिक बाबी सिद्ध केल्या पाहिजेत.

• source वरून नव्हे, तर तिसऱ्या मशीनवरून पुनर्संचय करा. कारण source नष्ट झाले आहे असे तुम्ही गृहीत धरत आहात. त्यामुळे repository password किंवा PBS key source शिवाय उपलब्ध असली पाहिजे.
• पुनर्संचयासाठी लागणारा वेळ मोजून तो लिहून ठेवा. त्याची तुम्ही घोषित केलेल्या RTO शी तुलना करा. वरील chart transfer floor दर्शवतो. प्रत्यक्ष वेळेत decrypt करणे, disk वर लिहिणे आणि तुम्हाला हवा असलेला snapshot शोधण्यासाठी लागलेला वेळ यांचाही समावेश होतो.
• state असलेली एखादी गोष्ट पुनर्संचयित करा. उदाहरणार्थ, database dump पुनर्संचयित करून तो scratch instance मध्ये load करा. Extract होणारी tar file application सुरू होते याचा पुरावा नाही.

जगातील सर्वात स्वस्त disk देखील त्यातून एकदा पुनर्संचय केलेले नसेल, तर निरुपयोगी आहे.

FAQ

माझ्या VPS provider कडील snapshot हा off-site backup आहे का?

नाही. Provider snapshot त्याच account मध्ये, त्याच panel login च्या नियंत्रणाखाली आणि ज्या server ची प्रत तो तयार करतो त्याच invoice वर असतो. ज्याला तो login मिळतो, तो एकाच session मध्ये server आणि त्याचे सर्व snapshots delete करू शकतो. धोकादायक upgrade करण्यापूर्वी जलद rollback करण्यासाठी snapshots उपयुक्त असतात; परंतु ते दुसरे स्वतंत्र स्थान नाही. Off-site copy वेगळ्या account अंतर्गत, शक्यतो वेगळ्या provider कडे असते आणि source machine कडे त्या credentials ची माहिती नसते.

एका महिन्यासाठी retained backups ठेवण्यासाठी मला किती disk space आवश्यक आहे?

Snapshots च्या संख्येऐवजी सर्वात जुन्या snapshot चे वय लक्षात घेऊन आकार ठरवा. Deduplication करणारे tool प्रत्येक unique chunk एकदाच साठवते. त्यामुळे repository चा आकार साधारणपणे source data इतका, तसेच दररोज नव्याने तयार होणारा unique data आणि तुम्ही backups ठेवत असलेल्या दिवसांची संख्या यांचा गुणाकार, इतका असतो. 500 GB data दररोज 5 GB ने बदलत असल्यास, एका आठवड्याचे daily backups सुमारे 535 GB असतील आणि पूर्ण वर्षाचा इतिहास 2,325 GB असेल. याव्यतिरिक्त काही headroom ठेवा. Disk पूर्ण भरल्यास पुढील backup अयशस्वी होतो. तसेच space परत देण्यापूर्वी pack files पुन्हा व्यवस्थित करण्यासाठी restic च्या prune ला मोकळी जागा आवश्यक असते.

breached server स्वतःचे off-site backups delete करू शकतो का?

होय, जोपर्यंत तुम्ही त्याविरुद्ध रचना केलेली नसेल. साध्या SSH किंवा SFTP repository मध्ये लिहिण्यासाठी वापरता येणारी key delete करण्यासाठीही वापरता येते. Source ला data remove करू न शकणारे credential द्या: फक्त DatastoreBackup role असलेला PBS API token, ज्यात Datastore.Prune privilege नसतो; किंवा --append-only सह सुरू केलेल्या rest-server विरुद्ध restic वापरा. हे existing backups चे deletion आणि modification नाकारते. Pull design याहून सुरक्षित असते, कारण source कडे backup host साठी कोणतेही credentialच नसते. Retention source नसलेल्या बाजूने चालवा.

Backup VPS वर Proxmox Backup Server चालवावे की restic?

तुम्ही restore करणार असलेल्या unit नुसार tool निवडा. Source Proxmox VE असेल आणि तुम्हाला पूर्ण virtual machine परत हवी असेल, तर PBS चालवा. ते disk-image स्तरावर backup घेते आणि एका step मध्ये VM restore करते. Source Linux host असेल आणि तुम्हाला files तसेच database dumps परत हवे असतील, तर restic चालवा. त्याला target वरील फक्त SSH account आवश्यक असते आणि data पाठवण्यापूर्वी ते encrypt करते. दोन्ही चालवणे सामान्य आहे: hypervisor साठी PBS आणि त्यावर नसलेल्या servers साठी restic.

VPS backup मधून restore करण्यासाठी किती वेळ लागतो?

किमान वेळ मिळवण्यासाठी data size ला link speed ने भागा. त्यानंतर decryption आणि writing साठी लागणारा वेळ जोडा. 100 Mbit/s link वर 500 GB transfer करण्यास line rate नुसार 11.1 hours लागतात. त्याच restore साठी 1 Gbit/s port वर 1.1 hours लागतात. अनेक लहान files असल्यास प्रत्येक file साठी लागणाऱ्या अतिरिक्त overhead मुळे प्रत्यक्ष वेग या गणनेपेक्षा कमी असतो. एकदा प्रत्यक्ष restore करून वेळ मोजा आणि तो मोजलेला आकडा वापरा. तुमच्या recovery plan ला विश्वास ठेवता येणारा हा एकमेव आकडा आहे.