Restic se VPS backup kaise lein

एक ही server पर backup लेना backup क्यों नहीं है

Restic एक free, open source backup tool है। यह आपके files के encrypted और deduplicated snapshots को किसी दूसरी जगह भेजता है: जैसे कि दूसरा VPS, घर पर रखा कोई machine, या S3-compatible object storage। यह guide Ubuntu 24.04 पर iska setup dikhati hai. Ismein installation se lekar SFTP par repository banana, pehla backup lena, nightly systemd timer set karna, retention policy, aur restore karne ka process shamil hai. Destination hamesha ek dusra machine hona chahiye, kyunki agar copy usi server par hai, to server fail hone par backup bhi khatam ho jayega.

Jis machine ka backup liya ja raha hai, usi par backup/ directory rakhne se aap sirf ek hi cheez se bach sakte hain: galti se file delete hona. Agar disk fail ho jaye, to yeh backup kaam nahi aayega kyunki backup bhi usi disk par tha. Agar kisi attacker ke paas root access hai, to bhi yeh backup safe nahi hai kyunki attacker sabse pehle copies delete karta hai. Agar account ki kisi galti se VPS hi delete ho jaye, to bhi yeh backup nahi bachega. The world's least efficient datacenter ek joke hai jismein backup_final_v2_REAL naam ka tarball usi array par rakha hota hai jahan data hota hai. Yeh joke isliye chalta hai kyunki bahut se log bilkul yahi galti karte hain. Backup hamesha machine se bahar hona chahiye, aur restic is rule ko follow karne ka sabse aasaan tarika hai.

Restic के चार मुख्य विचार

Repository. वह स्थान जहाँ restic डेटा लिखता है। यह restic के अपने format में एक directory है, जो encrypted blobs से भरी होती है, और इसे केवल restic ही पढ़ सकता है। आपको इसे कभी भी मैन्युअल रूप से edit नहीं करना चाहिए; आप restic commands और -r address के माध्यम से इसके साथ इंटरैक्ट करते हैं।

Snapshot. आपके द्वारा बैकअप किए गए files का एक निश्चित समय का चित्र (point-in-time picture)। हर backup run एक snapshot बनाता है, हर snapshot को अलग से restore किया जा सकता है, और प्रत्येक उस समय के आपके डेटा की एक पूर्ण प्रति (complete copy) की तरह कार्य करता है।

Deduplication. Restic files को content-defined chunks में विभाजित करता है और केवल उन्हीं chunks को upload करता है जिन्हें repository ने पहले नहीं देखा है। पहला backup सब कुछ upload करता है; उसके बाद के हर run में केवल वही upload होता है जो लगभग बदल गया है। 20 GB के nightly snapshot में यदि 50 MB डेटा बदलता है, तो उसकी लागत लगभग 50 MB ही होगी, इसीलिए दर्जनों snapshots रखना सस्ता पड़ता है।

Encryption by default. एक restic repository हमेशा encrypted (AES-256) होती है, और हर command के लिए repository password की आवश्यकता होती है। backup host या storage provider को केवल encrypted blobs ही दिखाई देते हैं। इसका कठोर परिणाम यह है: यदि आप password खो देते हैं, तो डेटा हमेशा के लिए चला जाएगा, क्योंकि इसे इसी तरह design किया गया है। Password की एक प्रति उस स्थान पर रखें जो यह server न हो। यह इतना महत्वपूर्ण है कि नीचे दो बार इसका उल्लेख किया गया है।

Ubuntu 24.04 पर restic install करें

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

Ubuntu 24.04 पर यह restic 0.16.4 install करता है, जबकि current upstream release 0.19.1 है। यह अंतर इसलिए है क्योंकि LTS (long term support) release अपने package versions को freeze कर देता है। इस मामले में इससे कोई फर्क नहीं पड़ता: 0.16.4 इस guide के सभी कार्यों के लिए पर्याप्त है। यदि आप speed improvements के लिए नवीनतम release चाहते हैं, तो restic project के GitHub releases page से official single-binary build download करें, इसे bunzip2 से unpack करें, और इसे /usr/local/bin/restic में install करें; restic installation के लिए बस इतना ही आवश्यक है।

SFTP के माध्यम से दूसरे server पर repository बनाएँ

आपको एक destination machine की आवश्यकता होगी: आमतौर पर एक दूसरा छोटा VPS उपयोग किया जाता है, लेकिन कोई भी machine जिसमें SSH server और खाली disk हो, काम कर सकती है। Restic, SFTP (SSH के माध्यम से file transfer) का उपयोग करता है, इसलिए backup host पर किसी भी software को install करने की आवश्यकता नहीं है। इस guide में, backup host 10.0.0.12 है और user का नाम restic है। उस user का नाम backup न रखें: Ubuntu और Debian के हर installation में backup (uid 34, no login shell) नामक एक reserved system account होता है, इसलिए adduser backup fail हो जाएगा और ssh backup@... nologin में चला जाएगा।

Nightly job, backup किए जा रहे server पर root के रूप में चलेगी, इसलिए backup host के लिए root को key login की आवश्यकता होगी। बिना passphrase वाली एक dedicated key बनाएँ, क्योंकि रात के 3 बजे passphrase टाइप करने के लिए कोई इंसान मौजूद नहीं होगा, और इसे copy करें:

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 key management basics इसके model, permissions, और बाद में key को revoke करने का तरीका समझाता है।

इसके बाद, repository password। इसे केवल root के लिए उपलब्ध एक file में generate करें:

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

आगे बढ़ने से पहले, इस password को अपने password manager में copy कर लें। यदि यह VPS खराब हो जाता है, तो repository और यह password सब कुछ वापस ला सकते हैं; password के बिना repository कुछ भी वापस नहीं ला सकती।

Repository को initialise करें:

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

एक alternative destination S3-compatible object storage है, जो तब सही विकल्प है जब आप दूसरा machine नहीं चलाना चाहते। कोई भी S3-compatible bucket इसी तरह काम करता है; केवल address और दो credential variables बदलते हैं:

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 के बाद की सभी चीजें दोनों destinations के लिए समान हैं। इस guide का शेष भाग SFTP address दिखाता है; इसके स्थान पर अपना address उपयोग करें।

पहला backup, excludes के साथ

केवल उस data का backup लें जिसे आप reinstall नहीं कर सकते, पूरा filesystem नहीं। Operating system reinstall करने पर वापस मिल जाता है; लेकिन आपकी configuration और data नहीं मिलता। एक typical VPS के लिए इसका मतलब है /etc, /home, और जहाँ भी आपके applications state रखते हैं, जैसे कि /srv या /var/www। Caches को exclude करें, क्योंकि वे बड़े होते हैं, रोज़ बदलते रहते हैं, और वे खुद को rebuild कर लेते हैं:

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

पहला run सब कुछ upload करता है, इसलिए इसमें समय लगता है। उसी command को दोबारा चलाएँ और यह कुछ ही seconds में पूरा हो जाएगा। यह कुछ files changed और कुछ MiB added रिपोर्ट करेगा, क्योंकि deduplication केवल नए chunks को upload करता है। आपके पास क्या है, इसकी list देखें:

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

हर command में repository address टाइप करना थकाऊ हो जाता है, और हाथ से (manually) चलाए जाने वाले backup एक महीने के भीतर रुक जाते हैं। इन दोनों समस्याओं का समाधान एक script और एक timer है। script में restic द्वारा उपयोग किए जाने वाले दो environment variables, RESTIC_REPOSITORY और RESTIC_PASSWORD_FILE, सेट किए जाते हैं, जिससे script के अंदर हर command छोटा रहता है:

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 lines का विवरण अगले दो sections में दिया गया है। अब schedule की बात करते हैं: एक oneshot service जो script को चलाती है, और एक timer जो इसे हर रात 03:00 बजे चलाता है। यहाँ cron के बजाय timer बेहतर है क्योंकि run logs journal में जाते हैं, और Persistent=true downtime के बाद server के वापस चालू होते ही छूटा हुआ backup चला देता है।

# /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

Timer को enable करें, फिर service को एक बार manually चलाकर देखें:

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 बताता है कि अगला run कब होगा। आप इन्हें टाइप करने के बजाय unit files का pair generate भी कर सकते हैं:

Calendar syntax और service के hardening directives सहित इन दोनों files का पूरा pattern, running a program as a systemd service on a VPS में दिया गया है।

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

इस वाक्य को एक नियम की तरह मानें। यदि backup job हर रात सफलतापूर्वक (green) चलता है, तो यह केवल यह साबित करता है कि job चला है; यह इस बात का प्रमाण नहीं है कि आपका data वापस मिल जाएगा। इस कमी को पूरा करने के लिए दो जाँचें आवश्यक हैं।

पहली, restic check, जो script पहले से ही हर रात चलाती है। यह repository structure और index को verify करती है, जिससे backup host पर होने वाला silent corruption अगले दिन ही पकड़ा जाता है, restore के दिन नहीं। महीने में एक बार, इसका गहरा (deeper) version चलाएँ, जो actual data के रैंडम दसवें हिस्से (one tenth) को download और cryptographically verify करता है:

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 रैंडम होता है, इसलिए monthly runs पूरे repository को कवर कर लेते हैं और आपको पूरा download करने की आवश्यकता नहीं पड़ती।

दूसरी, restore drill। ऊपर दिए गए root shell में ही, नवीनतम snapshot से एक वास्तविक directory को scratch location पर restore करें और उसकी तुलना live files से करें:

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

यदि diff कुछ भी print नहीं करता है, तो इसका अर्थ है कि हर byte बिल्कुल समान वापस आया है, और यही एकमात्र प्रमाण है जो मायने रखता है। इसके बाद /srv/restore-drill को delete कर दें। इस drill को हर महीने करें, और साल में एक या दो बार full version करें: पूरे नवीनतम snapshot को एक scratch VPS पर restore करें और जाँचें कि आपका application वास्तव में उससे start हो रहा है या नहीं। जिस दिन आपको दबाव में इसकी आवश्यकता होगी, आप इसे एक routine के रूप में पाएंगे जिसे आप पहले ही कर चुके होंगे।

Retention: forget और prune

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

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

Databases: पहले dump लें, फिर dump का backup लें

Restic फाइलों को पढ़ते समय ही उनकी कॉपी बनाता है, जबकि database लगातार अपनी फाइलों में लिखता रहता है। यदि write प्रक्रिया के बीच में ही database file को capture किया जाए, तो वह corrupt हो जाती है। ऐसा इसलिए होता है क्योंकि copy में write से पहले और write के बाद के pages मिल जाते हैं। इसका समाधान standard है: database engine से एक consistent export file बनवाएं, और फिर restic को उस file का backup लेने दें।

PostgreSQL के लिए, restic-backup.sh के शीर्ष पर, restic backup command से पहले, एक dump line जोड़ें, और backup paths में dump directory को शामिल करें:

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

MariaDB और MySQL के लिए mysqldump समान कार्य करता है। पूरे pattern का उदाहरण देखने के लिए, Nextcloud backup section देखें। यह maintenance mode चालू करता है, Postgres को dump करता है, और फाइलों को एक consistent set के रूप में copy करता है। यही वह set है जिसे restic को हर रात server से ले जाना चाहिए। SQLite के लिए भी यही तरीका अपनाया जाता है, लेकिन कम जटिलता के साथ: Vaultwarden guide db.sqlite3 की cold copy लेने के लिए container को कुछ सेकंड के लिए रोकता है, और restic उसी archive को server से भेजता है।

FAQ

क्या restic backups encrypted होते हैं?

हाँ, हमेशा। हर restic repository AES-256 के साथ encrypted होती है। इसमें कोई unencrypted mode नहीं है, और हर command के लिए repository password की आवश्यकता होती है। repository को store करने वाली machine या provider के पास केवल encrypted blobs होते हैं, इसलिए backup host के compromise होने पर भी आपके files सुरक्षित रहते हैं। यह एक पूर्ण समझौता है: password के बिना कोई भी data recover नहीं कर सकता, इसलिए इसकी एक copy server से दूर सुरक्षित रखें।

क्या restic incremental backups करता है?

हर restic snapshot एक full backup की तरह काम करता है, लेकिन इसमें storage केवल incremental ही लगता है। Restic files को chunks में विभाजित करता है और केवल उन्हीं chunks को upload करता है जो repository में पहले से मौजूद नहीं हैं। इस तरह, nightly run में केवल उतना ही data transfer होता है जो उस दिन बदला है। पारंपरिक incremental schemes के विपरीत, इसमें replay करने के लिए कोई chain नहीं होती: कोई भी snapshot सीधे restore हो जाता है और पुराने snapshot को delete करने से नया snapshot खराब नहीं होता।

मैं restic backup से files कैसे restore करूँ?

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

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

Server के लिए nightly run एक उचित न्यूनतम सीमा है, और deduplication इसे किफायती बनाता है: हर run में केवल वही chunks upload होते हैं जो पिछले run के बाद बदले हैं। जो data तेज़ी से बदलता है, या जिसे एक दिन के लिए भी खोना नुकसानदेह हो सकता है, उसे समान timer pattern के साथ हर कुछ घंटों में चलाया जा सकता है। Frequency तय करना आसान है; restic check को भी नियमित रूप से चलाएँ और महीने में एक बार restore drill करें, क्योंकि बिना verification के schedule केवल एक झूठा भरोसा है।

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

Backups को recover नहीं किया जा सकता। Restic encryption में कोई back door या reset option नहीं है, इसलिए password उतना ही महत्वपूर्ण है जितना कि स्वयं backups। इसकी एक copy अपने password manager में और किसी अन्य टिकाऊ स्थान पर रखें जो backed-up server न हो। जब तक आपके पास access है, restic key add उसी repository के लिए दूसरा password register कर सकता है, जो आपको एक spare देता है।