Restic vs BorgBackup: ఏది ఎప్పుడు వాడాలి?

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

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

మిగతా తేడాలన్నీ తక్కువ ప్రాధాన్యం కలిగినవే. రెండూ content-defined chunking ఉపయోగించి files ను విభజిస్తాయి. అందువల్ల 200 MB మారిన 40 GB directory నుంచి దాదాపు 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, ప్రస్తుతం 1.4.5 వద్ద ఉంది. Borg 2.0 ఎన్నో సంవత్సరాలుగా beta దశలో ఉంది. ఇది ఇప్పటికీ testing కోసం మాత్రమే గుర్తించబడుతోంది. కాబట్టి ఈరోజు deploy చేయాల్సింది 1.4.

రిపాజిటరీ మోడల్‌నే అసలు తేడా

restic రిపాజిటరీ అనేది ఫైళ్లతో కూడిన ఒక directory: config, keys/, snapshots/, index/ మరియు data/. ఇందులో pack files ఉంటాయి. దీన్ని చదవడానికి మరేదీ అవసరం లేదు. అందుకే restic అనేక backends‌తో పనిచేయగలదు. blobs‌ను ఉంచడం, పొందడం, జాబితా చేయడం మరియు తొలగించడం చేయగల ఏ storage అయినా restic రిపాజిటరీని నిల్వ చేయగలదు. ఈ విధంగానే ఒకే binary local paths, SFTP, దాని స్వంత REST server, S3, Backblaze B2, Azure, Google Cloud Storage మరియు rclone చేరుకోగల ఇతర storage‌లకు మద్దతు ఇస్తుంది.

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

ఈ ఒక్క design అంశం క్రింద కనిపించే చాలా ఆచరణాత్మక తేడాలకు కారణమవుతుంది.

# 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

Encryption: వాటిలో ఒకదాన్ని ఆపవచ్చు

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

Borg repository సృష్టించే సమయంలో 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. Bytes కంటే సమయం తక్కువగా ఉండటం ముఖ్యం కాని సందర్భాల్లో zlib మరియు lzma ఉపయోగించవచ్చు. 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 కోసం ఇంకా పూర్తి పరిమాణాన్నే వినియోగిస్తున్నారు.

రిమోట్ targets: S3 వర్సెస్ SSH

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

Restic కు S3 చేరుకోవడానికి environment లో credentials అవసరం. మరెక్కడా ఇంకే సేవ నడవాల్సిన అవసరం లేదు. మీరు స్వయంగా నిర్వహించే bucket కు కూడా ఇదే విధానం పనిచేస్తుంది. ఇది సాధారణంగా ఉపయోగించే కలయిక: మీ స్వంత VPS పై మీ సొంత 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

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

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

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

వేగం: ప్రతి డిజైన్ వల్ల కలిగే ప్రభావం

మీ స్వంత డేటా కోసం నమ్మదగినదిగా ఉపయోగించగల benchmark ను ఏ ప్రాజెక్ట్ కూడా ప్రచురించలేదు. కాబట్టి యంత్రాంగాన్ని బట్టి కారణాన్ని అర్థం చేసుకోండి.

లేటెన్సీ ఉన్న లింక్‌పై Borg over SSH వేగంగా ఉంటుంది, ఎందుకంటే server side తెలివిగా పనిచేస్తుంది. client ఒక ప్రశ్న పంపుతుంది. remote borg serve process repository index నుంచి సమాధానం ఇస్తుంది. transaction ఒకే చోట commit అవుతుంది. ప్రతి చిన్న file కోసం chunk lookup లు 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 సమయంలో cache మళ్లీ నిర్మించబడే వరకు ప్రక్రియ నెమ్మదిగా ఉంటుంది. millions కొద్దీ చిన్న files ఉన్న high-latency link పై, అదే డేటాకు Borg కంటే restic నెమ్మదిగా అనిపించే పరిస్థితి ఇదే.

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

లాకింగ్ మరియు అనేక మెషీన్‌ల బ్యాకప్

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

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

Retention: forget + prune, లేదా prune + compact

రెండు tools లోనూ “ఏవి ఉంచాలి” అనే నిర్ణయాన్ని “స్థలాన్ని తిరిగి ఖాళీ చేయడం” నుంచి వేరు చేస్తారు. రెండవ దశను మీరు స్వయంగా అమలు చేయాలి.

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

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

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

పునరుద్ధరణ: నిజంగా ప్రాముఖ్యమైన ఏకైక పరీక్ష

రెండు tools snapshot ను mount చేస్తాయి, కాబట్టి మీరు దాని contents ను browse చేయవచ్చు. ఒకే 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 అవుతాయి.

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

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

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

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

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

FAQ

restic లేదా BorgBackup వేగంగా పనిచేస్తాయా?

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

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 కు ఉపయోగిస్తారు. రెండింటి మధ్య ఏదీ share కాదు. అందువల్ల read మరియు hash cost రెండుసార్లు చెల్లించాలి. అలాగే సురక్షితంగా భద్రపరచాల్సిన passwords రెండు ఉంటాయి. రెండు restores ను పరీక్షించిన తర్వాత మాత్రమే ఇలా చేయండి.

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

రెండు tools లోనూ data ను తిరిగి పొందలేరు. Restic password నుంచి scrypt ఉపయోగించి 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 ను మారుస్తుంది. అయితే documented upgrade path ను అందిస్తుంది. కాబట్టి ఈరోజు ప్రారంభించడం వల్ల తరువాత migration కు మార్గం మూసుకుపోదు.