VPS को ऑफ-साइट बैकअप टारगेट कैसे बनाएं

ऑफ-साइट बैकअप टारगेट वास्तव में क्या है

ऑफ-साइट बैकअप टारगेट एक दूसरी मशीन होती है जो आपके डेटा की एक कॉपी रखती है और मूल सर्वर से स्वतंत्र रूप से विफल होती है। अधिकांश उपयोगकर्ताओं के लिए किसी अन्य प्रदाता पर स्थित एक VPS सबसे सस्ता विकल्प है। इसके तीन व्यावहारिक रूप हैं: VPS पर चल रहा Proxmox Backup Server, SSH या S3 के माध्यम से एक्सेस किया जाने वाला restic रिपॉजिटरी, या rsync मिरर जिसे बैकअप होस्ट पुल (pull) करता है। कौन सा विकल्प उपयुक्त है, यह इस पर निर्भर करता है कि आप क्या रिस्टोर करते हैं और आपको इसे कितनी जल्दी वापस पाने की आवश्यकता है। कॉपी को हटाने की अनुमति किसके पास है, यह बाकी चीजों को निर्धारित करता है।

ऑफ-साइट का अर्थ है एक अलग विफलता डोमेन (failure domain)। इसका मतलब है एक अलग प्रदाता, और एक ऐसा अकाउंट जो आपके सर्वर को चलाने वाले अकाउंट के साथ कोई लॉगिन साझा नहीं करता हो। एक ही प्रदाता के दूसरे क्षेत्र (region) में स्थित दूसरा सर्वर एक बिल्डिंग में लगी आग से तो बच सकता है, लेकिन वह एक कॉम्प्रोमाइज्ड कंट्रोल पैनल लॉगिन से नहीं बच सकता, क्योंकि एक ही अकाउंट दोनों कॉपियों को नियंत्रित करता है।

आपके प्रदाता द्वारा लिया गया स्नैपशॉट वह दूसरी कॉपी नहीं है। यह उसी पैनल पासवर्ड के पीछे होता है, इसलिए जिसके पास भी वह पासवर्ड होगा, वह एक ही सेशन में सर्वर और उसके स्नैपशॉट दोनों को डिलीट कर सकता है। स्नैपशॉट सेवाएं सामान्य डिस्क की तुलना में काफी अधिक दरों पर प्रति गीगाबाइट प्रति माह बिल लेती हैं, जिससे नब्बे दिनों के स्नैपशॉट महंगे हो जाते हैं। VPS स्नैपशॉट और बैकअप के बीच का अंतर को पढ़ना उपयोगी है, इससे पहले कि आप इनमें से किसी पर भी निर्भर रहें।

आपकी आवश्यकताओं के लिए कौन सा विकल्प उपयुक्त है

• Proxmox Backup Server (PBS): इसका स्रोत Proxmox VE (virtual environment) है और आप पूरी virtual machine को restore करते हैं। यह disk-image स्तर पर बैकअप लेता है, और इसके verify jobs target पर मौजूद डेटा को पुनः पढ़ते हैं।
• A restic repository: इसका स्रोत एक या अधिक Linux hosts हैं और आप किसी directory या database dump को restore करते हैं। यह client-side पर encryption करता है, और यह SSH तथा S3 के साथ-साथ अपने स्वयं के REST protocol का उपयोग करता है।
• rsync over SSH, जिसे backup host द्वारा pull किया जाता है: यदि आप चाहते हैं कि target पर फाइलें सामान्य फाइलों के रूप में रहें, जिन्हें ls और cat के साथ पढ़ा जा सके, और उन्हें वापस पाने के लिए किसी client software की आवश्यकता न हो।

यदि आप निर्णय नहीं ले पा रहे हैं, तो restic का उपयोग करें। यह डेटा के मशीन से बाहर जाने से पहले उसे encrypt कर देता है, और target पर SSH account तथा disk के अलावा किसी अन्य चीज़ की आवश्यकता नहीं होती। VPS पर restic बैकअप सेट करना लेख में client-side के बारे में विस्तार से बताया गया है, और restic और BorgBackup का तुलनात्मक उपयोग लेख उस स्थिति के लिए है यदि आप पहले से ही Borg का उपयोग कर रहे हैं।

लक्ष्य का आकार निर्धारित करना: एक महीने के रिटेंशन की लागत

Deduplication के कारण ही ये आंकड़े लोगों की उम्मीद से कम होते हैं। restic और PBS दोनों ही फाइलों को अलग-अलग आकार के chunks में विभाजित करते हैं और प्रत्येक chunk का hash बनाते हैं। प्रत्येक unique chunk को केवल एक बार स्टोर किया जाता है। 500 GB के डेटासेट का दूसरा backup अतिरिक्त 500 GB नहीं जोड़ता है। यह केवल उन chunks को जोड़ता है जो बदल गए हैं।

इसलिए repository का आकार आपके सबसे पुराने snapshot की उम्र पर निर्भर करता है, न कि snapshots की संख्या पर। मान लीजिए 500 GB डेटा है और प्रतिदिन 5 GB नया unique डेटा जुड़ता है। तो repository में 500 GB का आधार डेटा होगा, साथ ही उस नीति के अनुसार सबसे पुराने 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
  }
]

डॉलर वाला कॉलम उस repository की कीमत 10 US डॉलर प्रति TB प्रति माह के हिसाब से दर्शाता है। यह केवल गणना के लिए एक उदाहरण है, किसी प्रदाता की वास्तविक कीमत नहीं है, इसलिए आप जिस plan पर विचार कर रहे हैं उसकी वास्तविक प्रति-TB कीमत का उपयोग करें। एक सप्ताह के dailies में लगभग 535 GB डेटा होता है। एक पूरे वर्ष के इतिहास में 2,325 GB डेटा होता है, जिसकी लागत $23.25 प्रति माह है, जबकि एक सप्ताह के लिए यह $5.35 है। इतिहास सस्ता है। आप मुख्य रूप से आधार कॉपी (base copy) के लिए भुगतान कर रहे हैं।

Deduplication उन डेटा पर काम नहीं करता जो पहले से ही compressed या encrypted होकर आता है। एक gzipped database dump हर बार पूरी तरह बदल जाता है, इसलिए प्रत्येक dump नए chunks के रूप में स्टोर होता है और repository हर रात एक पूरे dump के आकार के बराबर बढ़ जाती है। dump को uncompressed लिखें और backup टूल को उसे compress करने दें, क्योंकि restic 0.14 के बाद से compressed repositories को सपोर्ट करता है और 0.19 वर्ज़न में fastest और better zstd मोड्स जोड़े गए हैं। फोटो और वीडियो लाइब्रेरी भी इसी कारण से ठीक से dedupe नहीं हो पाती हैं, इसलिए उनका आकार ऊपर दी गई पंक्तियों के बजाय उनकी वास्तविक वृद्धि दर से निर्धारित करें।

यहाँ आप CPU के बजाय idle disk खरीद रहे हैं, और यही वह स्थिति है जहाँ a storage VPS एक सामान्य VPS से बेहतर होता है।

बैंडविड्थ और रिस्टोर समय योजना को क्यों निर्धारित करते हैं

डिस्क सस्ती होती है। पहली बार अपलोड करना और अंततः डेटा को रिस्टोर करना सबसे महंगा हिस्सा है। 500 GB का मतलब 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
  }
]

ये आंकड़े बिना प्रोटोकॉल ओवरहेड के लाइन-रेट हैं, इसलिए इन्हें सर्वोत्तम स्थिति के रूप में देखें। 100 Mbit/s की गति पर, किसी के भी डेटा तक पहुँचने से पहले पूर्ण रिस्टोर में 11.1 घंटे लगेंगे। 40 Mbit/s के होम अपलोड से इसमें 27.8 घंटे लगेंगे। 1 Gbit/s के पोर्ट पर वही रिस्टोर 1.1 घंटों में पूरा होगा। कई छोटी फाइलें गणितीय गणना से धीमी चलती हैं, क्योंकि जब फाइलें कुछ सौ किलोबाइट से छोटी होती हैं, तो प्रति-फाइल ओवरहेड का प्रभाव अधिक हो जाता है।

इससे दो बातें स्पष्ट होती हैं। यदि आपका रिकवरी टाइम ऑब्जेक्टिव (RTO), यानी वह डाउनटाइम जिसे आप सहन कर सकते हैं, चार घंटे है, तो 100 Mbit/s लिंक पर 500 GB का रिस्टोर पहले ही उस समय सीमा को पार कर चुका होगा, और सस्ती डिस्क इसमें कोई मदद नहीं करेगी। साथ ही, अधिकांश VPS प्लान आउटबाउंड ट्रांसफर को मापते हैं (meter), इसलिए एक पूर्ण रिस्टोर बैकअप होस्ट के मासिक डेटा भत्ते (allowance) का 0.5 TB खर्च कर देगा। डेटा की आवश्यकता पड़ने से पहले उस भत्ते की जाँच करें, और यह भी देखें कि सीमा पार होने पर प्रदाता क्या कार्रवाई करता है।

पहला बैकअप पूरे डेटासेट का होता है और यह सबसे धीमी प्रक्रिया होगी। इसे शुक्रवार को शुरू करें, और इसे रेट-लिमिट करें ताकि यह स्रोत के अपलिंक को पूरी तरह से व्यस्त न कर दे: restic के लिए --limit-upload का उपयोग KiB प्रति सेकंड में करें, और rsync के लिए --bwlimit का उपयोग करें।

आकृति 1: रिमोट डेटास्टोर के रूप में Proxmox Backup Server

जब स्रोत Proxmox VE हो और रिस्टोर की इकाई वर्चुअल मशीन हो, तो PBS सबसे उपयुक्त है। एक VPS Proxmox ISO को बूट नहीं कर सकता, इसलिए Debian के ऊपर PBS इंस्टॉल करें। अगस्त 2026 तक संस्करण 4.2 वर्तमान है और यह 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

उस चेकसम की तुलना Proxmox package repositories page पर प्रकाशित मान से करें। एक apt रिपॉजिटरी उतनी ही विश्वसनीय होती है जितनी कि वह की (key) जिसे आपने सत्यापित किया है। फिर /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

डेटास्टोर को अपना स्वयं का फाइलसिस्टम या अपना वॉल्यूम दें। एक भरा हुआ डेटास्टोर बैकअप को रोक देता है, और यदि डेटास्टोर रूट फाइलसिस्टम को साझा करता है, तो उसके भर जाने पर पूरा सर्वर डाउन हो जाता है।

इसके बाद, वह अकाउंट बनाएं जिसका उपयोग स्रोत करेगा, और उसे पासवर्ड के बजाय एक टोकन दें।

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'

टोकन सीक्रेट केवल एक बार दिखाई देता है और इसे दोबारा नहीं पढ़ा जा सकता, इसलिए जब यह दिखाई दे तो इसे सुरक्षित रख लें। टोकन जितना महत्वपूर्ण है, भूमिका (role) भी उतनी ही महत्वपूर्ण है। DatastoreBackup अपने स्वयं के बैकअप बना और रिस्टोर कर सकता है, और इसमें Datastore.Prune विशेषाधिकार नहीं होता है, इसलिए वह टोकन उस स्नैपशॉट को डिलीट नहीं कर सकता जिसे उसने पहले ही लिख दिया है।

PBS पर रिटेंशन के दो भाग होते हैं, और दूसरा वह भाग है जिसे लोग छोड़ देते हैं। Prune स्नैपशॉट को हटाता है। Garbage collection उन चंक्स (chunks) को हटाता है जिन्हें कोई भी जीवित स्नैपशॉट रेफर नहीं करता है। खाली स्थान 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

जब स्नैपशॉट की सूची जिसे वह हटाने की योजना बना रहा है, सही दिखे, तब --dry-run चलाएं। Garbage collection दो चरणों में चलता है: यह प्रत्येक ऐसे चंक के एक्सेस टाइम को अपडेट करता है जिसे अभी भी रेफर किया जा रहा है, फिर उन चंक्स को हटा देता है जिनका एक्सेस टाइम कटऑफ से पुराना है, जो कि रन शुरू होने से 24 घंटे और 5 मिनट पहले का समय है। यह ग्रेस पीरियड इसलिए होता है ताकि बैकअप के दौरान लिखा जा रहा कोई चंक उसके नीचे से डिलीट न हो जाए। डेटास्टोर पर Prune को दैनिक और Garbage collection को साप्ताहिक रूप से शेड्यूल करें, और एक verify जॉब जोड़ें ताकि टारगेट अपने स्वयं के चंक्स को दोबारा पढ़े और रिस्टोर से पहले डिस्क पर किसी भी करप्शन की रिपोर्ट करे।

यदि स्रोत स्वयं एक PBS इंस्टेंस है, तो ऑफ-साइट बॉक्स पुश किए जाने के बजाय डेटा को पुल (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'

उस सिंक जॉब को VPS पर, डिफ़ॉल्ट पुल दिशा में चलाएं। VPS होम डेटास्टोर तक पहुंच बनाता है, जिसका अर्थ है कि होम बॉक्स के पास ऐसा कोई क्रेडेंशियल नहीं होता जो ऑफ-साइट कॉपी को छू सके।

आकृति 2: SSH या S3 पर एक restic repository

Debian और Ubuntu दोनों ही restic को पैकेज करते हैं, लेकिन दोनों के वर्ज़न upstream से पीछे रहते हैं। अगस्त 2026 तक वर्ज़न 0.19.1 नवीनतम है। source host पर आधिकारिक बाइनरी इंस्टॉल करें।

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 से इंस्टॉल की गई कॉपी पर।

Backup VPS पर एक ऐसा अकाउंट बनाएँ जिसके पास अन्य कुछ भी न हो, फिर source host की public key को /home/resticsrv/.ssh/authorized_keys में कॉपी करें।

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

Source से, SFTP के माध्यम से repository को इनिशियलाइज़ करें।

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

उस पासवर्ड को ऐसी जगह रखें जो न तो यह सर्वर हो और न ही बैकअप टारगेट। यदि आप इसे खो देते हैं, तो repository को पढ़ा नहीं जा सकेगा और इसे रिकवर करने का कोई रास्ता नहीं है। client-side encryption के साथ यही समझौता होता है।

Retention एक कमांड है, और इसका दूसरा भाग वह हिस्सा है जो डिस्क स्पेस खाली करता है।

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

forget स्नैपशॉट्स को डिलीट करता है। prune उन पैक फाइलों को डिलीट करता है जिन्हें केवल उन्हीं स्नैपशॉट्स ने रेफर किया था, और --prune इसे स्वचालित रूप से चलाता है जब वास्तव में कुछ हटाया जाता है। इसके बिना repository का आकार कभी कम नहीं होता। restic check repository की संरचना को वेरिफाई करता है, और --read-data-subset=10% पैक फाइलों के दसवें हिस्से को फिर से पढ़ता और हैश करता है, जो सब कुछ पढ़े बिना टारगेट पर करप्शन का पता लगा लेता है। दूसरा रूप, --read-data-subset=1/10, एक निश्चित दसवें हिस्से की जाँच करता है, इसलिए हर हफ्ते उस पहले नंबर को बढ़ाने से दस हफ्तों में पूरी repository कवर हो जाती है।

यदि कोई रन किल (kill) हो जाता है, तो अगला रन repository is already locked exclusively by PID के साथ रुक जाता है। सुनिश्चित करें कि कोई बैकअप नहीं चल रहा है, फिर इसे restic unlock के साथ क्लियर करें।

ऑब्जेक्ट स्टोरेज के लिए repository स्ट्रिंग s3:https://s3.example.net/web1 हो जाती है, जिसमें क्रेडेंशियल्स AWS_ACCESS_KEY_ID और AWS_SECRET_ACCESS_KEY में होते हैं। बाकी सब कुछ समान है, इसी तरह restic उसी VPS पर चल रहे self-hosted MinIO object store से बात करता है।

आकार 3: SSH पर rsync और pull-only key

इस आकार की सुरक्षा विशेषता इसकी दिशा है। बैकअप VPS स्रोत (source) से जुड़ता है और डेटा पढ़ता है। स्रोत के पास बैकअप होस्ट की कोई key या रूट नहीं होती है, इसलिए यदि स्रोत breached हो जाए, तो भी वह बैकअप तक नहीं पहुँच सकता है।

बैकअप VPS पर एक key pair जनरेट करें, फिर public key को एक forced command के साथ स्रोत पर इंस्टॉल करें।

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

rrsync, Debian 13 और Ubuntu 24.04 पर /usr/bin/rrsync में rsync पैकेज के साथ आता है। -ro केवल पढ़ने (read-only) की अनुमति देता है और इसमें -no-del निहित है, इसलिए यह key स्रोत पर कुछ भी लिख या हटा नहीं सकती है। restrict उन SSH सुविधाओं को बंद कर देता है जिनकी यहाँ आवश्यकता नहीं है, जैसे कि port forwarding और pty, ताकि इस key का उपयोग interactive login के लिए न किया जा सके। पाथ आपके द्वारा निर्दिष्ट डायरेक्टरी के सापेक्ष होते हैं, इसलिए रिमोट पाथ / का अर्थ स्रोत पर /srv होता है।

यह pull प्रक्रिया hardlinks के साथ इतिहास (history) बनाए रखती है। नए ट्री में अपरिवर्तित फाइलें पिछली ट्री की hardlinks होती हैं, इसलिए वे दूसरी कॉपी के बजाय केवल एक डायरेक्टरी एंट्री का उपयोग करती हैं।

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 ही दिनांकित डायरेक्टरी को विश्वसनीय बनाता है: नाम केवल तभी दिखाई देता है जब rsync 0 के साथ exit होता है, इसलिए अधूरा ट्रांसफर कभी भी पूर्ण स्नैपशॉट जैसा नहीं दिखता है। पुरानी डायरेक्टरी को एक लाइन के साथ हटाएँ, और तीस को सुरक्षित रखें।

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

इस आकार की लागत के बारे में स्पष्ट रहें। Hardlinks केवल पूरी फाइलों को ही deduplicate करते हैं, इसलिए 4 GB डिस्क इमेज के अंदर एक बाइट बदलने पर भी पूरा 4 GB कॉपी हो जाता है, जबकि restic और PBS केवल बदले हुए chunks को ही स्टोर करते हैं। लक्ष्य (target) पर आपकी फाइलें plaintext में होती हैं, इसलिए बैकअप VPS पर root एक्सेस रखने वाला कोई भी व्यक्ति उन्हें पढ़ सकता है।

Client-side encryption, ताकि target कभी भी plaintext न देख सके

Backup VPS को एक ऐसी मशीन मानें जिसे आप पूरी तरह से नियंत्रित नहीं करते हैं। इसका एक provider है, और उस provider के पास कर्मचारी हैं और खराब डिस्क हैं जो बिल्डिंग से बाहर जा सकती हैं।

restic भेजने से पहले source पर हर chunk को encrypt करता है, इसलिए repository केवल ciphertext और आकार व समय के बारे में metadata होती है। PBS में encryption को opt-in बनाया गया है: एक key बनाएँ, फिर हर backup के साथ उसे pass करें।

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 करें और उसे किसी भौतिक स्थान पर सुरक्षित रखें। Proxmox का documentation जोखिमों के बारे में स्पष्ट है: उनकी key के बिना, backup की गई फाइलें एक्सेस नहीं की जा सकतीं। Key को backup target पर न रखें, क्योंकि ciphertext के साथ रखी गई key किसी की सुरक्षा नहीं करती।

rsync mirrors में इसका कोई विकल्प नहीं है। फाइलें फाइल के रूप में ही पहुँचती हैं। यदि डेटा संवेदनशील है, तो या तो यह स्वीकार करें कि target उसे पढ़ सकता है, या फिर अन्य दो विकल्पों में से किसी एक का उपयोग करें।

किसी compromised source को अपने स्वयं के बैकअप मिटाने से रोकना

यदि कोई हमलावर source का नियंत्रण ले लेता है, तो वह सबसे पहले बैकअप की तलाश करता है। बैकअप अपलोड करने वाला credential उसी मशीन पर मौजूद होता है। यदि उस credential के पास delete करने की अनुमति है, तो हमलावर उसका उपयोग कर सकता है।

PBS इस समस्या का समाधान roles के माध्यम से करता है। एक token जिसके पास केवल DatastoreBackup है, वह नए snapshots लिख सकता है और उन्हें restore कर सकता है, लेकिन वह prune नहीं कर सकता। किसी snapshot को delete करने के लिए अलग से Datastore.Prune privilege की आवश्यकता होती है। retention को PBS की तरफ से चलाएं, ताकि source के पास कभी भी ऐसा credential न रहे जो किसी भी चीज़ को हटा सके।

SFTP पर restic में ऐसा कोई विभाजन नहीं है, क्योंकि जो SSH key repository में लिखती है, वही उसे delete भी कर सकती है। इसका समाधान REST backend है। backup VPS पर --append-only के साथ rest-server चलाएं। यह नए बैकअप बनाने की अनुमति देता है लेकिन मौजूदा बैकअप को delete या modify करने से रोकता है। client को RESTIC_REST_USERNAME और RESTIC_REST_PASSWORD का उपयोग करके rest:https://backup.example.net:8000/web1 पर point करें। इसके बाद source से आने वाला restic forget --prune विफल हो जाएगा, जो कि अपेक्षित परिणाम है। इसलिए, retention को एक दूसरी मशीन से चलाएं जिसके पास अपना स्वयं का credential हो। restic manual append-only repositories पर count-based policies के बजाय --keep-within का उपयोग करने की भी सलाह देता है। अन्यथा, एक हमलावर जो repository को बेकार snapshots से भर देता है, वह आपके वास्तविक बैकअप को --keep-last विंडो से बाहर धकेल सकता है।

rsync इसी समस्या को संरचनात्मक रूप से 'pull' करके हल करता है, क्योंकि source के पास target के लिए कोई credential नहीं होता है।

एक नियम इन तीनों स्थितियों पर लागू होता है: बैकअप delete करने वाला credential उस मशीन पर होना चाहिए जिसका बैकअप नहीं लिया जा रहा है।

रिस्टोर ड्रिल को कैलेंडर में शामिल करें

जिस बैकअप को आपने कभी रिस्टोर नहीं किया है, वह केवल एक परिकल्पना है। हर तिमाही में एक घंटा निर्धारित करें और इसका परीक्षण करें।

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/ है, साथ ही इसमें एक निर्धारित verify जॉब भी शामिल है जो टारगेट पर मौजूद चंक्स को फिर से पढ़ता है और चेकसम विफलता की रिपोर्ट करता है।

ड्रिल को केवल बाइट्स के सुरक्षित होने से अधिक साबित करना चाहिए।

• किसी तीसरे मशीन से रिस्टोर करें, न कि सोर्स से, क्योंकि आप यही मानकर चल रहे हैं कि सोर्स नष्ट हो चुका है। इसका मतलब है कि रिपॉजिटरी पासवर्ड या PBS की (key) उस मशीन के बिना भी उपलब्ध होनी चाहिए।
• रिस्टोर में लगने वाले समय को नोट करें और उसे अपने द्वारा घोषित RTO के साथ तुलना करें। ऊपर दिया गया चार्ट ट्रांसफर की न्यूनतम सीमा बताता है। वास्तविक संख्या में डिक्रिप्शन, डिस्क पर राइटिंग, और सही स्नैपशॉट चुनने में लगा समय भी शामिल होता है।
• स्टेट (state) वाली किसी चीज़ को रिस्टोर करें, जैसे कि डेटाबेस डंप जिसे आप एक स्क्रैच इंस्टेंस में लोड करते हैं। केवल एक tar फाइल का एक्सट्रैक्ट होना इस बात का प्रमाण नहीं है कि एप्लिकेशन स्टार्ट हो जाएगा।

दुनिया की सबसे सस्ती डिस्क भी तब तक बेकार है जब तक आपने उससे कम से कम एक बार रिस्टोर न किया हो।

FAQ

क्या मेरे VPS प्रदाता का snapshot एक off-site backup है?

नहीं। प्रदाता का snapshot उसी खाते में, उसी पैनल लॉगिन के पीछे और उसी इनवॉइस पर रहता है जिस पर वह सर्वर है जिसकी वह प्रतिलिपि है। जो कोई भी उस लॉगिन को प्राप्त कर लेता है, वह एक ही सत्र में सर्वर और उसके हर snapshot को हटा सकता है। Snapshot जोखिम भरे अपग्रेड से पहले त्वरित rollback के लिए उपयोगी हैं, लेकिन वे कोई दूसरा स्थान नहीं हैं। एक off-site प्रतिलिपि एक अलग खाते के अंतर्गत रहती है, आदर्श रूप से एक अलग प्रदाता के पास, ऐसे क्रेडेंशियल्स के साथ जो source मशीन के पास नहीं होते हैं।

मुझे एक महीने के सुरक्षित backups के लिए कितनी डिस्क की आवश्यकता है?

इसे snapshots की संख्या के बजाय अपने सबसे पुराने snapshot की आयु के आधार पर मापें। एक deduplicating टूल प्रत्येक unique chunk को एक बार स्टोर करता है, इसलिए repository का आकार लगभग source के आकार के बराबर होता है, जिसमें प्रतिदिन जुड़ने वाला नया unique डेटा और आपके द्वारा रखे गए दिनों की संख्या का गुणा शामिल होता है। 500 GB डेटा के लिए जो प्रतिदिन 5 GB बदलता है, एक सप्ताह के दैनिक backups लगभग 535 GB होंगे और पूरे एक वर्ष का इतिहास 2,325 GB होगा। ऊपर से अतिरिक्त जगह (headroom) रखें, क्योंकि डिस्क भर जाने पर अगला backup विफल हो जाता है, और restic के prune को जगह वापस देने से पहले pack files को repack करने के लिए खाली जगह की आवश्यकता होती है।

क्या एक compromised सर्वर अपने स्वयं के off-site backups को हटा सकता है?

हाँ, जब तक कि आपने इसके विरुद्ध सुरक्षा डिज़ाइन न की हो। एक साधारण SSH या SFTP repository के साथ, जो key लिख सकती है, वह हटा भी सकती है। source को ऐसा क्रेडेंशियल दें जो डेटा को हटा न सके: एक PBS API token जिसमें केवल DatastoreBackup भूमिका हो, जिसमें Datastore.Prune विशेषाधिकार न हो, या rest-server के विरुद्ध restic चलाएँ जिसे --append-only के साथ शुरू किया गया हो, जो मौजूदा backups को हटाने और संशोधित करने से मना कर देता है। एक pull डिज़ाइन और भी बेहतर है, क्योंकि उस स्थिति में source के पास backup होस्ट के लिए कोई क्रेडेंशियल नहीं होता है। retention को उस तरफ से चलाएँ जो source नहीं है।

क्या मुझे backup VPS पर Proxmox Backup Server या restic चलाना चाहिए?

टूल का मिलान उस यूनिट से करें जिसे आप restore करना चाहते हैं। यदि source Proxmox VE है और आप पूरी virtual machine वापस चाहते हैं, तो PBS चलाएँ, क्योंकि यह disk-image स्तर पर backup लेता है और एक चरण में VM को restore करता है। यदि source एक Linux होस्ट है और आप files और database dumps वापस चाहते हैं, तो restic चलाएँ, जिसे target पर केवल एक SSH खाते की आवश्यकता होती है और भेजने से पहले यह encrypt करता है। दोनों को चलाना सामान्य है: hypervisor के लिए PBS, और उन सर्वर्स के लिए restic जो उस पर नहीं हैं।

VPS backup से restore करने में कितना समय लगता है?

न्यूनतम समय प्राप्त करने के लिए डेटा के आकार को लिंक की गति से विभाजित करें, फिर decryption और लिखने के लिए समय जोड़ें। 100 Mbit/s लिंक पर 500 GB डेटा के लिए लाइन रेट पर 11.1 घंटे लगते हैं, और 1 Gbit/s पोर्ट पर वही restore 1.1 घंटे में होता है। प्रति-फ़ाइल ओवरहेड के कारण कई छोटी फाइलें उस गणित से धीमी चलती हैं। एक वास्तविक restore का समय मापें और उस मापी गई संख्या का उपयोग करें, क्योंकि केवल उसी पर आपकी recovery योजना निर्भर कर सकती है।