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 के अपने प्रारूप में एक डायरेक्टरी है, जो एन्क्रिप्टेड ब्लब्स से भरी होती है, और इसे केवल restic ही पढ़ सकता है। आप इसे कभी भी मैन्युअल रूप से एडिट नहीं करते हैं; आप restic कमांड्स और -r पते के माध्यम से इससे संवाद करते हैं।

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

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

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

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, जिसे स्क्रिप्ट पहले से ही हर रात चलाती है। यह रिपॉजिटरी की संरचना और इंडेक्स को सत्यापित करती है, ताकि बैकअप होस्ट पर होने वाली किसी भी गुप्त खराबी (silent corruption) का पता रिस्टोर के दिन के बजाय अगली रात ही चल जाए। महीने में एक बार, इसका गहन संस्करण चलाएं, जो वास्तविक डेटा के यादृच्छिक दसवें हिस्से को डाउनलोड करता है और क्रिप्टोग्राफिक रूप से सत्यापित करता है:

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%

चूंकि हर बार उप-सेट (subset) यादृच्छिक होता है, इसलिए मासिक रन पूरी रिपॉजिटरी की जाँच कर लेते हैं, बिना पूरे डेटा को डाउनलोड करने की लागत के।

दूसरा, रिस्टोर ड्रिल। ऊपर दिए गए root shell में रहते हुए, नवीनतम स्नैपशॉट से एक वास्तविक डायरेक्टरी को एक अस्थायी स्थान (scratch location) पर रिस्टोर करें और इसकी तुलना लाइव फाइलों से करें:

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 backups एन्क्रिप्टेड होते हैं?

हाँ, हमेशा। प्रत्येक restic repository AES-256 के साथ एन्क्रिप्टेड होती है, इसमें कोई unencrypted मोड नहीं है, और हर कमांड के लिए repository पासवर्ड की आवश्यकता होती है। repository को स्टोर करने वाली मशीन या प्रदाता के पास केवल एन्क्रिप्टेड blobs होते हैं, इसलिए compromised backup host आपकी फाइलों को उजागर नहीं करता है। इसका परिणाम स्पष्ट है: पासवर्ड के बिना डेटा को कोई भी रिकवर नहीं कर सकता, इसलिए इसकी एक कॉपी सर्वर से दूर सुरक्षित रखें।

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

हर restic snapshot एक पूर्ण बैकअप की तरह काम करता है, जबकि इसकी स्टोरेज लागत इंक्रीमेंटल होती है। Restic फाइलों को chunks में विभाजित करता है और केवल उन्हीं chunks को अपलोड करता है जो repository में पहले से मौजूद नहीं हैं, इसलिए nightly run में लगभग उतना ही डेटा ट्रांसफर होता है जितना उस दिन बदला है। पारंपरिक इंक्रीमेंटल स्कीमों के विपरीत, इसमें replay करने के लिए कोई chain नहीं होती: कोई भी snapshot सीधे restore हो जाता है और पुराने snapshot को डिलीट करने से नया snapshot कभी खराब नहीं होता।

मैं restic बैकअप से फाइलें कैसे restore करूँ?

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

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

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

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

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