Restic vs BorgBackup: எது சிறந்தது? ஒப்பீடு

Restic மற்றும் BorgBackup ஒப்பீடு

Restic மற்றும் BorgBackup ஆகிய இரண்டுமே Linux server-ல் deduplicated, encrypted மற்றும் incremental backups எடுக்கும் ஒரே பணியைச் செய்கின்றன. இவற்றில் எதைத் தேர்ந்தெடுப்பது என்பது backup எங்கு சேமிக்கப்படுகிறது என்பதைப் பொறுத்தது. Restic, S3 மற்றும் பிற object storage API-களை நேரடியாக ஆதரிப்பதால், தொலைதூர முனையில் எந்த மென்பொருளையும் நிறுவ வேண்டிய அவசியமின்றி ஒரு bucket-ஐ முதன்மை இலக்காகப் பயன்படுத்தலாம். Borg-க்கு repository இருக்கும் கணினியில் borg நிரல் நிறுவப்பட்டிருக்க வேண்டும், ஏனெனில் Borg repository ஒரு filesystem அல்லது API மூலம் அல்லாமல், ஒரு process மூலம் இயங்குகிறது. உங்கள் இலக்கு object storage என்றால், Restic சிறந்த தேர்வாகும். உங்கள் கட்டுப்பாட்டில் உள்ள மற்றொரு Linux கணினியை இலக்காகக் கொண்டால், Borg-ஐப் பயன்படுத்தலாம், இது பெரும்பாலும் வேகமானது.

மற்ற அம்சங்கள் சிறிய வேறுபாடுகளைக் கொண்டவை. இரண்டுமே content defined chunking மூலம் கோப்புகளைப் பிரிப்பதால், 40 GB கோப்பகத்தில் 200 MB மாற்றம் ஏற்பட்டால், சுமார் 200 MB மட்டுமே பதிவேற்றப்படும். இரண்டுமே client பக்கத்திலேயே encryption செய்கின்றன. இரண்டுமே FUSE (filesystem in userspace) மூலம் snapshot-ஐ mount செய்து, ஒரு கோப்பை மட்டும் தனியாக எடுக்க அனுமதிக்கின்றன. ஜூலை 2026 நிலவரப்படி, restic 0.19.1 பதிப்பிலும், Borg-ன் நிலையான தொடர் 1.4.5 பதிப்பிலும் உள்ளன. Borg 2.0 பல ஆண்டுகளாக beta நிலையில் இருப்பதால், தற்போது 1.4 பதிப்பையே பயன்படுத்த வேண்டும்.

Repository மாதிரிதான் உண்மையான வேறுபாடு

ஒரு restic repository என்பது கோப்புகளின் தொகுப்பாகும்: config, keys/, snapshots/, index/, மற்றும் data/ ஆகியவை pack கோப்புகளால் நிரம்பியிருக்கும். இதை வாசிப்பதற்கு வேறு எதுவும் தேவையில்லை. இதனால்தான் restic பலவிதமான backends-ஐ ஆதரிக்கிறது. Blobs-ஐ put, get, list மற்றும் delete செய்யக்கூடிய எந்தவொரு சேமிப்பகமும் restic repository-ஐ வைத்திருக்க முடியும். இதனால்தான் ஒரே binary கோப்பு local paths, SFTP, அதன் சொந்த REST server, S3, Backblaze B2, Azure, Google Cloud Storage மற்றும் rclone அணுகக்கூடிய அனைத்தையும் ஆதரிக்கிறது.

Borg repository-யும் வட்டில் உள்ள கோப்புகள்தான், ஆனால் Borg ஒருபோதும் dumb transport மூலம் அதனுடன் தொடர்புகொள்வதில்லை. ஒரு remote repository-க்கு, Borg தொலைதூர முனையில் SSH வழியாக borg serve-ஐத் தொடங்கி, அந்த process-உடன் தனது சொந்த protocol-ல் பேசுகிறது. Server பக்கம் உண்மையான வேலைகளைச் செய்கிறது: அது 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 எப்போதும் குறியாக்கம் செய்யப்பட்டே இருக்கும். இதில் குறியாக்கம் செய்யப்படாத முறை (unencrypted mode) கிடையாது. restic init ஒரு கடவுச்சொல்லைக் கேட்கும், அதிலிருந்து scrypt மூலம் ஒரு key-ஐ உருவாக்கும், அதன் பிறகு எழுதப்படும் ஒவ்வொரு pack file-ம் குறியாக்கம் செய்யப்பட்டு அங்கீகரிக்கப்படும் (authenticated). கடவுச்சொல்லைத் தொலைத்துவிட்டால் தரவுகளை மீட்க முடியாது, ஏனெனில் வடிவமைப்பிலேயே மீட்பதற்கான வழிமுறை எதுவும் இல்லை.

Borg-ல் repository-ஐ உருவாக்கும்போதே குறியாக்கத்தைத் தேர்வு செய்யலாம், அந்தத் தேர்வு நிரந்தரமானது. borg init --encryption=repokey குறியாக்கம் செய்யப்பட்ட key-ஐ repository-க்குள்ளேயே வைத்திருக்கும், எனவே passphrase மட்டும் இருந்தால் போதும், தரவுகளை மீட்கலாம். --encryption=keyfile key-ஐ client-ல் ~/.config/borg/keys/-ல் வைத்திருக்கும், எனவே repository முழுவதையும் யாராவது திருடினாலும் அவர்களால் எதையும் செய்ய முடியாது; ஆனால் அந்த key file-ஐ நீங்கள் தனியாக backup எடுக்க வேண்டும், இல்லையெனில் archives-ஐ வாசிக்க முடியாது. ஒவ்வொரு முறையிலும் -blake2 என்ற வகை உள்ளது, இது HMAC-SHA256-க்கு பதிலாக BLAKE2b மூலம் அங்கீகரிக்கும், இது SHA acceleration இல்லாத வன்பொருள்களில் வேகமாகச் செயல்படும். --encryption=none என்ற முறையும் உள்ளது, நீங்கள் சொந்தமாக வைத்திருக்கும் குறியாக்கம் செய்யப்பட்ட வட்டில் (encrypted disk) repository இருக்கும்போது இது ஒரு சரியான தேர்வாகும்.

நடைமுறை விதி: சாதாரண server backup-க்கு repokey-blake2-ஐப் பயன்படுத்தவும், நீங்கள் முழுமையாக நம்பாத இடத்தில் repository இருக்கும்போது keyfile-ஐப் பயன்படுத்தவும், வாடகைக்கு எடுத்த கணினியில் ஒருபோதும் none-ஐப் பயன்படுத்த வேண்டாம்.

Compression மற்றும் restic-ல் அது ஏன் தாமதமாக வந்தது

Borg தொடக்கத்திலிருந்தே compression வசதியைக் கொண்டுள்ளது. இயல்பான அமைப்பான lz4, அனைத்துக்கும் பயன்படுத்தும் வகையில் போதுமான வேகத்தைக் கொண்டிருப்பதால் தேர்ந்தெடுக்கப்பட்டது. zstd ஆனது 1 முதல் 22 வரையிலான நிலைகளை ஏற்கிறது, இதன் இயல்புநிலை 3 ஆகும். zlib மற்றும் lzma ஆகியவை நேரத்தை விட சேமிப்பு இடத்திற்கு முக்கியத்துவம் அளிக்கும் சூழல்களுக்காக உள்ளன. auto ஒவ்வொரு chunk-க்கும் ஒரு heuristic-ஐ இயக்குவதால், ஏற்கனவே compressed செய்யப்பட்ட தரவு மீண்டும் அழுத்தப்படாது.

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

repository format 2 வரும் வரை restic-ல் compression வசதி இருக்கவில்லை; இதற்கு restic 0.14.0 அல்லது அதற்குப் பிந்தைய பதிப்பு தேவை. இப்போது புதிய repository-களுக்கு format 2 இயல்புநிலையாக உள்ளது. compression வசதியை --compression மூலம் auto, off அல்லது max ஆகிய மதிப்புகளில் அமைக்கலாம். பழைய format 1 repository-ஐ நீங்கள் migrate செய்யும் வரை அது compressed செய்யப்படாது. எனவே, உங்கள் restic repository 0.14-க்கு முந்தையது மற்றும் நீங்கள் அதை migrate செய்யவில்லை என்றால், text, logs மற்றும் database dumps-களுக்கு நீங்கள் முழு அளவிலான சேமிப்பு இடத்தையே செலவிடுகிறீர்கள் என்று அர்த்தம்.

தொலைநிலை இலக்குகள்: S3 மற்றும் SSH ஒப்பீடு

இங்குதான் வழக்கமாகத் தேர்வு செய்யப்படுகிறது.

Restic, S3-ஐ அணுகும்போது அதற்கு 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

Borg ஒரு தொலைநிலை repository-ஐ அணுகும்போது, அதற்கு SSH மற்றும் தொலைமுனையில் Borg நிறுவல் தேவைப்படும். மேலும், அங்குள்ள பதிப்பு (version) client-உடன் இணக்கமாக இருக்க வேண்டும். தொலைமுனை உங்கள் கட்டுப்பாட்டில் இல்லை என்றால், இது ஒரு சிரமமான காரணியாகும். அதுவே நீங்கள் ஏற்கனவே நிர்வகிக்கும் மற்றொரு server என்றால், இது எந்தச் சிக்கலையும் ஏற்படுத்தாது. மேலும், இது ransomware-க்கு எதிராக எந்தக் கருவியும் வழங்காத வலுவான பாதுகாப்பை வழங்குகிறது: append-only SSH key. இந்த key-ஐ borg serve-ஐ இயக்க கட்டாயப்படுத்தினால், client-ஆல் புதிய archives-களைச் சேர்க்க முடியுமே தவிர, ஏற்கனவே உள்ளவற்றை நீக்க முடியாது. எனவே, ஒரு machine பாதிக்கப்பட்டாலும், அதன் வரலாற்றை (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 மூலம் இதே விளைவைப் பெறலாம்; இது restic-ன் வேலை அல்ல, சேவை வழங்குநரின் (provider) பொறுப்பாகும். போக்குவரத்தையும் (transport) பாதுகாப்பாக வைத்திருக்கவும், ஏனெனில் SSH-ன் இந்த அம்சம் மற்ற எந்த login-ஐயும் போலவே கவனமாக கையாளப்பட வேண்டும்: restricted authorized_keys உள்ளீட்டுடன் key-only SSH-ஐ backup கணக்கிற்குப் பயன்படுத்தவும்.

வேகம்: ஒவ்வொரு வடிவமைப்பும் உணர்த்துவது என்ன

எந்தவொரு திட்டமும் உங்கள் தரவுகளுக்குப் பொருந்தக்கூடிய நம்பகமான அளவீட்டு முடிவுகளை (benchmark) வெளியிடுவதில்லை. எனவே, அவற்றின் செயல்பாட்டு முறையை வைத்து நீங்களே முடிவு செய்ய வேண்டும்.

Borg over SSH, தாமதமுள்ள (latency) இணைப்பிலும் வேகமாகச் செயல்படும், ஏனெனில் இதன் server பக்கம் புத்திசாலித்தனமாக வடிவமைக்கப்பட்டுள்ளது. client ஒரு கேள்வியைக் கேட்கும்போது, remote borg serve process repository index-லிருந்து அதற்குப் பதிலளிக்கும், மேலும் பரிவர்த்தனை ஒரே இடத்தில் முடிவடையும். ஒவ்வொரு சிறிய கோப்பிற்கும் network round trip தேவைப்படாது.

Restic, object storage-ல் பயன்படுத்தப்படும்போது server-side வசதி இல்லாததால், அது HTTP மூலம் பெறும் index files மற்றும் pack files-ஐக் கொண்டு தரவுகளை ஒருங்கிணைக்க வேண்டும். கோரிக்கைகளின் எண்ணிக்கையைக் கட்டுக்குள் வைக்க, அது பல சிறிய துண்டுகளை (chunks) பெரிய pack files-ஆக மாற்றி upload செய்கிறது. மேலும், இது ~/.cache/restic-ல் local cache-ஐப் பராமரிக்கிறது, இதனால் அடுத்தமுறை இயக்கும்போது முழு index-ஐயும் மீண்டும் பதிவிறக்க வேண்டியதில்லை. அந்த cache-ஐ நீக்கிவிட்டால், அடுத்த backup செயல்முறை மெதுவாகவே நடக்கும், ஏனெனில் அது மீண்டும் index-ஐ உருவாக்க வேண்டும். அதிக தாமதமுள்ள இணைப்பில், லட்சக்கணக்கான சிறிய கோப்புகளைக் கையாளும்போது, Borg-ஐ விட Restic மெதுவாகச் செயல்படுவதை உணர முடியும்.

local disk அல்லது வேகமான LAN இணைப்பில் இந்த வித்தியாசம் குறைந்துவிடும். இறுதியில், இரண்டு கருவிகளுமே மூலத் தரவுகளை எவ்வளவு வேகமாக வாசித்து hash செய்கின்றன என்பதைப் பொறுத்தே அவற்றின் வேகம் அமையும்.

பல கணினிகளைப் பூட்டுதல் மற்றும் காப்புப்பிரதி எடுத்தல்

Borg 1.4 முழு செயல்பாட்டின் போதும் repository-ல் ஒரு பிரத்யேக (exclusive) பூட்டைப் பயன்படுத்துகிறது. ஒரே நேரத்தில் இரண்டு clients ஒரு repository-ல் எழுதுவது வேலை செய்யாது: இரண்டாவது client காத்திருந்து, இறுதியில் lock timeout பிழையுடன் தோல்வியடையும். ஒரு client-க்கு ஒரு repository என்பதே பரிந்துரைக்கப்படும் முறையாகும். இதன் பொருள் deduplication ஒரு கணினியின் repository-க்குள் மட்டுமே நடக்கும்; எனவே, ஒரே மாதிரியான பத்து servers-ல் பத்து நகல்கள் சேமிக்கப்படும்.

Restic பல clients ஒரே நேரத்தில் ஒரு repository-ல் காப்புப்பிரதி எடுக்க அனுமதிக்கிறது, ஏனெனில் காப்புப்பிரதி எடுக்கும்போது ஒரு பகிரப்பட்ட (shared) பூட்டு மட்டுமே பயன்படுத்தப்படுகிறது. prune போன்ற பராமரிப்புப் பணிகள் மட்டுமே பிரத்யேக பூட்டைப் பயன்படுத்துகின்றன. ஒரே மாதிரியான பத்து servers ஒரு restic repository-ஐப் பயன்படுத்தும்போது, அவை ஒன்றுக்கொன்று deduplicate செய்துகொள்ளும்; இதனால் இரண்டாவது server-லிருந்து சேமிக்கப்படும் தரவு மிகக் குறைவாகவே இருக்கும். இதன் பாதிப்பு என்னவென்றால், ஒரு கடவுச்சொல் மற்றும் ஒரு repository-ல் அனைத்தும் இருப்பதால், கடவுச்சொல்லை இழந்தால் பத்து கணினிகளின் தரவுகளையும் இழக்க நேரிடும்.

Retention: 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 ஆவணங்களை (archives) நீக்கும், ஆனால் அது தானாகவே வட்டு இடத்தை (disk space) விடுவிக்காது. borg compact இயங்கும்போதுதான் இடம் மீண்டும் கிடைக்கும். எனவே, prune செய்துவிட்டு compact செய்யாத ஒரு cron job, ஆவணப் பட்டியலைச் சிறியதாக வைத்திருக்கும், ஆனால் repository-ன் அளவை தொடர்ந்து வளரச் செய்யும். Restic-ல், --prune இல்லாமல் forget-ஐ மட்டும் இயக்கினால், அது snapshot குறிப்புகளை மட்டுமே நீக்கும்; prune இயங்கும் வரை தரவு அங்கேயே இருக்கும்.

Prune செய்த பிறகு restic check-ஐ இயக்கவும். இது repository கட்டமைப்புகளைச் சரிபார்த்து, ஏதேனும் சேதமடைந்துள்ளதா என்பதைத் தெரிவிக்கும். தரவை மீட்டெடுக்கும்போது (restore) சிக்கலை அறிவதை விட, முன்கூட்டியே அறிவது சிறந்தது.

மீட்டெடுத்தல், இது மட்டுமே உண்மையான சோதனை

இரண்டு கருவிகளும் snapshot-ஐ mount செய்ய அனுமதிக்கின்றன, இதன் மூலம் நீங்கள் கோப்புகளை உலாவ முடியும். ஒரு கோப்பை மட்டும் விரைவாக மீட்டெடுக்க இதுவே சிறந்த வழியாகும்.

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) உள்ள கோப்புப் பாதைகள் தொடக்க slash இல்லாமல் சேமிக்கப்படுகின்றன, எனவே etc/nginx என்பது சரியானது, ஆனால் /etc/nginx எதையும் பொருத்தாது மற்றும் எதையும் பிரித்தெடுக்காது, இதற்கான காரணமும் பிழைச் செய்தியாகக் காட்டப்படாது. பிரித்தெடுத்தல் (extraction) தற்போது நீங்கள் இருக்கும் directory-ல் கோப்புகளை எழுதும், எனவே முதலில் ஒரு தற்காலிக directory-க்குச் செல்லவும், இல்லையெனில் பழைய கோப்புகள் தற்போதைய கோப்புகளை அழித்துவிடும்.

பிழையின்றி முடிவடையும் ஒரு மீட்டெடுப்பு மட்டுமே முழுமையானது என்று அர்த்தமல்ல, ஏனெனில் அதன் மேல் இயங்கும் application-க்கு முழுமையான மீட்டெடுப்பு என்றால் என்ன என்பதில் தனிப்பட்ட வரையறை இருக்கலாம்: Postgres data directory-ன் நகலில் இருந்து மீண்டும் உருவாக்கப்பட்ட ஒரு Immich server, வட்டில் உள்ள அனைத்து புகைப்படங்களையும் காட்டும், ஆனால் காலவரிசையில் (timeline) எதையும் காட்டாது. இதுவே Immich-ஐ backup மற்றும் restore செய்தல் பகுதியில் சரிசெய்ய வேண்டிய தோல்வியாகும்.

நீங்கள் எந்தக் கருவியைத் தேர்வு செய்தாலும், அட்டவணைப்படுத்துதல் என்பது வேலையின் பாதி மட்டுமே. ஒரு தற்காலிக directory-ல் மீட்டெடுப்பைச் செய்து சோதிக்கும் முறையைத் தொடர்ந்து கண்காணிக்கவும். VPS-க்கான restic backup வழிகாட்டி பகுதியில் உள்ள systemd timer-ஐப் பயன்படுத்தி முழுமையான செயல்முறையைச் செய்வது போலவே இதையும் செய்யவும்.

எந்தப் பணிக்கு எது சிறந்தது

இலக்கு object storage-ஆக இருக்கும்போது, ஒரே ஒரு binary மட்டும் போதும் என்ற சூழலில், தொலைதூர முனையில் எந்த மென்பொருளும் தேவையில்லை எனும்போது, பல கணினிகள் ஒன்றையொன்று deduplicate செய்ய வேண்டும் எனும்போது, அல்லது மீட்டெடுக்கும் நபர் நீங்களாக இருக்க வாய்ப்பில்லை எனும்போது restic-ஐத் தேர்ந்தெடுக்கவும். இது ஒரு ஒற்றை static binary மற்றும் repository-க்கான URL-ஐக் கொண்டது, செயல்பாட்டு ரீதியாக இதை மிஞ்சுவது கடினம்.

நீங்கள் கட்டுப்படுத்தும் ஒரு Linux box இலக்காக இருக்கும்போது, இணைப்பில் latency இருந்து தரவுத்தொகுப்பு லட்சக்கணக்கான சிறிய கோப்புகளைக் கொண்டிருக்கும்போது, ransomware-லிருந்து பாதுகாக்க append-only SSH key தேவைப்படும்போது, அல்லது ஒவ்வொரு பணிக்கும் ஏற்ப compression-ஐ மாற்ற விரும்பும்போது Borg-ஐத் தேர்ந்தெடுக்கவும். இது பழைய கருவி, இதன் stable series மெதுவாகவே மேம்படுத்தப்படும்; backup மென்பொருளைப் பொறுத்தவரை இது ஒரு சிறப்பம்சமே.

இரண்டுமே சரியான தேர்வுகள் தான். நீங்கள் ஒருபோதும் சோதிக்காத ஒன்றே தவறான தேர்வு. நீங்கள் ஏற்கனவே application level dumps எடுக்கிறீர்கள் என்றால், அதைத் தொடருங்கள்: database dumps-உடன் கூடிய Docker-ல் Nextcloud அமைப்பு-ல் உள்ள முறை இரண்டு கருவிகளுக்கும் பொருந்தும், ஏனெனில் தன்னிச்சையான நேரத்தில் நகலெடுக்கப்படும் ஒரு நேரடி database கோப்பு, ஒரு முழுமையான database backup ஆகாது.

FAQ

restic அல்லது BorgBackup இதில் எது வேகமானது?

Local disk அல்லது வேகமான LAN இணைப்பில் இவை இரண்டும் சமமான வேகத்தையே கொண்டிருக்கும். மூலத் தரவை வாசித்தல் (read) மற்றும் hash செய்யும் வேகமே இவற்றின் செயல்பாட்டைத் தீர்மானிக்கிறது. அதிக latency கொண்ட SSH இணைப்பில், அதிக எண்ணிக்கையிலான சிறிய கோப்புகளைக் கையாளும்போது 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 மூலம் இயக்கப்படுகிறது; அத்தகைய process எதவும் bucket-க்குள் இயங்காது. சிலர் rclone மூலம் object storage-ஐ filesystem-ஆக mount செய்து இதைச் செய்கிறார்கள். ஆனால், Borg project இதை பரிந்துரைப்பதில்லை. ஏனெனில், ஒரு transaction பாதியில் இருக்கும்போது mount துண்டிக்கப்பட்டால், repository சிதைந்துவிட (corrupt) வாய்ப்புள்ளது. உங்களுக்கு object storage தேவைப்பட்டால், restic-ஐப் பயன்படுத்தவும்.

ஒரே தரவிற்கு இரண்டு கருவிகளையும் பயன்படுத்தலாமா?

ஆம், சிலர் அவ்வாறு செய்கிறார்கள்: வேகமான local restore-க்காக Borg-ஐ ஒரு secondary server-க்கும், offsite நகலுக்காக restic-ஐ object storage-க்கும் பயன்படுத்துகிறார்கள். இவை இரண்டும் ஒன்றையொன்று சார்ந்து இருக்காது என்பதால், வாசிப்பு மற்றும் hash செய்யும் செலவை நீங்கள் இரண்டு முறை ஏற்க வேண்டியிருக்கும்; மேலும் இரண்டு கடவுச்சொற்களைப் பாதுகாப்பாக வைத்திருக்க வேண்டும். இரண்டு கருவிகளிலும் restore செய்து சோதித்த பிறகு மட்டுமே இதைச் செய்யவும்.

repository கடவுச்சொல்லை மறந்துவிட்டால் என்னவாகும்?

இரண்டு கருவிகளிலும் தரவை மீண்டும் பெற முடியாது. Restic தனது key-ஐ scrypt மூலம் கடவுச்சொல்லிலிருந்து உருவாக்குகிறது, இதைத் தவிர்க்க வழியில்லை. Borg repokey பயன்முறையில், encrypted key-ஐ repository-க்குள்ளேயே சேமிக்கிறது, எனவே passphrase மட்டும் இருந்தால் போதுமானது. keyfile பயன்முறையில், ~/.config/borg/keys/-லிருந்து key file-உம் தேவைப்படும். கடவுச்சொல்லை, backup எடுக்கப்படும் server-ல் இல்லாத ஒரு password manager-ல் சேமிக்கவும். நீங்கள் keyfile பயன்படுத்தினால், borg key export மூலம் Borg key-ஐ export செய்து வைக்கவும்.

Borg 2.0-க்காகக் காத்திருக்க வேண்டுமா?

வேண்டாம். ஜூலை 2026 நிலவரப்படி, Borg 2.0 இன்னும் beta நிலையிலேயே (2.0.0b22) உள்ளது, இதைச் சோதனைக்கு மட்டுமே பயன்படுத்த வேண்டும் என்று project குறிப்பிடுகிறது. தற்போதைய stable series 1.4 ஆகும், இது தற்போது 1.4.5 பதிப்பில் உள்ளது. இப்போதே 1.4-ல் தொடங்கவும். Borg 2, repository வடிவமைப்பை மாற்றுகிறது மற்றும் முறையான upgrade வழியையும் வழங்குகிறது, எனவே இன்று தொடங்குவதால் உங்கள் தரவு சிக்கலாகாது.