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

Restic vs 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ను ఉపయోగించవచ్చు. ఇది తరచుగా వేగంగా ఉంటుంది.

మిగతా తేడాలన్నీ చిన్నవే. రెండు toolsలోనూ content-defined chunkingతో filesను విభజిస్తాయి. అందువల్ల 200 MB మాత్రమే మారిన 40 GB directory నుంచి సుమారు 200 MB upload అవుతుంది. రెండు toolsలోనూ clientపైనే encryption జరుగుతుంది. రెండు toolsలోనూ 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 కోసం మాత్రమే అని గుర్తించబడుతోంది. అందువల్ల ప్రస్తుతం deploy చేయాల్సింది 1.4.

వాస్తవ తేడా repository మోడల్‌లోనే ఉంది

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

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

ఈ ఒక్క రూపకల్పన వాస్తవ వినియోగంలోని దిగువ తేడాల్లో ఎక్కువ భాగానికి కారణమవుతుంది.

# 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 మార్గం లేదు.

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 ఉంటుంది. ఇది తగినంత వేగంగా ఉండటంతో అన్ని సందర్భాల్లో enabled గా ఉంచవచ్చు. zstd 1 నుంచి 22 వరకు levels ను అంగీకరిస్తుంది. దీని default విలువ 3. zlib మరియు lzma, సమయంకంటే bytes పరిమాణానికి ఎక్కువ ప్రాధాన్యం ఇచ్చే సందర్భాల కోసం ఉన్నాయి. auto ప్రతి chunk పై heuristic ను అమలు చేస్తుంది. అందువల్ల ఇప్పటికే compressed data ను రెండుసార్లు మరింతగా కుదించదు.

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 విలువల్లో సెట్ చేయవచ్చు. పాత format 1 repository ను migrate చేసే వరకు అది uncompressed గానే ఉంటుంది. కాబట్టి మీ restic repository 0.14 కంటే పాతదై ఉండి, మీరు దాన్ని ఎప్పుడూ migrate చేయకపోతే, text, logs మరియు database dumps కోసం ఇప్పటికీ పూర్తి పరిమాణాన్నే చెల్లిస్తున్నారు.

రిమోట్ లక్ష్యాలు: S3 మరియు SSH

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

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

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

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

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

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

ప్రతి డిజైన్ సూచించే వేగ లక్షణాలు

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

లేటెన్సీ ఉన్న linkలో Borg over SSH వేగంగా పనిచేస్తుంది. దీనికి కారణం server sideలో intelligent processing ఉండటం. client ఒక ప్రశ్న పంపుతుంది. remote borg serve process repository index నుంచి సమాధానం ఇస్తుంది. transaction ఒకే చోట commit అవుతుంది. ప్రతి చిన్న file కోసం chunk lookupలు network round tripలుగా మారవు.

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

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

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

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

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

నిల్వ వ్యవధి: forget తర్వాత prune, వర్సెస్ prune తర్వాత 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 ఆర్కైవ్‌లను తొలగిస్తుంది, కానీ స్వయంగా డిస్క్ స్థలాన్ని ఖాళీ చేయదు. borg compact అమలైనప్పుడు మాత్రమే స్థలం తిరిగి లభిస్తుంది. అందువల్ల prune చేసి compact చేయని cron job వల్ల ఆర్కైవ్‌ల జాబితా చిన్నగానే ఉన్నప్పటికీ repository నిరంతరం పెరుగుతూనే ఉంటుంది. resticలో --prune లేకుండా forget అమలు చేస్తే snapshot సూచనలు మాత్రమే తొలగుతాయి. prune అమలు చేసే వరకు డేటా అలాగే ఉంటుంది.

prune తర్వాత restic check అమలు చేయండి. ఇది repository నిర్మాణాలను ధృవీకరిస్తుంది మరియు ఏదైనా దెబ్బతిన్నదా అని తెలియజేస్తుంది. restore సమయంలో సమస్యను తెలుసుకోవడం కంటే ఇది చాలా మంచిది.

పునరుద్ధరణ మాత్రమే నిజంగా పరిగణనలోకి వచ్చే పరీక్ష

రెండు టూల్స్ snapshot‌ను mount చేస్తాయి, కాబట్టి మీరు దాన్ని browse చేయవచ్చు. ఒక ఫైల్‌ను వేగంగా తిరిగి పొందడానికి ఇదే ఉత్తమ మార్గం.

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 ఏదికీ సరిపోదు మరియు ఏదీ extract చేయదు. దీనికి కారణం చెప్పే error కూడా కనిపించదు. Extraction ప్రస్తుత working directoryలోకి కూడా రాస్తుంది. కాబట్టి ముందుగా scratch directoryకి మారండి. లేకపోతే పాత ఫైళ్లతో live files overwrite అవుతాయి.

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

ఏ పనికి ఏది మెరుగైనది

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

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

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

FAQ

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

స్థానిక డిస్క్ లేదా వేగవంతమైన LANలో రెండూ దాదాపు సమానంగా ఉంటాయి. మూల డేటాను చదివే వేగం మరియు hash చేసే వేగమే రెండింటి పనితీరును పరిమితం చేస్తాయి. చాలా చిన్న ఫైళ్లతో అధిక latency ఉన్న SSH linkపై Borg సాధారణంగా మెరుగ్గా పనిచేస్తుంది. కారణం, దూరపు వైపున ఉన్న borg serve process index ప్రశ్నలకు సమాధానం ఇస్తుంది. ప్రతి chunk కోసం network round trip అవసరం ఉండదు. లక్ష్యం 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ను ఉపయోగించండి.

ఒకే డేటాపై రెండు toolsను అమలు చేయవచ్చా?

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

Repository password పోతే ఏమి జరుగుతుంది?

రెండు toolsలోనూ డేటాను తిరిగి పొందలేరు. restic passwordతో scrypt ఉపయోగించి keyని ఉత్పత్తి చేస్తుంది. దీనిని దాటవేసే మార్గం లేదు. 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ను అందిస్తుంది. అందువల్ల ఈరోజు ప్రారంభించడం వల్ల భవిష్యత్తులో మీరు చిక్కుకుపోరు.