Resticతో VPS బ్యాకప్‌ను మరో సర్వర్‌కు పంపడం

ఒకే సర్వర్‌లోని బ్యాకప్ అసలు బ్యాకప్ ఎందుకు కాదు

Restic అనేది ఉచిత, ఓపెన్ సోర్స్ బ్యాకప్ సాధనం. ఇది మీ ఫైళ్లను గుప్తీకరించిన, డూప్లికేషన్ తొలగించిన snapshotలుగా వేరే ప్రదేశంలోని repositoryకి పంపుతుంది. ఆ ప్రదేశం రెండవ VPS, ఇంట్లోని ఒక machine లేదా S3-compatible object storage కావచ్చు. ఈ guideలో Ubuntu 24.04లో install చేయడం నుంచి SFTP ద్వారా repository ఏర్పాటు, మొదటి backup, రాత్రిపూట అమలయ్యే systemd timer, retention policy, మొత్తం వ్యవస్థ సరిగ్గా పనిచేస్తుందని నిర్ధారించే restore drill వరకు వివరించబడింది. Destination మరొక machineలో ఉండాలి. ఎందుకంటే అదే serverలో ఉన్న copy, serverతోపాటు నశిస్తుంది.

బ్యాకప్ చేయబడుతున్న serverలోని backup/ directory మిమ్మల్ని ఒక సమస్య నుంచి మాత్రమే రక్షిస్తుంది: పొరపాటున fileని delete చేయడం. అది విఫలమైన disk నుంచి రక్షించదు, ఎందుకంటే ఆ directory అదే diskలో ఉంది. root కలిగిన attacker నుంచి కూడా రక్షించదు, ఎందుకంటే వారు ముందుగా copiesని delete చేయగలరు. VPSనే తొలగించే account పొరపాటు నుంచి కూడా రక్షించదు. ప్రపంచంలోనే అత్యంత అసమర్థమైన datacenter అనే మాట, data ఉన్న అదే arrayలో backup_final_v2_REAL పేరుతో ఉన్న tarball గురించి చేసే జోక్. మనలో చాలామంది సరిగ్గా అదే పని చేసి ఉండటంతో ఆ జోక్ సరిపోతుంది. Server వెలుపల ఉంచడం నియమం. దాన్ని పాటించడానికి restic అత్యల్ప ఇబ్బందికరమైన మార్గం.

నాలుగు Restic ప్రాథమిక భావనలు

Repository. restic డేటాను వ్రాసే స్థలం. ఇది restic స్వంత ఫార్మాట్‌లోని ఒక directory. ఇందులో encrypted blobs ఉంటాయి. దీన్ని restic మాత్రమే చదవగలదు. దీన్ని చేతితో ఎప్పుడూ మార్చవద్దు. restic commands మరియు -r address ద్వారా మాత్రమే దీన్ని ఉపయోగించండి.

Snapshot. మీరు backup చేసిన files కు సంబంధించిన ఒక నిర్దిష్ట సమయపు ప్రతిరూపం. ప్రతి backup run ఒక snapshot ను సృష్టిస్తుంది. ప్రతి snapshot ను స్వతంత్రంగా restore చేయవచ్చు. ప్రతి snapshot ఆ సమయానికి మీ డేటా యొక్క పూర్తి copy లాగా పనిచేస్తుంది.

Deduplication. Restic files ను content-defined chunks గా విభజిస్తుంది. Repository ఇంతకు ముందు చూడని chunks ను మాత్రమే upload చేస్తుంది. మొదటి backup మొత్తం డేటాను upload చేస్తుంది. ఆ తర్వాత ప్రతి run లో మారిన డేటాకు సమానమైన పరిమాణం మాత్రమే సాధారణంగా upload అవుతుంది. 20 GB nightly snapshot లో 50 MB మారితే, దానికి సుమారు 50 MB మాత్రమే అవసరం అవుతుంది. అందుకే dozens of snapshots ను ఉంచడం తక్కువ ఖర్చుతో సాధ్యమవుతుంది.

డిఫాల్ట్‌గా Encryption. Restic repository ఎల్లప్పుడూ encrypted గానే ఉంటుంది (AES-256). ప్రతి command కు repository password అవసరం. Backup host లేదా storage provider కు encrypted blobs మాత్రమే కనిపిస్తాయి. దీని ముఖ్యమైన పరిణామం: password ను కోల్పోతే, డేటా శాశ్వతంగా మరియు ఉద్దేశపూర్వకంగా తిరిగి పొందలేనిదిగా మారుతుంది. Password యొక్క ఒక copy ని ఈ 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 స్థిరంగా ఉంచడం వల్ల ఈ వ్యత్యాసం ఉంది. ఈ సందర్భంలో ఇది సమస్య కాదు: ఈ గైడ్‌లోని అన్ని పనులకు 0.16.4 సరిపోతుంది. వేగం మెరుగుదలల కోసం తాజా release కావాలంటే, restic ప్రాజెక్ట్ GitHub releases పేజీ నుంచి అధికారిక single-binary buildను download చేసి, bunzip2తో unpack చేసి, /usr/local/bin/resticలో ఇన్‌స్టాల్ చేయండి. restic ఇన్‌స్టాలేషన్‌కు దీనికి మించి మరేమీ అవసరం లేదు.

SFTP ద్వారా మరొక server పై repositoryని సృష్టించండి

మీకు destination machine అవసరం. సాధారణంగా రెండో చిన్న VPS సరిపోతుంది. SSH server మరియు అదనపు disk ఉన్న ఏ machine అయినా పనిచేస్తుంది. Restic, SFTP (SSH ద్వారా file transfer)ను ఉపయోగిస్తుంది. కాబట్టి backup hostపై ఏదీ install చేయాల్సిన అవసరం లేదు. ఈ guideలో backup host 10.0.0.12, user పేరు restic. ఆ userకు backup అని పేరు పెట్టవద్దు. Ubuntu మరియు Debian ప్రతి installationలో backup అనే reserved system accountను (uid 34, login shell లేదు) అందిస్తాయి. అందువల్ల adduser backup విఫలమవుతుంది, అలాగే ssh backup@..., nologinలోకి చేరుతుంది.

బ్యాకప్ చేయాల్సిన serverపై nightly job rootగా నడుస్తుంది. కాబట్టి rootకు backup hostలో key login అవసరం. Passphrase లేకుండా ప్రత్యేక keyని సృష్టించండి. రాత్రి 3amకు దాన్ని టైప్ చేయడానికి ఎవరూ ఉండరు. తర్వాత దాన్ని 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 ప్రాథమికాలు model, permissions, అలాగే తర్వాత keyని revoke చేసే విధానాన్ని వివరిస్తుంది.

తర్వాత repository passwordను సిద్ధం చేయండి. rootకు మాత్రమే అనుమతి ఉన్న fileలో బలమైన 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

రెండో machineను నిర్వహించకూడదనుకుంటే, ప్రత్యామ్నాయ destinationగా S3-compatible object storage సరైన ఎంపిక. ఏ 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ను ఉపయోగించండి.

excludeలతో మొదటి backup

మీరు మళ్లీ install చేయలేని dataను మాత్రమే backup చేయండి. మొత్తం filesystemను backup చేయవద్దు. operating systemను మళ్లీ install చేస్తే తిరిగి పొందవచ్చు. మీ configuration మరియు dataను మాత్రం అలా తిరిగి పొందలేరు. సాధారణ 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

మొదటి runలో మొత్తం data upload అవుతుంది. అందువల్ల కొంత సమయం పడుతుంది. అదే commandను మళ్లీ run చేస్తే అది కొన్ని secondsలో పూర్తవుతుంది. మారిన కొన్ని files మరియు జోడించిన కొన్ని MiB మాత్రమే report అవుతాయి. ఎందుకంటే deduplication కొత్త chunksను మాత్రమే upload చేస్తుంది. మీ వద్ద ఉన్న వాటి జాబితాను చూడండి:

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

ప్రతి snapshotలో ఒక ID, ఒక సమయం, అలాగే అందులో ఉన్న paths కనిపిస్తాయి. మీరు restore చేయాల్సింది ఈ IDsతోనే.

systemd టైమర్‌తో రాత్రివేళ అమలు

ప్రతి కమాండ్‌లో repository address టైప్ చేయడం విసుగుగా మారుతుంది. చేతితో అమలు చేసే backup ఒక నెలలోనే ఆగిపోతుంది. ఒక script మరియు ఒక timer ఈ రెండు సమస్యలను పరిష్కరిస్తాయి. Script restic చదివే రెండు environment variables, 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 లైన్ల వివరణను తదుపరి రెండు విభాగాల్లో చూడండి. ఇప్పుడు schedule చూద్దాం: script‌ను అమలు చేసే oneshot service, అలాగే ప్రతి రాత్రి 03:00కి దాన్ని ప్రారంభించే timer. ఇక్కడ timer, cron line కంటే మెరుగైనది. ఎందుకంటే అమలు journal‌లో log అవుతుంది. అలాగే downtime తర్వాత server మళ్లీ అందుబాటులోకి వచ్చిన వెంటనే missed backup‌ను 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

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 చూపిస్తుంది. Unit files‌ను చేతితో టైప్ చేయడానికి బదులుగా, మీరు ఆ రెండు files‌ను generate కూడా చేయవచ్చు:

ఈ రెండు files వెనుక ఉన్న పూర్తి విధానం, అందులో calendar syntax మరియు service‌లో ఉపయోగించగల hardening directives సహా, VPSలో systemd service‌గా ఒక program‌ను అమలు చేయడంలో ఉంది.

బ్యాకప్‌ను పునరుద్ధరించే వరకు అది కేవలం ఊహ మాత్రమే

ఈ వాక్యాన్ని ఆదేశంగా పరిగణించండి. ప్రతి రాత్రి విజయవంతంగా పూర్తయ్యే బ్యాకప్ job, job నడిచిందని మాత్రమే నిర్ధారిస్తుంది; మీ data తిరిగి వస్తుందని నిర్ధారించదు. ఈ లోటును రెండు తనిఖీలు భర్తీ చేస్తాయి.

మొదటిది, restic check. ఈ తనిఖీని script ఇప్పటికే ప్రతి రాత్రి నిర్వహిస్తుంది. ఇది repository నిర్మాణాన్ని మరియు indexను ధృవీకరిస్తుంది. అందువల్ల backup hostలో జరిగిన నిశ్శబ్ద corruption, restore రోజున కాకుండా మరుసటి రాత్రే గుర్తించబడుతుంది. నెలకు ఒకసారి, లోతైన సంస్కరణను అమలు చేయండి. ఇది నిజమైన dataలో యాదృచ్ఛికంగా ఎంపిక చేసిన పదో వంతును download చేసి, cryptographic 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 యాదృచ్ఛికంగా ఎంపికవుతుంది. అందువల్ల నెలవారీ 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ను నెలకు ఒకసారి నిర్వహించండి. సంవత్సరానికి ఒకటి లేదా రెండుసార్లు పూర్తి సంస్కరణను చేయండి: తాజా snapshot మొత్తాన్ని scratch VPSపై restore చేసి, మీ application దానినుంచి నిజంగా start అవుతుందో తనిఖీ చేయండి. ఒత్తిడిలో ఇది పనిచేయాల్సిన రోజున, మీరు ఇప్పటికే పలుమార్లు నిర్వహించిన routineగా ఇది ఉండాలి.

Retention: forget plus prune

పాలసీ లేకపోతే snapshots ఎప్పటికీ పేరుకుపోతాయి. Repository పరిమాణం మాత్రమే పెరుగుతుంది. Scriptలోని forget line ప్రతి రాత్రి ఒక పాలసీని అమలు చేస్తుంది: --keep-daily 7 గత ఏడు రోజులకు రోజుకు ఒక snapshotను ఉంచుతుంది, --keep-weekly 4 నాలుగు వారాలకు వారానికి ఒక snapshotను ఉంచుతుంది, --keep-monthly 6 ఆరు నెలలకు నెలకు ఒక snapshotను ఉంచుతుంది. ఏ నియమం ద్వారా రక్షించబడని ప్రతిదీ forget చేయబడుతుంది.

forget మాత్రమే అమలు చేస్తే snapshot records తొలగిపోతాయి. Data chunks repositoryలోనే ఉంటాయి. వాటిని ఏదైనా తొలగించే వరకు అవి అలాగే ఉంటాయి. ఆ పని --prune చేస్తుంది. మిగిలిన ఏ snapshot కూడా సూచించని chunksను ఇది కనుగొని తొలగిస్తుంది. అప్పుడు మాత్రమే disk space నిజంగా తిరిగి లభిస్తుంది. Prune repositoryపై వాస్తవమైన పని చేస్తుంది. అందువల్ల పెద్ద repositoryలో కొందరు forgetను ప్రతి రాత్రి, --pruneను ప్రతి వారం అమలు చేస్తారు. సాధారణ VPS పరిమాణాల్లో ప్రతి రాత్రి అమలు చేయడం సరిపోతుంది.

Databases: ముందుగా dump, తర్వాత dumpకు backup

Restic ఫైళ్లను చదువుతున్నప్పుడు వాటి కాపీలను తయారు చేస్తుంది. Database నిరంతరం తన ఫైళ్లలోకి రాస్తుంది. రాస్తున్న మధ్యలో live database ఫైల్ కాపీ అయితే, రాయడానికి ముందు మరియు తర్వాతి పేజీలు కలిసిపోతాయి. అందువల్ల restore చేసిన database corrupt అవుతుంది. దీనికి ప్రామాణిక పరిష్కారం ఉంది: database engine ద్వారా consistent exportను ఒక ఫైల్‌గా తయారు చేయండి. తర్వాత restic ఆ ఫైల్‌కు 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 ఇదే పని చేస్తుంది. మొత్తం విధానానికి పూర్తి ఉదాహరణ కోసం Nextcloud backup విభాగం maintenance modeను ప్రారంభిస్తుంది, Postgresకు dump తీస్తుంది, తర్వాత ఫైళ్లను ఒకే consistent setగా కాపీ చేస్తుంది. ప్రతి రాత్రి restic server నుంచి బయటకు తీసుకెళ్లాల్సింది ఇదే set. SQLiteలో కూడా ఇదే విధానం ఉంటుంది, కానీ చిన్న పరిష్కారంతో: Vaultwarden guide కొన్ని సెకన్ల పాటు 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ను ఎవరూ తిరిగి పొందలేరు. కాబట్టి password యొక్క ఒక ప్రతిని serverకు దూరంగా భద్రపరచండి.

restic incremental బ్యాకప్‌లు చేస్తుందా?

ప్రతి restic snapshot పూర్తి బ్యాకప్‌లా పనిచేస్తుంది. అయితే దీనికి incremental storage మాత్రమే అవసరం. restic filesను chunksగా విభజిస్తుంది. Repositoryలో ఇప్పటికే లేని chunksను మాత్రమే upload చేస్తుంది. అందువల్ల nightly run సాధారణంగా ఆ రోజున మారిన data పరిమాణాన్నే బదిలీ చేస్తుంది. సాంప్రదాయ incremental పద్ధతులకు భిన్నంగా, replay చేయాల్సిన chain ఉండదు. ఏ snapshotనైనా నేరుగా restore చేయవచ్చు. పాత snapshotను తొలగించినా కొత్త snapshot దెబ్బతినదు.

restic బ్యాకప్ నుంచి filesను ఎలా restore చేయాలి?

Snapshot IDను కనుగొనడానికి restic snapshotsను run చేయండి. దాన్ని restore చేయడానికి restic restore <id> --target /some/empty/dirను run చేయండి. దానిలోని కొంత భాగాన్ని మాత్రమే restore చేయాలంటే --include /pathను జోడించండి. ID స్థానంలో latestను ఉపయోగించవచ్చు. Restic అసలు directory structureను target కింద మళ్లీ సృష్టిస్తుంది. కాబట్టి /etc/sshను restore చేస్తే అది /some/empty/dir/etc/sshలోకి వస్తుంది. అవసరం ఏర్పడకముందే ఈ ప్రక్రియను పరీక్షించండి. పరీక్షించని బ్యాకప్ కేవలం నిర్ధారణ లేని నమ్మకం మాత్రమే.

restic backupను ఎంత తరచుగా run చేయాలి?

Serverకు nightly కనీసం సరైన పద్ధతి. Deduplication వల్ల ఇది తక్కువ ఖర్చుతో జరుగుతుంది. ప్రతి runలో చివరి run తర్వాత మారిన chunks మాత్రమే upload అవుతాయి. వేగంగా మారే dataను, లేదా ఒక్క రోజు data కోల్పోయినా తీవ్రమైన నష్టం కలిగించే dataను, అదే timer patternతో ప్రతి కొన్ని గంటలకు run చేయవచ్చు. Frequency సులభమైన భాగం మాత్రమే. restic checkను కూడా క్రమం తప్పకుండా run చేయండి. నెలకు ఒకసారి restore drill నిర్వహించండి. Verification లేకుండా ఉండే schedule తప్పుడు భద్రతాభావాన్ని మాత్రమే ఇస్తుంది.

restic repository passwordను కోల్పోతే ఏమి జరుగుతుంది?

ఆ బ్యాకప్‌లను తిరిగి పొందలేరు. Restic encryptionకు back door లేదా reset లేదు. అందువల్ల password బ్యాకప్‌లంతే ముఖ్యమైనది. Password యొక్క ఒక ప్రతిని మీ password managerలో, అలాగే బ్యాకప్ చేయబడిన serverపై కాకుండా దీర్ఘకాలం భద్రంగా ఉండే మరొక ప్రదేశంలో ఉంచండి. మీకు ఇంకా access ఉన్నప్పుడు, అదే repository కోసం రెండవ passwordను నమోదు చేయడానికి restic key addను ఉపయోగించవచ్చు. దీంతో మీకు ఒక అదనపు password ఉంటుంది.