Restic vs BorgBackup: ఏది ఎంచుకోవాలి?

Restic మరియు BorgBackup: ఒక పేరాలో పోలిక

Restic మరియు BorgBackup రెండూ Linux server కోసం deduplication, encryption, incremental backups అనే ప్రాథమిక పనినే చేస్తాయి. ఏది ఎంచుకోవాలో నిర్ణయించే ప్రధాన తేడా backup ఎక్కడ నిల్వ అవుతుందనేదే. Restic స్థానికంగానే S3 మరియు ఇతర object storage APIs కు మద్దతు ఇస్తుంది. అందువల్ల దూరంలోని సిస్టమ్‌లో ఏదీ install చేయకుండా bucket ను నేరుగా target గా ఉపయోగించవచ్చు. Repository ను ఉంచే machineలో borg program install అయి ఉండాలి, ఎందుకంటే Borg repository ను filesystem లేదా API కాకుండా ఒక process అందిస్తుంది. మీ target object storage అయితే, ఎంపిక స్పష్టమే. మీ target మీ నియంత్రణలో ఉన్న రెండో Linux box అయితే, Borg అనుకూలమైన ఎంపికగా ఉంటుంది మరియు తరచుగా వేగంగా పనిచేస్తుంది.

మిగతా తేడాలన్నీ తక్కువ ప్రాధాన్యమైనవే. రెండూ content-defined chunking తో files ను విభజిస్తాయి. అందువల్ల 40 GB directory లో 200 MB మారితే దాదాపు 200 MB మాత్రమే upload అవుతుంది. రెండూ client వద్దనే encryption చేస్తాయి. రెండూ FUSE (filesystem in userspace) తో snapshot ను mount చేయడానికి అనుమతిస్తాయి. అందువల్ల ఒక file ను బయటకు copy చేసుకోవచ్చు. July 2026 నాటికి restic version 0.19.1 లో ఉంది. Borg యొక్క stable series 1.4, ప్రస్తుత version 1.4.5. Borg 2.0 అనేక సంవత్సరాలుగా beta లోనే ఉంది మరియు ఇప్పటికీ testing only గా గుర్తించబడుతోంది. కాబట్టి ప్రస్తుతం deploy చేయాల్సింది 1.4.

Repository నమూనానే అసలు తేడా

restic repository అనేది files ఉన్న ఒక directory: config, keys/, snapshots/, index/ మరియు pack files తో నిండిన data/. దాన్ని చదవడానికి మరేదీ అవసరం లేదు. అందుకే restic అనేక backends తో పనిచేయగలదు. blobs ను put, get, list, delete చేయగల ఏ storage అయినా restic repository ను ఉంచగలదు. అందువల్ల ఒకే binary local paths, SFTP, దాని స్వంత REST server, S3, Backblaze B2, Azure, Google Cloud Storage మరియు rclone చేరుకోగల ఇతర storage లకు మద్దతు ఇస్తుంది.

Borg repository కూడా disk పై files రూపంలో ఉంటుంది. కానీ Borg దానితో సాధారణ transport ద్వారా ఎప్పుడూ మాట్లాడదు. Remote repository కోసం Borg SSH ద్వారా అవతలి వైపు borg serve ను ప్రారంభించి, ఆ process తో తన స్వంత protocol ను ఉపయోగిస్తుంది. Server side నిజమైన పనిని చేస్తుంది: అది repository ను ఉంచుతుంది, transaction ను అమలు చేస్తుంది మరియు index ప్రశ్నలకు సమాధానం ఇస్తుంది. అందుకే Borg కు S3 backend లేదు. Project దాన్ని జోడించలేదు కూడా. Bucket లోపల అమలు చేయడానికి process ఏదీ ఉండదు.

ఈ ఒక్క design విషయం క్రింది practical తేడాలలో ఎక్కువ భాగానికి కారణం.

# restic: the repository is a URL, and the backend is part of it
restic -r /srv/restic-repo init
restic -r sftp:backup@198.51.100.20:/srv/restic-repo init
restic -r s3:s3.us-east-1.amazonaws.com/my-backup-bucket init

# borg: a local path, or user@host:path, with borg installed on that host
borg init --encryption=repokey-blake2 /srv/borg/vps1
borg init --encryption=repokey-blake2 backup@198.51.100.20:/srv/borg/vps1

ఎన్క్రిప్షన్: వీటిలో ఒకదాన్ని నిలిపివేయవచ్చు

Restic ఎల్లప్పుడూ encrypted గానే ఉంటుంది. Unencrypted mode అందుబాటులో లేదు. restic init password అడుగుతుంది, scrypt ద్వారా దాని నుంచి key ను రూపొందిస్తుంది. ఆ తర్వాత రాయబడే ప్రతి pack file encrypted మరియు authenticated గా ఉంటుంది. Password పోతే data ను తిరిగి పొందలేరు. Recovery path ఉద్దేశపూర్వకంగా ఏదీ లేదు.

Repository సృష్టించే సమయంలో Borg encryption ను ఒక ఎంపికగా అందిస్తుంది. ఆ ఎంపికను తరువాత మార్చలేరు. borg init --encryption=repokey encrypted key ను repository లోనే ఉంచుతుంది. అందువల్ల passphrase మాత్రమే ఉంటే restore చేయవచ్చు. --encryption=keyfile key ను client లోని ~/.config/borg/keys/ లో ఉంచుతుంది. కాబట్టి repository మొత్తాన్ని దొంగిలించిన వ్యక్తికి key లేకుండా ఏమీ ఉపయోగపడదు. అయితే మీరు ఆ key file ను విడిగా backup చేయాలి. లేకపోతే మీ archives ను చదవలేరు. ప్రతి mode కు -blake2 variant కూడా ఉంది. ఇది HMAC-SHA256 బదులుగా BLAKE2b తో authentication చేస్తుంది. SHA acceleration లేని hardware పై ఇది వేగంగా ఉంటుంది. --encryption=none కూడా అందుబాటులో ఉంది. Repository మీ స్వంత encrypted disk పై ఉన్నప్పుడు ఇది సరైన ఎంపిక.

ఆచరణాత్మక నియమం: సాధారణ server backup కోసం repokey-blake2 ఉపయోగించండి. Repository పై మీకు పూర్తిగా నమ్మకం లేని ప్రదేశంలో ఉన్నప్పుడు keyfile ఉపయోగించండి. అద్దెకు తీసుకున్న machine పై ఎప్పుడూ none ఉపయోగించవద్దు.

Compression మరియు resticలో ఇది ఆలస్యంగా రావడానికి కారణం

Borg ప్రారంభం నుంచే compression కు మద్దతు ఇస్తోంది. Default గా lz4 ఉపయోగించబడుతుంది. ఇది ప్రతి సందర్భంలోనూ enable చేసి ఉంచగలిగేంత వేగంగా ఉంటుంది. zstd 1 నుంచి 22 వరకు levels ను అంగీకరిస్తుంది. దీని default level 3. zlib మరియు lzma bytes ను తగ్గించడాన్ని సమయంకన్నా ఎక్కువగా ప్రాధాన్యమిచ్చే సందర్భాల కోసం ఉన్నాయి. auto ప్రతి chunk కు heuristic ను అమలు చేస్తుంది. అందువల్ల ఇప్పటికే compressed అయిన data మళ్లీ squeeze చేయబడదు.

borg create --compression zstd,3 --stats --progress \
  /srv/borg/vps1::'{hostname}-{now}' /etc /home /srv

Repository format 2 వచ్చే వరకు resticలో compression అసలు లేదు. దీనికి restic 0.14.0 లేదా ఆ తర్వాతి version అవసరం. ప్రస్తుతం కొత్త repositoryకి format 2 default గా ఉంటుంది. Compression ను --compression ద్వారా auto, off లేదా max values తో సెట్ చేయవచ్చు. పాత format 1 repositoryని migrate చేసే వరకు అది uncompressed గానే ఉంటుంది. కాబట్టి మీ restic repository 0.14 కంటే పాతదై ఉండి, మీరు దాన్ని ఎప్పుడూ migrate చేయకపోతే, text, logs మరియు database dumps కోసం ఇప్పటికీ పూర్తి size ను చెల్లిస్తున్నారు.

Remote targets: S3 మరియు SSH

ఇక్కడే సాధారణంగా ఎంపిక జరుగుతుంది.

S3ను చేరుకోవడానికి restic కు environment లో credentials ఉంటే సరిపోతుంది. మరెక్కడా ఇంకేదీ నడుస్తూ ఉండాల్సిన అవసరం లేదు. మీరు స్వయంగా నిర్వహించే bucket పైనా ఇదే విధానం పనిచేస్తుంది. ఇది సాధారణంగా ఉపయోగించే కలయిక: మీ స్వంత VPS పై S3 API కోసం MinIOను నడిపించి, restic ను దానికి point చేయండి.

export AWS_ACCESS_KEY_ID=...
export AWS_SECRET_ACCESS_KEY=...
export RESTIC_REPOSITORY=s3:https://objects.example.com/backups
export RESTIC_PASSWORD_FILE=/root/.restic-pass
restic init
restic backup /etc /home /srv --exclude-caches

Remote repositoryను చేరుకోవడానికి Borg కు SSHతో పాటు అవతలి వైపు Borg install కూడా అవసరం. అక్కడి version clientతో compatible గా ఉండాలి. అవతలి వ్యవస్థ మీ నియంత్రణలో లేకపోతే ఇది అదనపు ఇబ్బంది. అది మీరు ఇప్పటికే నిర్వహిస్తున్న రెండో server అయితే ఈ ఇబ్బంది ఉండదు. అంతేకాదు, ransomwareకు వ్యతిరేకంగా ఈ రెండు సాధనాల్లో లభించే బలమైన నియంత్రణను ఇది అందిస్తుంది: append only SSH key. ఆ keyని borg serve ను అమలు చేసేలా పరిమితం చేయండి. అప్పుడు client archivesను add చేయగలదు, కానీ వాటిని delete చేయలేరు. అందువల్ల compromised machine తన backup historyని తానే తొలగించలేరు.

command="borg serve --append-only --restrict-to-path /srv/borg/vps1",restrict ssh-ed25519 AAAA...

Resticలో దీనికి సమానమైన విధానం దాని స్వంత REST serverను నడిపినప్పుడే లభిస్తుంది. ఆ server append only modeకు మద్దతు ఇస్తుంది. సాధారణ S3కు వ్యతిరేకంగా ఇదే ప్రభావాన్ని bucket policy లేదా object lock ద్వారా పొందవచ్చు. ఇది provider బాధ్యత, resticది కాదు. Transportను కూడా కఠినంగా పరిమితం చేయండి. SSH login విషయంలో ఇతర loginల మాదిరిగానే జాగ్రత్త అవసరం: backup accountకు పరిమిత authorized_keys entryతో key మాత్రమే ఉపయోగించే SSH ను అమలు చేయండి.

వేగం: ప్రతి రూపకల్పన వల్ల కలిగే ప్రభావం

మీ స్వంత డేటాపై నమ్మదగిన benchmark ను ఏ ప్రాజెక్ట్ కూడా ప్రచురించదు. అందువల్ల విధానం ఆధారంగా అంచనా వేయండి.

లేటెన్సీ ఉన్న లింక్‌పై Borg over SSH వేగంగా పనిచేస్తుంది, ఎందుకంటే server side తెలివిగా పనిచేస్తుంది. Client ఒక ప్రశ్న పంపుతుంది. Remote borg serve process repository index నుంచి సమాధానం ఇస్తుంది. Transaction ఒకే చోట commit అవుతుంది. ప్రతి చిన్న file కోసం chunk lookups network round trip గా మారవు.

Object storage పై Restic కు server side ఉండదు. అందువల్ల HTTP ద్వారా fetch చేసే index files మరియు pack files ఆధారంగా తన డేటా చిత్రాన్ని నిర్మించాలి. Request count నియంత్రణలో ఉండేందుకు upload చేయడానికి ముందు అనేక చిన్న chunks ను పెద్ద pack files లోకి చేర్చి నిల్వ చేస్తుంది. తదుపరి run లో మొత్తం index ను మళ్లీ fetch చేయకుండా ~/.cache/restic లో local cache ను ఉంచుతుంది. ఆ cache ను తొలగిస్తే, దాన్ని మళ్లీ నిర్మించే సమయంలో తదుపరి backup నెమ్మదిగా ఉంటుంది. Millions of small files ఉన్న high latency link పై, అదే డేటాకు Borg తో పోలిస్తే restic నెమ్మదిగా అనిపించే పరిస్థితి ఇదే.

Local disk లేదా fast LAN పై ఈ తేడా ఎక్కువగా తగ్గిపోతుంది. చివరికి రెండు tools కూడా source ను ఎంత వేగంగా read చేసి hash చేయగలవో దానిపైనే పరిమితమవుతాయి.

లాకింగ్ మరియు అనేక యంత్రాల బ్యాకప్

Borg 1.4 మొత్తం ఆపరేషన్‌ కోసం repositoryపై exclusive lock తీసుకుంటుంది. ఒకే repositoryకి ఒకేసారి రెండు clients రాయడం సాధ్యం కాదు: రెండవ client వేచి ఉంటుంది, తరువాత lock timeoutతో విఫలమవుతుంది. ప్రతి clientకు ఒక repository ఉండటం మద్దతు ఉన్న విధానం. దీనివల్ల deduplication ఒకే యంత్రానికి చెందిన repositoryలో మాత్రమే జరుగుతుంది. కాబట్టి దాదాపు ఒకేలా ఉన్న పది servers ఒకే base systemకు చెందిన పది కాపీలను నిల్వ చేస్తాయి.

Restic ఒకే repositoryలోకి ఒకేసారి అనేక clients బ్యాకప్ చేయడానికి అనుమతిస్తుంది. కారణం, బ్యాకప్ shared lock తీసుకుంటుంది. prune వంటి maintenance పనులు మాత్రమే exclusive lock తీసుకుంటాయి. ఒకే restic repositoryని సూచించే పది సమానమైన servers పరస్పరం deduplicate అవుతాయి. రెండవ server నుంచి సాధారణంగా చాలా తక్కువ డేటా మాత్రమే నిల్వ అవుతుంది. అయితే blast radius పెరుగుతుంది: ఒక password మరియు మొత్తం డేటాను కలిగి ఉన్న ఒక repositoryపై ఆధారపడాలి. కాబట్టి password కోల్పోతే పది serversకు సంబంధించిన మొత్తం డేటా కోల్పోతారు.

Retention: forget plus prune, versus prune plus compact

రెండు సాధనాలు ఏవి ఉంచాలో నిర్ణయించడాన్ని, స్థలాన్ని తిరిగి పొందడాన్ని వేర్వేరు దశలుగా నిర్వహిస్తాయి. రెండవ దశను మీరు స్వయంగా అమలు చేయాలి.

restic forget --keep-daily 7 --keep-weekly 5 --keep-monthly 12 --prune
restic check

borg prune --list --glob-archives '{hostname}-*' \
  --keep-daily=7 --keep-weekly=4 --keep-monthly=6 /srv/borg/vps1
borg compact /srv/borg/vps1

రెండు సాధనాల్లోనూ ఒకే పొరపాటు జరుగుతుంది. దీన్ని స్పష్టంగా చెప్పాలి. Borg లో borg prune archives ను తొలగిస్తుంది. కానీ అది స్వయంగా disk space ను విడుదల చేయదు. borg compact అమలైనప్పుడు మాత్రమే స్థలం తిరిగి లభిస్తుంది. అందువల్ల prune చేసి compact చేయని cron job ఉంటే, archive list చిన్నగానే ఉన్నప్పటికీ repository నిరంతరం పెరుగుతూనే ఉంటుంది. restic లో forget ను --prune లేకుండా అమలు చేస్తే snapshot references మాత్రమే తొలగిపోతాయి. prune అమలయ్యే వరకు data అలాగే ఉంటుంది.

Pruning తర్వాత restic check ను అమలు చేయండి. ఇది repository structures ను ధృవీకరిస్తుంది. ఏదైనా దెబ్బతిన్నదా అని తెలియజేస్తుంది. Restore సమయంలో ఈ విషయం తెలిసే కంటే ఇది చాలా మెరుగైన విధానం.

పునరుద్ధరణ మాత్రమే నిజమైన పరీక్ష

రెండు tools snapshot ను mount చేస్తాయి, కాబట్టి మీరు దాని contents ను పరిశీలించవచ్చు. ఒక file ను తిరిగి పొందడానికి ఇది అత్యంత వేగవంతమైన మార్గం.

restic snapshots
restic restore latest --target /tmp/restore --include /etc/nginx
restic mount /mnt/restore

borg list /srv/borg/vps1
borg extract --list /srv/borg/vps1::vps1-2026-07-30T02:00:00 etc/nginx
borg mount /srv/borg/vps1::vps1-2026-07-30T02:00:00 /mnt/restore

borg extract లో path రూపాన్ని గమనించండి. Archive లోని paths ప్రారంభ slash లేకుండా నిల్వ చేయబడతాయి. అందువల్ల etc/nginx సరైనది. /etc/nginx ఏదికీ match కాకుండా ఏదీ extract చేయదు. దీనికి కారణం ఏమిటో తెలియజేసే error కూడా కనిపించదు. Extraction ప్రస్తుత working directory లోకి files ను రాస్తుంది. కాబట్టి ముందుగా scratch directory కి మారండి. లేకపోతే పాత files తో live files overwrite అవుతాయి.

Error లేకుండా పూర్తయ్యే restore కూడా సరైనదని నిరూపించదు. ఎందుకంటే పై స్థాయిలోని application కు complete restore అంటే ఏమిటనే దానిపై తన స్వంత నిర్వచనం ఉంటుంది. ఉదాహరణకు, Postgres data directory కాపీతో పునర్నిర్మించిన Immich server లో disk పై అన్ని photos కనిపించవచ్చు. కానీ timeline లో ఏదీ కనిపించకపోవచ్చు. ఈ సమస్యను Immich ను backup చేసి restore చేయడం పరిష్కరించాలి.

మీరు ఏ tool ఎంచుకున్నా, schedule పని మొత్తంలో సగమే. మీరు నిజంగా monitor చేసే timer ద్వారా scratch directory లోకి restore ను అమలు చేయండి. VPS కోసం restic backup guide లోని పూర్తి walkthrough కూడా systemd timer తో ఇదే విధంగా చేస్తుంది.

ఏ పని కోసం ఏది అనుకూలం

లక్ష్యం object storage అయితే, ఒకే binary కావాలనుకుంటే మరియు remote వైపు ఎలాంటి software ఉండకూడదనుకుంటే, అనేక machines పరస్పరం deduplication చేసుకోవాలనుకుంటే, లేదా restore చేసే వ్యక్తి మీరే కాకపోవచ్చని భావిస్తే restic ను ఎంచుకోండి. ఇది repository కోసం URL తీసుకునే ఒకే static binary. నిర్వహణ పరంగా దీనిని మించడం కష్టం.

లక్ష్యం మీరు నియంత్రించే Linux box అయితే, link లో latency ఉండి dataset లో millions కొద్దీ చిన్న files ఉంటే, ransomware నుంచి రక్షణ కోసం append only SSH key ను నియంత్రణగా ఉపయోగించాలనుకుంటే, లేదా ప్రతి job కు compression ను ప్రత్యేకంగా సర్దుబాటు చేయాలనుకుంటే Borg ను ఎంచుకోండి. ఇది పాత tool. దీని stable series నెమ్మదిగా మారుతుంది. Backup software లో ఇది ఒక ప్రయోజనం.

రెండూ సరైన ఎంపికలే. మీరు ఎప్పుడూ test చేయని ఎంపికే తప్పు. మీరు ఇప్పటికే application level dumps తీసుకుంటుంటే, వాటిని కొనసాగించండి: database dumps తో కూడిన Nextcloud on Docker setup లోని విధానం ఏ tool కైనా వర్తిస్తుంది. ఎందుకంటే యాదృచ్ఛిక సమయంలో copy చేసిన live database file, database యొక్క backup కాదు.

FAQ

restic లేదా BorgBackup వేగంగా ఉంటాయా?

స్థానిక disk లేదా వేగవంతమైన LANలో రెండింటి పనితీరు దాదాపు సమానంగా ఉంటుంది. Sourceలో data చదివే వేగం మరియు hash చేసే వేగమే రెండింటికీ సాధారణంగా పరిమితిగా ఉంటాయి. చాలా చిన్న files ఉన్న అధిక latency SSH linkలో Borg సాధారణంగా మెరుగ్గా ఉంటుంది. కారణం, దూరంలోని borg serve process ప్రతి chunkకు network round trip అవసరం లేకుండా index ప్రశ్నలకు సమాధానం ఇస్తుంది. Targetగా object storage ఉన్నప్పుడు restic సాధారణంగా మెరుగ్గా ఉంటుంది. Borg నేరుగా object storageకు వెళ్లలేడు.

BorgBackupను S3 లేదా Backblaze B2కు backup చేయవచ్చా?

నేరుగా చేయలేరు. Borg repositoryను SSH ద్వారా borg serve process అందిస్తుంది. Bucket లోపల అలాంటి process నడవదు. కొందరు rcloneతో object storageను filesystemగా mount చేసి ఈ పరిమితిని అధిగమించడానికి ప్రయత్నిస్తారు. అయితే Borg project దీన్ని సిఫారసు చేయదు. కారణం, transaction మధ్యలో mount connection తెగిపోతే repository దెబ్బతినవచ్చు. మీకు object storage అవసరమైతే restic ఉపయోగించండి.

ఒకే dataపై రెండు toolsను నడపవచ్చా?

అవును. కొందరు ఇలా చేస్తారు: వేగవంతమైన local restore కోసం Borgను రెండవ serverకు, offsite copy కోసం resticను object storageకు ఉపయోగిస్తారు. ఇవి ఏదీ మరొకదానితో పంచుకోవు. అందువల్ల data చదవడం మరియు hash చేయడం కోసం అయ్యే ఖర్చు రెండుసార్లు ఉంటుంది. అలాగే సురక్షితంగా నిల్వ చేయాల్సిన passwords రెండు ఉంటాయి. రెండు restore ప్రక్రియలను పరీక్షించినప్పుడే ఇలా చేయండి.

Repository password పోతే ఏమవుతుంది?

రెండు toolsలోనూ dataను తిరిగి పొందలేరు. Restic scryptతో password నుంచి keyను ఉత్పత్తి చేస్తుంది. దీనికి bypass లేదు. Borgలో repokey mode ఉపయోగించినప్పుడు encrypted key repositoryలోనే నిల్వ ఉంటుంది. అందువల్ల passphraseతోనే restore చేయవచ్చు. keyfile modeలో ~/.config/borg/keys/ నుంచి key file కూడా అవసరం. Backup చేస్తున్న serverలోనే లేని password managerలో passwordను భద్రపరచండి. keyfile ఉపయోగిస్తే borg key exportతో Borg keyను export చేయండి.

Borg 2.0 కోసం వేచి ఉండాలా?

వద్దు. July 2026 నాటికి Borg 2.0 ఇంకా beta దశలోనే ఉంది; ప్రస్తుత version 2.0.0b22. Project దీన్ని testing కోసం మాత్రమే అని పేర్కొంది. Stable series 1.4, ప్రస్తుత version 1.4.5. ఇప్పుడే 1.4తో ప్రారంభించండి. Borg 2 repository formatను మార్చుతుంది మరియు document చేసిన upgrade pathను అందిస్తుంది. అందువల్ల ఈరోజు ప్రారంభించడం వల్ల భవిష్యత్తులో migration మార్గం కోల్పోరు.