Restic का उपयोग करके VPS डेटा का बैकअप कैसे लें

एक ही सर्वर पर रखा गया बैकअप, बैकअप क्यों नहीं होता

Restic एक मुफ्त, ओपन सोर्स बैकअप टूल है जो आपकी फाइलों के एन्क्रिप्टेड, डुप्लीकेट-रहित (deduplicated) स्नैपशॉट्स को कहीं और मौजूद रिपॉजिटरी में भेजता है: जैसे कि किसी दूसरे VPS, घर पर रखे किसी मशीन, या S3-compatible ऑब्जेक्ट स्टोरेज पर। यह गाइड इसे Ubuntu 24.04 पर सेटअप करने की प्रक्रिया बताती है, जिसमें इंस्टॉलेशन से लेकर SFTP के जरिए रिपॉजिटरी बनाना, पहला बैकअप लेना, nightly systemd टाइमर सेट करना, रिटेंशन पॉलिसी लागू करना और रिस्टोर ड्रिल करना शामिल है, जो यह साबित करता है कि पूरी प्रक्रिया सही ढंग से काम कर रही है। डेस्टिनेशन के लिए दूसरी मशीन का होना अनिवार्य है, क्योंकि एक ही सर्वर पर मौजूद कॉपी सर्वर के खराब होने के साथ ही खत्म हो जाती है।

जिस बॉक्स का आप बैकअप ले रहे हैं, उसी पर मौजूद backup/ डायरेक्टरी आपको केवल एक ही स्थिति से बचाती है: गलती से कोई फाइल डिलीट हो जाना। यह डिस्क फेल होने पर सुरक्षित नहीं रहती, क्योंकि वह उसी डिस्क पर थी। यह root एक्सेस वाले हमलावर से भी नहीं बचती, क्योंकि वे सबसे पहले इन्हीं कॉपीज को डिलीट करते हैं। यह उस अकाउंट संबंधी गलती से भी नहीं बचती जिसके कारण पूरा VPS ही डिलीट हो जाए। दुनिया का सबसे कम कुशल डेटासेंटर में backup_final_v2_REAL नाम की एक tarball के उसी एरे पर होने का मजाक उड़ाया गया है जहाँ डेटा मौजूद है, और यह मजाक इसलिए सटीक है क्योंकि हम में से बहुत से लोगों ने ठीक ऐसा ही किया है। नियम यह है कि डेटा बॉक्स से बाहर होना चाहिए, और restic इस नियम का पालन करने का सबसे आसान तरीका है।

Restic: चार मुख्य विचार

Repository. वह स्थान जहाँ restic डेटा लिखता है। यह restic के अपने फॉर्मेट में एक डायरेक्टरी है, जो एन्क्रिप्टेड ब्लब्स (blobs) से भरी होती है, और इसे केवल restic ही पढ़ सकता है। आप इसे कभी भी मैन्युअल रूप से एडिट नहीं करते; आप restic commands और -r पते के माध्यम से इससे संवाद करते हैं।

Snapshot. आपके द्वारा बैकअप की गई फाइलों की एक निश्चित समय की तस्वीर। हर बैकअप रन एक स्नैपशॉट बनाता है, हर स्नैपशॉट को अलग से रिस्टोर किया जा सकता है, और प्रत्येक उस समय के आपके डेटा की एक पूर्ण प्रतिलिपि की तरह व्यवहार करता है।

Deduplication. Restic फाइलों को कंटेंट-आधारित टुकड़ों (chunks) में विभाजित करता है और केवल उन्हीं टुकड़ों को अपलोड करता है जिन्हें रिपॉजिटरी ने पहले नहीं देखा है। पहला बैकअप सब कुछ अपलोड करता है; उसके बाद का हर रन लगभग वही अपलोड करता है जो बदल गया है। 20 GB के एक दैनिक स्नैपशॉट में यदि 50 MB का बदलाव हुआ है, तो इसकी लागत लगभग 50 MB ही होगी, इसीलिए दर्जनों स्नैपशॉट रखना सस्ता पड़ता है।

Encryption by default. एक restic रिपॉजिटरी हमेशा एन्क्रिप्टेड (AES-256) होती है। Restic खाली पासवर्ड के साथ रिपॉजिटरी बनाने या खोलने से मना कर देता है, जब तक कि आप --insecure-no-password (restic 0.17.0 और बाद के संस्करण) का उपयोग न करें, इसलिए इस गाइड में सेट की गई रिपॉजिटरी को हर कमांड के लिए अपने पासवर्ड की आवश्यकता होती है। बैकअप होस्ट या स्टोरेज प्रदाता केवल एन्क्रिप्टेड ब्लब्स ही देख पाते हैं। इसका कठोर परिणाम यह है: यदि पासवर्ड खो गया, तो डेटा स्थायी रूप से और डिजाइन के अनुसार ही नष्ट हो जाएगा। पासवर्ड की एक प्रति कहीं और रखें, जो इस सर्वर पर न हो। यह इतना महत्वपूर्ण है कि नीचे इसका दो बार और उल्लेख किया गया है।

Ubuntu 24.04 पर restic इंस्टॉल करें

sudo apt update && sudo apt install -y restic
restic version

Ubuntu 24.04 पर यह restic 0.16.4 इंस्टॉल करता है, जबकि वर्तमान upstream release 0.19.1 है। यह अंतर इसलिए है क्योंकि एक LTS (long term support) release अपने package versions को स्थिर रखता है, और यहाँ इससे कोई फर्क नहीं पड़ता: 0.16.4 इस गाइड में बताए गए सभी कार्य करने में सक्षम है। यदि आप गति में सुधार के लिए नवीनतम release चाहते हैं, तो restic project के GitHub releases page से आधिकारिक single-binary build डाउनलोड करें, इसे bunzip2 के साथ unpack करें, और इसे /usr/local/bin/restic में इंस्टॉल करें; restic के इंस्टॉलेशन में इसके अलावा और कुछ नहीं है।

SFTP के माध्यम से दूसरे सर्वर पर रिपॉजिटरी बनाना

आपको एक डेस्टिनेशन मशीन की आवश्यकता होगी: आमतौर पर एक दूसरा छोटा VPS इसके लिए उपयुक्त है, और कोई भी ऐसी मशीन जिसमें SSH सर्वर और अतिरिक्त डिस्क उपलब्ध हो, काम करेगी। Restic SFTP (SSH पर फाइल ट्रांसफर) का उपयोग करता है, इसलिए बैकअप होस्ट पर कुछ भी अलग से इंस्टॉल करने की आवश्यकता नहीं है। इस गाइड में बैकअप होस्ट 10.0.0.12 है और इसमें restic नाम का एक यूजर है। उस यूजर का नाम backup न रखें: Ubuntu और Debian के हर इंस्टॉलेशन में backup (uid 34, नो लॉगिन शेल) नाम का एक आरक्षित सिस्टम अकाउंट होता है, इसलिए adduser backup विफल हो जाता है और ssh backup@..., nologin में चला जाता है।

नाइटली जॉब बैकअप लिए जा रहे सर्वर पर root के रूप में चलेगी, इसलिए root को बैकअप होस्ट पर की-आधारित लॉगिन की आवश्यकता है। बिना पासफ्रेज वाली एक समर्पित की (key) बनाएं, क्योंकि रात के 3 बजे इसे टाइप करने के लिए कोई व्यक्ति मौजूद नहीं होगा, और इसे कॉपी करें:

sudo ssh-keygen -t ed25519 -f /root/.ssh/id_ed25519 -N "" -C "web1-restic"
sudo ssh-copy-id -i /root/.ssh/id_ed25519.pub restic@10.0.0.12
sudo ssh restic@10.0.0.12 true && echo key login works

यदि आप की (keys) के बारे में नए हैं, तो SSH की प्रबंधन की मूल बातें इस मॉडल, अनुमतियों और बाद में की को रद्द करने के तरीके के बारे में बताती है।

अगला चरण, रिपॉजिटरी पासवर्ड है। एक मजबूत पासवर्ड जनरेट करें और इसे केवल root द्वारा पठनीय फाइल में रखें:

openssl rand -base64 32 | sudo tee /root/.restic-password
sudo chmod 600 /root/.restic-password

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

रिपॉजिटरी को इनिशियलाइज़ करें:

sudo restic -r sftp:restic@10.0.0.12:/srv/restic/web1 --password-file /root/.restic-password init

created restic repository 9f3c2a1b0d at sftp:restic@10.0.0.12:/srv/restic/web1

वैकल्पिक डेस्टिनेशन S3-संगत ऑब्जेक्ट स्टोरेज है, जो तब सही विकल्प है जब आप दूसरी मशीन नहीं चलाना चाहते। कोई भी S3-संगत बकेट एक ही तरह से काम करता है; केवल पता और दो क्रेडेंशियल वेरिएबल बदलते हैं:

export AWS_ACCESS_KEY_ID=your-key-id
export AWS_SECRET_ACCESS_KEY=your-secret-key
sudo -E restic -r s3:https://s3.example.com/web1-backups --password-file /root/.restic-password init

init के बाद की सभी चीजें दोनों डेस्टिनेशन के लिए समान हैं। यह गाइड SFTP पते को दर्शाती है; आप अपना पता बदल लें।

पहला बैकअप, excludes के साथ

केवल उस डेटा का बैकअप लें जिसे आप पुनः इंस्टॉल नहीं कर सकते, पूरे filesystem का नहीं। ऑपरेटिंग सिस्टम पुनः इंस्टॉल करने पर वापस आ जाता है; आपकी कॉन्फ़िगरेशन और आपका डेटा नहीं। एक सामान्य VPS के लिए इसका मतलब है /etc, /home, और जहाँ भी आपके एप्लिकेशन state रखते हैं, जैसे कि /srv या /var/www। Caches को exclude करें, क्योंकि वे बड़े होते हैं, उनमें हर दिन बदलाव होता है, और वे खुद को फिर से बना लेते हैं:

sudo restic -r sftp:restic@10.0.0.12:/srv/restic/web1 --password-file /root/.restic-password backup /etc /home /srv --exclude '/home/*/.cache'

Files:        4181 new,     0 changed,     0 unmodified
Added to the repository: 731.204 MiB (312.418 MiB stored)
snapshot 5b8a3f2c saved

पहली बार चलाने पर सब कुछ अपलोड होता है, इसलिए इसमें कुछ समय लगता है। उसी कमांड को दोबारा चलाएं और यह कुछ ही सेकंड में पूरा हो जाएगा, जिसमें कुछ बदली हुई फाइलें और कुछ MiB डेटा जुड़ने की रिपोर्ट मिलेगी, क्योंकि deduplication केवल नए chunks को ही अपलोड करता है। अपनी सूची देखें:

sudo restic -r sftp:restic@10.0.0.12:/srv/restic/web1 --password-file /root/.restic-password snapshots

प्रत्येक snapshot एक ID, एक समय, और उसमें शामिल paths दिखाता है। आप इन्हीं IDs से restore करते हैं।

systemd timer के साथ nightly runs

हर कमांड पर रिपॉजिटरी का पता टाइप करना थकाऊ हो जाता है, और जिसे आप मैन्युअल रूप से बैकअप करते हैं, वह एक महीने के भीतर बंद हो जाता है। ये दोनों समस्याएं एक स्क्रिप्ट और एक टाइमर से हल हो जाती हैं। स्क्रिप्ट उन दो environment variables को सेट करती है जिन्हें restic पढ़ता है, RESTIC_REPOSITORY और RESTIC_PASSWORD_FILE, ताकि इसके अंदर की हर कमांड छोटी रहे:

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

#!/usr/bin/env bash
set -euo pipefail
export RESTIC_REPOSITORY='sftp:restic@10.0.0.12:/srv/restic/web1'
export RESTIC_PASSWORD_FILE=/root/.restic-password

restic backup /etc /home /srv --exclude '/home/*/.cache'
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
restic check

sudo chmod 700 /usr/local/bin/restic-backup.sh

forget और check लाइनों को अगली दो sections में समझाया गया है। अब शेड्यूल की बात करें: एक oneshot सर्विस जो स्क्रिप्ट को चलाती है, और एक टाइमर जो इसे हर रात 03:00 बजे शुरू करता है। यहाँ cron लाइन की तुलना में टाइमर बेहतर है क्योंकि रन का लॉग journal में दर्ज होता है, और Persistent=true सर्वर के डाउनटाइम के बाद वापस आते ही छूटे हुए बैकअप को चला देता है।

# /etc/systemd/system/restic-backup.service
[Unit]
Description=Nightly restic backup
Wants=network-online.target
After=network-online.target

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

# /etc/systemd/system/restic-backup.timer
[Unit]
Description=Run the nightly restic backup

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

[Install]
WantedBy=timers.target

टाइमर को enable करें, फिर सर्विस को एक बार मैन्युअल रूप से चलाएं और इसे काम करते हुए देखें:

sudo systemctl daemon-reload
sudo systemctl enable --now restic-backup.timer
sudo systemctl start restic-backup.service
sudo journalctl -u restic-backup.service -f

systemctl list-timers दिखाता है कि अगला रन कब होगा। आप इन दोनों unit files को टाइप करने के बजाय generate भी कर सकते हैं:

इन दो फाइलों के पीछे का पूरा पैटर्न, जिसमें calendar syntax और वे hardening directives शामिल हैं जो एक सर्विस ले सकती है, VPS पर systemd सर्विस के रूप में प्रोग्राम चलाना में दिया गया है।

बैकअप तब तक केवल एक अफवाह है जब तक आप उसे रिस्टोर न कर लें

इस वाक्य को एक आदेश की तरह मानें। हर रात चलने वाला एक सफल बैकअप जॉब केवल यह साबित करता है कि जॉब चला था; यह यह साबित नहीं करता कि आपका डेटा वापस आ सकता है। दो जांचें इस कमी को पूरा करती हैं।

पहला, restic check, जिसे स्क्रिप्ट पहले से ही हर रात चलाती है। यह रिपॉजिटरी संरचना और इंडेक्स को सत्यापित करता है, ताकि बैकअप होस्ट पर होने वाली साइलेंट करप्शन रिस्टोर के दिन के बजाय अगली रात ही पकड़ी जा सके। महीने में एक बार, गहरा संस्करण चलाएं, जो वास्तविक डेटा के यादृच्छिक दसवें हिस्से को डाउनलोड और क्रिप्टोग्राफिक रूप से सत्यापित करता है:

sudo -i
export RESTIC_REPOSITORY='sftp:restic@10.0.0.12:/srv/restic/web1'
export RESTIC_PASSWORD_FILE=/root/.restic-password
restic check --read-data-subset=10%

चूंकि सबसेट हर बार यादृच्छिक रूप से चुना जाता है, restic का डॉक्यूमेंटेशन स्पष्ट है कि बार-बार चलाने पर भी हर पैक फाइल कवर होने की गारंटी नहीं है। यदि आप चाहते हैं कि मासिक रन पूरे डाउनलोड का भुगतान किए बिना पूरी रिपॉजिटरी की जांच करें, तो फिक्स्ड ग्रुप फॉर्म का उपयोग करें: एक महीने --read-data-subset=1/10, अगले महीने 2/10, और इसी तरह 10/10 तक। Restic पैक फाइलों को दस लगभग समान समूहों में विभाजित करता है और केवल समूह n की जांच करता है, इसलिए दस रन का एक पूरा चक्र हर समूह को एक बार पढ़ लेता है।

दूसरा, रिस्टोर ड्रिल। ऊपर दिए गए रूट शेल में रहते हुए, नवीनतम स्नैपशॉट से एक वास्तविक डायरेक्टरी को स्क्रैच लोकेशन पर रिस्टोर करें और इसकी तुलना लाइव फाइलों से करें:

restic restore latest --target /srv/restore-drill --include /etc/ssh
diff -r /etc/ssh /srv/restore-drill/etc/ssh

diff के कुछ भी प्रिंट न करने का मतलब है कि हर बाइट बिल्कुल वैसी ही वापस आई है, जो एकमात्र प्रमाण है जो मायने रखता है। बाद में /srv/restore-drill को हटा दें। इस ड्रिल को मासिक रूप से करें, और साल में एक या दो बार पूर्ण संस्करण करें: पूरे नवीनतम स्नैपशॉट को एक स्क्रैच VPS पर रिस्टोर करें और जांचें कि क्या आपका एप्लिकेशन वास्तव में उससे शुरू होता है। जिस दिन आपको दबाव में इसकी आवश्यकता होगी, आप चाहेंगे कि यह एक ऐसी प्रक्रिया हो जिसे आप पहले ही कर चुके हों।

Retention: forget और prune

बिना किसी policy के, snapshots हमेशा के लिए जमा होते रहते हैं और repository का आकार केवल बढ़ता जाता है। स्क्रिप्ट की forget लाइन हर रात एक policy लागू करती है: --keep-daily 7 पिछले सात दिनों के लिए प्रति दिन एक snapshot रखती है, --keep-weekly 4 चार सप्ताह के लिए प्रति सप्ताह एक, और --keep-monthly 6 छह महीने के लिए प्रति माह एक snapshot रखती है। जो कुछ भी किसी नियम द्वारा सुरक्षित नहीं है, उसे forget कर दिया जाता है।

forget केवल snapshot records को हटाता है; data chunks repository में तब तक बने रहते हैं जब तक कोई उन्हें delete न करे। यही काम --prune करता है: यह उन chunks को ढूँढता है जिन्हें कोई भी शेष snapshot reference नहीं करता और उन्हें delete कर देता है, जिससे disk space वास्तव में वापस मिलता है। Prune repository पर वास्तविक काम करता है, इसलिए बड़ी repository पर कुछ लोग forget को nightly और --prune को weekly चलाते हैं; सामान्य VPS आकार के लिए, nightly चलाना ठीक है।

डेटाबेस: पहले डंप करें, फिर डंप का बैकअप लें

Restic फाइलों को पढ़ते समय उनकी कॉपी बनाता है, जबकि डेटाबेस लगातार अपनी फाइलों में लिखता रहता है। यदि किसी लाइव डेटाबेस फाइल को लिखते समय कॉपी किया जाए, तो वह रिस्टोर होने पर करप्ट हो जाती है, क्योंकि कॉपी में राइट ऑपरेशन से पहले और बाद के पेज आपस में मिल जाते हैं। इसका मानक समाधान यह है: डेटाबेस इंजन से एक सुसंगत (consistent) एक्सपोर्ट फाइल तैयार करवाएं, और फिर Restic से उस फाइल का बैकअप लें।

PostgreSQL के लिए, restic-backup.sh के शीर्ष पर, restic backup कमांड से पहले एक डंप लाइन जोड़ें, और बैकअप पाथ में डंप डायरेक्टरी को शामिल करें:

mkdir -p /var/backups/db
sudo -u postgres pg_dump myapp | gzip > /var/backups/db/myapp.sql.gz

MariaDB और MySQL के लिए mysqldump भी यही भूमिका निभाता है। पूरे पैटर्न के एक व्यावहारिक उदाहरण के लिए, Nextcloud बैकअप सेक्शन में मेंटेनेंस मोड चालू किया जाता है, Postgres को डंप किया जाता है, और फाइलों को एक सुसंगत सेट के रूप में कॉपी किया जाता है; यही वह सटीक सेट है जिसे Restic को हर रात सर्वर से बाहर ले जाना चाहिए। SQLite के लिए भी यही विचार है, बस तरीका थोड़ा अलग है: Vaultwarden गाइड में कंटेनर को कुछ सेकंड के लिए रोककर db.sqlite3 की एक कोल्ड कॉपी ली जाती है, और उसी आर्काइव को Restic सर्वर से बाहर भेजता है।

FAQ

क्या restic बैकअप एन्क्रिप्टेड होते हैं?

हाँ, हमेशा। हर restic रिपॉजिटरी AES-256 के साथ एन्क्रिप्टेड होती है और इसका कोई अनएन्क्रिप्टेड मोड नहीं है। Restic खाली पासवर्ड को भी स्वीकार नहीं करता है जब तक कि आप --insecure-no-password (restic 0.17.0 से उपलब्ध) का उपयोग न करें, इसलिए इस गाइड में सेट की गई रिपॉजिटरी को हर कमांड के लिए पासवर्ड की आवश्यकता होती है। रिपॉजिटरी को स्टोर करने वाली मशीन या प्रदाता के पास केवल एन्क्रिप्टेड ब्लब्स होते हैं, इसलिए एक ब्रीच्ड बैकअप होस्ट आपकी फाइलों को उजागर नहीं करता है। इसका परिणाम यह है: पासवर्ड के बिना डेटा किसी के द्वारा भी रिकवर नहीं किया जा सकता है, इसलिए इसकी एक प्रति सर्वर से दूर रखें।

क्या restic इंक्रीमेंटल बैकअप करता है?

हर restic स्नैपशॉट एक पूर्ण बैकअप की तरह व्यवहार करता है, जबकि इसकी लागत इंक्रीमेंटल स्टोरेज जितनी ही होती है। Restic फाइलों को टुकड़ों में विभाजित करता है और केवल उन्हीं टुकड़ों को अपलोड करता है जिन्हें रिपॉजिटरी ने पहले स्टोर नहीं किया है, इसलिए एक दैनिक रन लगभग वही ट्रांसफर करता है जो उस दिन बदला है। पारंपरिक इंक्रीमेंटल योजनाओं के विपरीत, इसमें रिप्ले करने के लिए कोई चेन नहीं होती: कोई भी स्नैपशॉट सीधे रिस्टोर हो जाता है और पुराने स्नैपशॉट को हटाने से कभी भी नया स्नैपशॉट खराब नहीं होता है।

मैं restic बैकअप से फाइलें कैसे रिस्टोर करूँ?

स्नैपशॉट ID खोजने के लिए restic snapshots चलाएं, फिर उसे रिस्टोर करने के लिए restic restore <id> --target /some/empty/dir चलाएं, केवल उसका कुछ हिस्सा रिस्टोर करने के लिए --include /path जोड़ें। latest ID की जगह काम करता है। Restic टारगेट के तहत मूल डायरेक्टरी संरचना को फिर से बनाता है, इसलिए /etc/ssh को रिस्टोर करने पर वह /some/empty/dir/etc/ssh में आता है। इसकी आवश्यकता पड़ने से पहले इसका अभ्यास करें, क्योंकि एक अनटेस्टेड बैकअप केवल एक अफवाह है।

मुझे restic बैकअप कितनी बार चलाना चाहिए?

सर्वर के लिए दैनिक (nightly) आधार एक उचित न्यूनतम मानक है, और डिडुप्लीकेशन इसे सस्ता बनाता है: प्रत्येक रन केवल उन्हीं टुकड़ों को अपलोड करता है जो पिछले रन के बाद से बदल गए हैं। जो डेटा तेजी से बदलता है, या जिसे खोने पर एक दिन का नुकसान भी भारी पड़ सकता है, उसे उसी टाइमर पैटर्न के साथ हर कुछ घंटों में चलाया जा सकता है। आवृत्ति आसान हिस्सा है; नियमित रूप से restic check भी चलाएं और मासिक रूप से रिस्टोर ड्रिल करें, क्योंकि बिना सत्यापन के शेड्यूल केवल एक झूठा दिलासा है।

यदि मैं अपना restic रिपॉजिटरी पासवर्ड खो दूँ तो क्या होगा?

बैकअप रिकवर नहीं किए जा सकते। Restic के एन्क्रिप्शन में कोई बैक डोर या रिसेट नहीं है, इसलिए पासवर्ड उतना ही महत्वपूर्ण है जितना कि स्वयं बैकअप। इसकी एक प्रति अपने पासवर्ड मैनेजर में और किसी अन्य सुरक्षित स्थान पर रखें जो बैकअप किए गए सर्वर पर न हो। जब तक आपके पास एक्सेस है, restic key add उसी रिपॉजिटरी के लिए दूसरा पासवर्ड रजिस्टर कर सकता है, जो आपको एक बैकअप विकल्प देता है।