Restic वापरून VPS बॅकअप कसा घ्यावा

एकाच सर्व्हरवरील बॅकअप हा बॅकअप का नसतो

Restic हे एक मोफत, open source बॅकअप टूल आहे. हे तुमच्या फाईल्सचे encrypted आणि deduplicated snapshots दुसऱ्या ठिकाणी पाठवते: जसे की दुसरा VPS, घरातील एखादे machine, किंवा S3-compatible object storage. हे मार्गदर्शक Ubuntu 24.04 वर याची मांडणी (setup) कशी करायची ते सांगते. यामध्ये installation पासून ते SFTP वर repository तयार करणे, पहिला backup घेणे, nightly systemd timer सेट करणे, retention policy आणि संपूर्ण प्रक्रिया यशस्वी आहे हे तपासण्यासाठी restore drill यांचा समावेश आहे. बॅकअपचे ठिकाण दुसरे machine असणे आवश्यक आहे, कारण एकाच सर्व्हरवर असलेली प्रत (copy) सर्व्हर निकामी झाल्यास नष्ट होते.

एकाच मशीनवरील backup/ directory तुम्हाला फक्त एकाच गोष्टीपासून वाचवू शकते: चुकून फाईल डिलीट होण्यापासून. जर disk निकामी झाली, तर तो बॅकअप वाचू शकत नाही, कारण तो त्याच disk वर होता. जर एखाद्या attacker कडे root access असेल, तर तो बॅकअप वाचवू शकत नाही, कारण ते आधी बॅकअपच्या प्रती (copies) डिलीट करतात. जर VPS स्वतःच डिलीट झाला, तर तो बॅकअप वाचवू शकत नाही. The world's least efficient datacenter मध्ये backup_final_v2_REAL नावाचा tarball त्याच array वर असल्याचे मजेत म्हटले आहे, जे सत्य आहे कारण अनेकांनी नेमकी हीच चूक केली आहे. बॅकअप दुसऱ्या मशीनवर असणे हा नियम आहे, आणि restic पाळण्यासाठी सर्वात सोपा मार्ग आहे.

Restic चे चार मुख्य संकल्पना

Repository. restic ज्या ठिकाणी डेटा writes करते ते ठिकाण. हे restic च्या स्वतःच्या format मध्ये असलेले एक directory आहे, जे encrypted blobs ने भरलेले असते आणि फक्त restic ते वाचू शकते. तुम्ही ते कधीही manually edit करू नका; restic commands आणि -r address द्वारे तुम्ही त्याशी संवाद साधू शकता.

Snapshot. तुम्ही backup घेतलेल्या files चा एका विशिष्ट वेळेचा (point-in-time) फोटो. प्रत्येक backup run एक snapshot तयार करते, प्रत्येक snapshot स्वतंत्रपणे restore करता येते, आणि प्रत्येक snapshot त्या क्षणी तुमच्या डेटाची पूर्ण प्रत (complete copy) म्हणून काम करते.

Deduplication. restic files ला content-defined chunks मध्ये विभागते आणि फक्त तेच chunks upload करते जे repository मध्ये आधीपासून नाहीत. पहिला backup सर्व काही upload करतो; त्यानंतरच्या प्रत्येक run मध्ये फक्त बदललेला डेटा (roughly what changed) 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 गमावला, तर तुमचा डेटा कायमचा नष्ट होईल, कारण हे system च्या design मध्येच आहे. password ची एक प्रत या server व्यतिरिक्त इतरत्र सुरक्षित ठेवा. ही गोष्ट इतकी महत्त्वाची आहे की खालील मजकुरात तिचा पुन्हा दोनदा उल्लेख केला आहे.

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 स्थिर (freeze) ठेवल्यामुळे हा फरक आहे; परंतु येथे त्याची गरज नाही: 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, no login shell) असतो, त्यामुळे adduser backup अयशस्वी होते आणि ssh backup@... nologin मध्ये जाते.

नाईटली जॉब (nightly job) बॅकअप घेतल्या जाणाऱ्या सर्व्हरवर root म्हणून रन होईल, म्हणून बॅकअप होस्टवर root साठी की-आधारित लॉगिन आवश्यक आहे. पासवर्डशिवाय एक समर्पित की तयार करा, कारण पहाटे 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 key management basics मध्ये मॉडेल, परवानग्या आणि नंतर की कशी रद्द करायची (revoke) याचे स्पष्टीकरण दिले आहे.

त्यानंतर, रिपॉझिटरी पासवर्ड. फक्त 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-compatible object storage हा आहे. जेव्हा तुम्हाला दुसरे मशीन चालवायचे नसते, तेव्हा हा योग्य पर्याय आहे. कोणताही S3-compatible bucket सारख्याच पद्धतीने काम करतो; फक्त पत्ता (address) आणि दोन क्रेडेंशियल व्हेरिएबल्स बदलतात:

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 पत्ता दर्शवतो; त्याऐवजी तुमचा स्वतःचा पत्ता वापरा.

पहिला backup, excludes सह

संपूर्ण filesystem backup करू नका, फक्त तुम्ही पुन्हा इंस्टॉल करू न शकतील असा डेटा backup करा. operating system पुन्हा इंस्टॉल केल्यावर परत मिळते; परंतु तुमची configuration आणि तुमचा डेटा नाही. सामान्य VPS साठी याचा अर्थ /etc, /home, आणि तुमची applications जिथे 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

पहिल्या वेळी सर्व काही upload होते, त्यामुळे त्याला वेळ लागतो. तोच command पुन्हा चालवा आणि तो काही सेकंदात पूर्ण होईल. तो काही files बदलल्याचे आणि काही MiB वाढल्याचे दर्शवेल, कारण deduplication फक्त नवीन chunks upload करते. तुमच्याकडे काय आहे याची यादी पहा:

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

प्रत्येक snapshot मध्ये एक ID, वेळ आणि त्यातील paths असतात. त्या IDs वरून तुम्ही डेटा restore करू शकता.

Nightly runs with a systemd timer

प्रत्येक वेळी repository address टाईप करणे कठीण होते आणि मॅन्युअली बॅकअप घेणे काही दिवसांत थांबते. या दोन्ही समस्यांवर एक script आणि एक timer द्वारे उपाय निघतो. script मध्ये restic द्वारे वापरले जाणारे RESTIC_REPOSITORY आणि RESTIC_PASSWORD_FILE हे दोन environment variables सेट केले जातात, ज्यामुळे 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 या ओळींची माहिती पुढील दोन विभागांमध्ये दिली आहे. आता वेळापत्रकाबद्दल: script रन करण्यासाठी एक oneshot service आणि दररोज रात्री 03:00 वाजता ती सुरू करण्यासाठी एक timer वापरला जातो. cron ऐवजी timer वापरणे अधिक चांगले आहे कारण run logs journal मध्ये साठवले जातात आणि Persistent=true मुळे server downtime नंतर पुन्हा सुरू होताच missed 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 एकदा मॅन्युअली रन करून ती व्यवस्थित काम करतेय की नाही ते तपासा:

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 मॅन्युअली टाईप करण्याऐवजी ते generate देखील करू शकता:

calendar syntax आणि service साठी लागणारे hardening directives या दोन्ही files मधील पूर्ण पद्धत running a program as a systemd service on a VPS मध्ये दिली आहे.

बॅकअप तेव्हाच खरा असतो जेव्हा तुम्ही तो रिस्टोर करू शकता

या वाक्याचा नियम म्हणून विचार करा. दररोज रात्री यशस्वीपणे (green) पूर्ण होणारा बॅकअप जॉब फक्त तो जॉब रन झाला हेच सिद्ध करतो; तुमचा डेटा परत मिळेल हे सिद्ध करत नाही. ही त्रुटी दूर करण्यासाठी दोन तपासण्या आवश्यक आहेत.

पहिली, restic check, जी स्क्रिप्ट आधीच दररोज रात्री रन करते. ही प्रक्रिया रिपॉझिटरी स्ट्रक्चर आणि इंडेक्स तपासते, ज्यामुळे बॅकअप होस्टवर झालेली 'silent corruption' रिस्टोरच्या दिवशी समजण्याऐवजी पुढच्या रात्रीच पकडली जाते. महिन्यातून एकदा, अधिक सखोल आवृत्ती (deeper version) रन करा, जी प्रत्यक्ष डेटाचा कोणताही 10% भाग डाउनलोड करून त्याचे क्रिप्टोग्राफिकली verification करते:

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 रँडम असल्याने, पूर्ण डेटा डाउनलोड न करता मासिक रनद्वारे संपूर्ण रिपॉझिटरीची तपासणी पूर्ण होते.

दुसरी, रिस्टोर ड्रिल (restore drill). वरीलप्रमाणे रूट शेलमध्ये असताना, नवीनतम snapshot मधून एक प्रत्यक्ष डिरेक्टरी scratch location वर रिस्टोर करा आणि तिची तुलना live फाइल्सशी करा:

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

जर diff मध्ये काहीही प्रिंट झाले नाही, तर याचा अर्थ प्रत्येक byte तंतोतंत परत आला आहे, आणि हेच एकमेव महत्त्वाचे पुरावे आहे. त्यानंतर /srv/restore-drill डिलीट करा. ही ड्रिल दरमहा करा, आणि वर्षातून एकदा किंवा दोनदा पूर्ण आवृत्ती करा: संपूर्ण नवीनतम snapshot एका scratch VPS वर रिस्टोर करा आणि तुमचे application त्यातून खरोखर सुरू होते की नाही ते तपासा. ज्या दिवशी तुम्हाला दबावाखाली हे काम करायचे असेल, त्या दिवशी ती प्रक्रिया तुमच्यासाठी एक नियमित सवय (routine) असावी.

Retention: forget plus prune

नियम (policy) नसल्यास, snapshots सतत वाढत राहतात आणि repository चा आकार वाढत जातो. स्क्रिप्टमधील forget ओळ दररोज रात्री policy लागू करते: --keep-daily 7 गेल्या सात दिवसांसाठी दिवसाला एक snapshot ठेवते, --keep-weekly 4 चार आठवड्यांसाठी आठवड्याला एक, आणि --keep-monthly 6 सहा महिन्यांसाठी महिन्यातून एक ठेवते. ज्या गोष्टींना कोणत्याही नियमाने संरक्षण दिलेले नाही, त्या काढून टाकल्या जातात (forgotten).

केवळ forget वापरल्यास फक्त snapshot records निघून जातात; डेटा chunks जोपर्यंत कोणीतरी ते डिलीट करत नाही तोपर्यंत repository मध्येच राहतात. --prune हे काम करते: ते असे chunks शोधते ज्यांचा कोणताही snapshot reference उरलेला नाही आणि त्यांना डिलीट करते; यामुळेच प्रत्यक्ष डिस्क स्पेस रिकव्हर होते. Prune हे प्रत्यक्ष repository वर काम करते, म्हणून मोठ्या repository साठी काही लोक forget दररोज आणि --prune दर आठवड्याला चालवतात; सामान्य VPS आकारासाठी, दररोज चालवणे पुरेसे आहे.

Databases: प्रथम dump करा, त्यानंतर dump चा backup घ्या

Restic फाईल्स वाचतानाच त्यांची प्रत (copy) तयार करते, तर डेटाबेस सतत त्याच्या फाईल्समध्ये माहिती लिहित असतो. जर डेटाबेस फाईल लिहिण्याच्या प्रक्रियेत असताना (mid-write) कॅप्चर केली, तर ती corrupt डेटाबेस म्हणून रिस्टोर होते; कारण त्या प्रतमध्ये लिहिण्यापूर्वीच्या आणि लिहिण्यानंतरच्या पेजेसचे मिश्रण असते. याचे उपायमानक निराकरण असे आहे: डेटाबेस इंजिनला फाईलमध्ये एक सुसंगत (consistent) export तयार करण्यास सांगा आणि त्यानंतर restic ला ती फाईल backup करण्यास द्या.

PostgreSQL साठी, restic backup कमांडच्या आधी, restic-backup.sh च्या सुरुवातीला एक dump लाईन जोडा आणि backup paths मध्ये dump डिरेक्टरी समाविष्ट करा:

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

MariaDB आणि MySQL साठी mysqldump हीच भूमिका बजावते. संपूर्ण पॅटर्नचे उदाहरण पाहण्यासाठी, Nextcloud backup section मध्ये maintenance mode चालू केला जातो, Postgres dump केला जातो आणि फाईल्सचा एक सुसंगत संच कॉपी केला जातो; हा तोच संच आहे जो restic ने दररोज रात्री सर्व्हरवरून नेणे आवश्यक आहे. SQLite साठी हीच संकल्पना अधिक सोप्या पद्धतीने वापरली जाते: Vaultwarden guide मध्ये db.sqlite3 ची cold copy घेण्यासाठी कंटेनर काही सेकंदांसाठी थांबवला जातो, आणि restic त्या archive चा सर्व्हरवरून backup घेते.

FAQ

restic backups एन्क्रिप्टेड असतात का?

हो, नेहमीच. प्रत्येक restic repository AES-256 ने एन्क्रिप्ट केलेले असते. यामध्ये कोणताही अन-एन्क्रिप्टेड मोड उपलब्ध नाही आणि प्रत्येक कमांडसाठी repository पासवर्ड आवश्यक असतो. repository स्टोअर करणाऱ्या मशीन किंवा प्रोव्हायडरकडे फक्त एन्क्रिप्टेड blobs असतात, त्यामुळे बॅकअप होस्ट हॅक झाला तरी तुमची फाईल्स सुरक्षित राहतात. याचे नियम अत्यंत कडक आहेत: पासवर्डशिवाय कोणीही डेटा रिकव्हर करू शकत नाही, म्हणून त्याची एक प्रत सर्व्हरपासून दूर सुरक्षित ठेवा.

restic incremental backups करते का?

प्रत्येक restic snapshot पूर्ण बॅकअपप्रमाणे काम करते, परंतु स्टोरेजमध्ये फक्त incremental डेटा वापरते. restic फाईल्सचे chunks मध्ये विभाजन करते आणि फक्त तेच chunks अपलोड करते जे repository मध्ये आधीपासून नाहीत. त्यामुळे दररोजचा बॅकअप फक्त त्या दिवसातील बदललेला डेटाच ट्रान्सफर करतो. पारंपारिक incremental पद्धतींप्रमाणे यामध्ये कोणतीही 'chain' नसते: कोणताही snapshot थेट रिस्टोर करता येतो आणि जुना snapshot डिलीट केल्यामुळे नवीन snapshot खराब होत नाही.

restic बॅकअपमधून फाईल्स रिस्टोर कशा करायच्या?

snapshot ID शोधण्यासाठी restic snapshots चालवा, त्यानंतर रिस्टोर करण्यासाठी restic restore <id> --target /some/empty/dir वापरा. फक्त काही भाग रिस्टोर करण्यासाठी --include /path जोडा. ID च्या ऐवजी latest वापरता येते. restic टार्गेट डिरेक्टरीमध्ये मूळ directory structure पुन्हा तयार करते, त्यामुळे /etc/ssh रिस्टोर केल्यास ते /some/empty/dir/etc/ssh मध्ये येईल. प्रत्यक्ष गरजेच्या वेळी अडचण येऊ नये म्हणून याचा सराव आधीच करून घ्या, कारण न तपासलेला बॅकअप हा केवळ एक अफवा आहे.

मी restic backup किती वेळा चालवला पाहिजे?

सर्व्हरसाठी दररोज रात्री (nightly) बॅकअप घेणे योग्य आहे. deduplication मुळे हा खर्च कमी होतो: प्रत्येक वेळी फक्त गेल्या वेळेपासून बदललेले chunks अपलोड होतात. वेगाने बदलणारा किंवा दिवसाचाही डेटा गमावणे नुकसानकारक ठरेल असा डेटा, दर काही तासांनी त्याच वेळेच्या पॅटर्ननुसार बॅकअप घेऊ शकता. वारंवारता ठरवणे सोपे आहे; परंतु नियमितपणे restic check चालवा आणि दर महिन्याला रिस्टोरचा सराव (drill) करा, कारण पडताळणीशिवाय ठेवलेला शेड्यूल हा केवळ एक आभास आहे.

जर मी माझा restic repository पासवर्ड हरवून बसलो तर काय होईल?

बॅकअप्स रिकव्हर करता येणार नाहीत. restic च्या एन्क्रिप्शनमध्ये कोणताही 'back door' किंवा 'reset' पर्याय नाही, त्यामुळे पासवर्ड बॅकअपइतकाच महत्त्वाचा आहे. त्याची एक प्रत तुमच्या password manager मध्ये किंवा बॅकअप घेतलेल्या सर्व्हरव्यतिरिक्त इतर कोणत्याही सुरक्षित ठिकाणी ठेवा. जोपर्यंत तुमच्याकडे ॲक्सेस आहे, तोपर्यंत तुम्ही restic key add वापरून त्याच repository साठी दुसरा पासवर्ड रजिस्टर करू शकता, ज्यामुळे तुमच्याकडे एक बॅकअप पासवर्ड म्हणून राहील.