Restic बॅकअप VPSच्या बाहेर कसे ठेवावे?

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

Restic हे विनामूल्य, मुक्त-स्रोत बॅकअप साधन आहे. ते तुमच्या फाइल्सचे एन्क्रिप्ट केलेले आणि डीडुप्लिकेशन केलेले स्नॅपशॉट्स दुसऱ्या ठिकाणी असलेल्या repository कडे पाठवते: दुसरा VPS, घरातील मशीन किंवा S3-compatible object storage. या मार्गदर्शकात Ubuntu 24.04 वर त्याची स्थापना करण्यापासून SFTP द्वारे repository तयार करणे, पहिला बॅकअप घेणे, nightly systemd timer, retention policy आणि संपूर्ण प्रक्रिया कार्यरत असल्याचे सिद्ध करणारी restore drill यांची मांडणी केली आहे. गंतव्य दुसरे मशीन असणे आवश्यक आहे, कारण त्याच सर्व्हरवर असलेली प्रत सर्व्हरसह नष्ट होते.

ज्या मशीनचा बॅकअप घेतला जातो त्याच मशीनवरील backup/ directory तुम्हाला केवळ एका गोष्टीपासून वाचवते: चुकून फाइल हटवण्यापासून. डिस्क निकामी झाल्यास ती प्रत टिकत नाही, कारण ती त्याच डिस्कवर असते. root असलेल्या आक्रमणकर्त्यापासून ती सुरक्षित राहत नाही, कारण तो आधी त्या प्रती हटवतो. VPS स्वतःच हटवणाऱ्या account-संबंधित चुकीपासूनही ती सुरक्षित राहत नाही. जगातील सर्वात अकार्यक्षम datacenter याच array वर डेटासोबत backup_final_v2_REAL नावाची tarball ठेवण्याची गंमत करते, आणि ही गंमत परिणामकारक ठरते कारण आपल्यापैकी अनेकांनी नेमके हेच केले आहे. प्रत सर्व्हरच्या बाहेर ठेवणे हा नियम आहे, आणि तो पाळण्याचा restic हा सर्वात कमी त्रासदायक मार्ग आहे.

Restic च्या चार मूलभूत संकल्पना

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

Snapshot. तुम्ही backup केलेल्या files ची एखाद्या विशिष्ट वेळेवरील प्रतिमा. प्रत्येक backup run मुळे एक snapshot तयार होते. प्रत्येक snapshot स्वतंत्रपणे restore करता येते. त्या क्षणी तुमच्या डेटाची पूर्ण प्रत असल्याप्रमाणे प्रत्येक snapshot कार्य करते.

Deduplication. Restic files चे content-defined chunks मध्ये विभाजन करते आणि repository ने यापूर्वी पाहिलेले नसलेले chunksच upload करते. पहिल्या backup मध्ये सर्व डेटा upload होतो. त्यानंतरच्या प्रत्येक run मध्ये साधारणपणे बदललेला डेटाच upload होतो. 20 GB पैकी 50 MB डेटा बदललेल्या nightly snapshot साठी सुमारे 50 MB जागा लागते. त्यामुळे डझनावधी snapshots ठेवणे स्वस्त ठरते.

By default encryption. Restic repository नेहमी encrypted असते (AES-256), आणि प्रत्येक command साठी repository password आवश्यक असतो. Backup host किंवा storage provider ला केवळ encrypted blobs दिसतात. याचा गंभीर परिणाम असा आहे: password गमावल्यास डेटा कायमचा गमावला जातो. 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 आवृत्त्या स्थिर केल्या जातात, म्हणून हा फरक आहे. येथे त्याचा परिणाम होत नाही: या मार्गदर्शकातील सर्व कार्यांसाठी 0.16.4 पुरेसे आहे. वेगातील सुधारणा मिळवण्यासाठी तुम्हाला नवीनतम release हवे असल्यास, restic प्रकल्पाच्या GitHub releases पृष्ठावरून अधिकृत single-binary build डाउनलोड करा, ते bunzip2 वापरून unpack करा आणि /usr/local/bin/restic येथे स्थापित करा; restic स्थापित करण्यासाठी याव्यतिरिक्त काहीही आवश्यक नाही.

SFTP द्वारे दुसऱ्या सर्व्हरवर repository तयार करा

तुम्हाला destination machine आवश्यक आहे. दुसरा छोटा VPS हा नेहमीचा पर्याय आहे. SSH server आणि पुरेशी disk space असलेली कोणतीही मशीन चालते. Restic SFTP (SSH द्वारे file transfer) वापरते. त्यामुळे backup host वर काहीही install करण्याची आवश्यकता नाही. या मार्गदर्शकात backup host 10.0.0.12 आहे आणि वापरकर्ता restic आहे. त्या वापरकर्त्याचे नाव backup ठेवू नका. Ubuntu आणि Debian प्रत्येक install मध्ये backup नावाचे reserved system account (uid 34, login shell नसलेले) देतात. त्यामुळे adduser backup अयशस्वी होते आणि ssh backup@... nologin मध्ये जाते.

रात्रीचे job ज्या server चा backup घेतला जात आहे त्यावर root म्हणून चालेल. त्यामुळे root ला backup host वर key login आवश्यक आहे. passphrase नसलेली स्वतंत्र key तयार करा. कारण पहाटे 3 वाजता ती टाइप करण्यासाठी कोणीही उपस्थित नसते. ती key दुसऱ्या host वर 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 व्यवस्थापनाची मूलतत्त्वे या विभागात model, permissions आणि नंतर key revoke करण्याची पद्धत स्पष्ट केली आहे.

आता repository password तयार करा. तो root-only file मध्ये strong password म्हणून 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

दुसरा पर्याय 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 साठी समान आहे. या मार्गदर्शकाच्या उर्वरित भागात SFTP address दाखवला आहे. तुमचा address त्याऐवजी वापरा.

excludes सह पहिला backup

तुम्ही पुन्हा स्थापित करू शकत नाही असा data backup करा; संपूर्ण filesystem चा नाही. पुन्हा install केल्यावर operating system परत मिळते; तुमचे configuration आणि data परत मिळत नाहीत. सामान्य VPS साठी याचा अर्थ /etc, /home आणि तुमचे applications state जिथे ठेवतात ती ठिकाणे, जसे /srv किंवा /var/www. caches वगळा, कारण ते मोठे असतात, दररोज बदलत राहतात आणि स्वतः पुन्हा तयार होतात:

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 बदलल्या आणि काही MiB जोडले गेले असे दिसते, कारण deduplication फक्त नवीन chunks upload करते. तुमच्याकडे असलेल्या snapshots ची यादी पहा:

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

प्रत्येक snapshot मध्ये ID, वेळ आणि त्यात असलेले paths दिसतात. restore करण्यासाठी हेच IDs वापरता.

systemd timer वापरून रात्रीची कामे

प्रत्येक command मध्ये repository address टाइप करणे कंटाळवाणे होते. तसेच, हाताने चालवलेला backup एका महिन्याच्या आत बंद पडतो. या दोन्ही समस्यांसाठी एक script आणि एक timer पुरेसे आहेत. Script मध्ये restic वाचत असलेले दोन environment variables, RESTIC_REPOSITORY आणि RESTIC_PASSWORD_FILE, सेट केले आहेत. त्यामुळे त्यातील प्रत्येक 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 पाहू. Script चालवणारी oneshot service आणि ती service दररोज रात्री 03:00 वाजता सुरू करणारा timer वापरा. येथे cron line पेक्षा timer अधिक योग्य आहे, कारण run चे logs journal मध्ये नोंदवले जातात आणि downtime नंतर server पुन्हा सुरू झाल्यावर Persistent=true चुकलेला 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 एकदा हाताने चालवून तिचे काम monitor करा:

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 हाताने लिहिण्याऐवजी तुम्ही त्यांची जोडी तयारही करू शकता:

या दोन files मागील संपूर्ण पद्धत, त्यात calendar syntax आणि service मध्ये वापरता येणारे hardening directives यांसह, VPS वर systemd service म्हणून program चालवणे येथे दिली आहे.

पुनर्संचयित करेपर्यंत बॅकअप ही केवळ अफवा असते

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

पहिली तपासणी म्हणजे restic check, जी स्क्रिप्ट आधीच दररोज रात्री चालवते. ती repository ची रचना आणि index पडताळते. त्यामुळे बॅकअप host वरील मूक corruption restore च्या दिवशी नव्हे, तर पुढील रात्रीच आढळते. महिन्यातून एकदा अधिक सखोल आवृत्ती चालवा. ती प्रत्यक्ष डेटापैकी यादृच्छिक दहावा भाग download करून cryptographic पद्धतीने पडताळते:

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 यादृच्छिक असल्यामुळे, पूर्ण download चा खर्च न करता मासिक चालवण्यांमधून संपूर्ण repository तपासली जाते.

दुसरी तपासणी म्हणजे 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 दर महिन्याला करा. तसेच वर्षातून एकदा किंवा दोनदा पूर्ण आवृत्ती करा: नवीनतम snapshot संपूर्णपणे scratch VPS वर restore करा आणि तुमचा application त्यावरून प्रत्यक्ष सुरू होतो का ते तपासा. दबावाखाली हे कार्य करून घ्यायची वेळ येईल त्या दिवशी, तुम्ही यापूर्वीच केलेली routine तुमच्याकडे तयार असावी.

ठेवण: विसरा आणि छाटणी करा

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

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

डेटाबेस: प्रथम dump घ्या, त्यानंतर dump चा backup घ्या

Restic फाइल्स वाचताना त्यांची प्रत तयार करते आणि डेटाबेस सतत आपल्या फाइल्समध्ये लिहित असतो. लिहिण्याच्या प्रक्रियेदरम्यान घेतलेली live डेटाबेस फाइल पुनर्संचयित केल्यावर दूषित डेटाबेस तयार होतो, कारण त्या प्रतीमध्ये लेखनापूर्वीची आणि लेखनानंतरची पाने मिसळलेली असतात. यावरील प्रमाणित उपाय असा आहे: डेटाबेस इंजिनकडून फाइलमध्ये सुसंगत export तयार करून घ्या आणि त्यानंतर restic कडून त्या फाइलचा backup घेऊ द्या.

PostgreSQL साठी restic-backup.sh च्या सुरुवातीला, restic backup command च्या आधी dump ची ओळ जोडा आणि 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 हीच भूमिका पार पाडते. संपूर्ण पद्धतीच्या उदाहरणासाठी Nextcloud backup विभाग maintenance mode सुरू करतो, Postgres चा dump घेतो आणि फाइल्स एकाच सुसंगत संचाप्रमाणे कॉपी करतो. प्रत्येक रात्री server वरून restic ने बाहेर पाठवायचा संच नेमका हाच असतो. SQLite मध्येही हीच कल्पना वापरली जाते, परंतु अधिक सोप्या पद्धतीने: Vaultwarden मार्गदर्शक काही सेकंदांसाठी container थांबवून db.sqlite3 ची cold copy तयार करतो आणि restic server वरून बाहेर पाठवतो ती हाच archive असतो.

FAQ

restic बॅकअप एन्क्रिप्ट केलेले असतात का?

होय, नेहमी. प्रत्येक restic repository AES-256 ने एन्क्रिप्ट केलेले असते. एन्क्रिप्शनशिवाय कोणताही मोड उपलब्ध नाही. प्रत्येक command साठी repository password आवश्यक असतो. repository साठवणारे machine किंवा provider कडे केवळ एन्क्रिप्ट केलेले blobs असतात. त्यामुळे breached backup host मुळे तुमच्या files उघड होत नाहीत. मात्र यासाठी एक महत्त्वाची अट आहे: password शिवाय कोणालाही data पुनर्प्राप्त करता येत नाही. त्यामुळे त्याची एक प्रत server पासून वेगळ्या सुरक्षित ठिकाणी साठवा.

restic incremental backups करते का?

प्रत्येक restic snapshot पूर्ण backup प्रमाणे कार्य करते, परंतु त्यासाठी incremental storage लागते. restic files चे chunks मध्ये विभाजन करते आणि repository मध्ये आधीपासून साठवलेले नसलेले chunksच upload करते. त्यामुळे nightly run मध्ये साधारणपणे त्या दिवशी बदललेला data transfer होतो. पारंपरिक incremental पद्धतींप्रमाणे येथे 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 जोडा. ID ऐवजी latest वापरता येते. Restic मूळ directory structure target अंतर्गत पुन्हा तयार करते. त्यामुळे /etc/ssh restore केल्यावर ते /some/empty/dir/etc/ssh मध्ये येते. ही प्रक्रिया गरज पडण्यापूर्वी सरावून पाहा, कारण तपासलेली नसलेली backup प्रत्यक्षात उपलब्ध आहे असे गृहीत धरता येत नाही.

restic backup किती वेळा चालवावे?

Server साठी nightly ही योग्य किमान वारंवारता आहे. Deduplication मुळे खर्च कमी राहतो, कारण प्रत्येक run मध्ये मागील run नंतर बदललेले chunksच upload केले जातात. जलद बदलणारा data किंवा एक दिवसाचा data गमावणेही गंभीर ठरणार असल्यास, त्यासाठी त्याच timer pattern सह दर काही तासांनी backup चालवता येते. Frequency हा उपायाचा एक भाग आहे. restic check नियमितपणे चालवा आणि दर महिन्याला restore drill करा. Verification शिवाय schedule वर अवलंबून राहणे सुरक्षिततेचा खोटा भास निर्माण करते.

restic repository password हरवल्यास काय होते?

Backups पुनर्प्राप्त करता येत नाहीत. Restic च्या encryption मध्ये back door किंवा reset सुविधा नाही. त्यामुळे password चे महत्त्व backups इतकेच आहे. त्याची एक प्रत password manager मध्ये आणि backed-up server व्यतिरिक्त टिकाऊ, सुरक्षित ठिकाणी ठेवा. अजून access उपलब्ध असताना, त्याच repository साठी दुसरा password नोंदवण्यासाठी restic key add वापरता येते. त्यामुळे तुमच्याकडे अतिरिक्त password उपलब्ध राहतो.