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 மட்டுமே upload செய்யப்படும். இரண்டுமே client-ல் தரவை encrypt செய்கின்றன. இரண்டுமே 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 கோப்பும் குறியாக்கம் செய்யப்பட்டு அங்கீகரிக்கப்படும். கடவுச்சொல்லைத் தொலைத்துவிட்டால் தரவுகள் கிடைக்காது, ஏனெனில் வடிவமைப்பின்படி தரவை மீட்க எந்த வழியும் இல்லை.

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

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

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

Borg தொடக்கத்திலிருந்தே compression-ஐக் கொண்டுள்ளது. இதற்கான default மதிப்பு lz4 ஆகும்; இது அனைத்துக்கும் பயன்படுத்தும் அளவுக்கு வேகமானது என்பதால் தேர்ந்தெடுக்கப்பட்டது. zstd ஆனது 1 முதல் 22 வரையிலான நிலைகளை ஏற்றுக்கொள்கிறது, இதன் default மதிப்பு 3 ஆகும். zlib மற்றும் lzma ஆகியவை நேரத்தை விட சேமிப்பு இடத்திற்கு (bytes) முக்கியத்துவம் அளிக்கும் சூழல்களுக்காக உள்ளன. 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-வே default-ஆக உள்ளது. compression வசதியை --compression மூலம் auto, off அல்லது max ஆகிய மதிப்புகளில் அமைக்கலாம். பழைய format 1 repository-ஐ நீங்கள் migrate செய்யும் வரை அது compressed செய்யப்படாது. எனவே, உங்கள் restic repository 0.14-க்கு முந்தையதாக இருந்து, நீங்கள் அதை migrate செய்யவில்லை என்றால், text, logs மற்றும் database dumps ஆகியவற்றிற்கு நீங்கள் முழு அளவிலான சேமிப்பு இடத்தையே செலவிடுகிறீர்கள் என்று அர்த்தம்.

Remote targets: S3 மற்றும் SSH

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

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

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

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

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

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

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

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

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

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

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, archive பட்டியலைச் சிறியதாக வைத்திருக்கும், ஆனால் repository-ன் அளவை தொடர்ந்து வளரச் செய்யும். Restic-ல், --prune இல்லாமல் forget-ஐ மட்டும் இயக்கினால், அது snapshot references-ஐ மட்டுமே நீக்கும்; prune இயங்கும் வரை தரவுகள் அங்கேயே இருக்கும்.

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

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

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

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

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

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

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

இரண்டுமே சரியான தேர்வுகள் தான். நீங்கள் ஒருபோதும் சோதனை செய்யாத ஒன்றே தவறான தேர்வு. ஏற்கனவே application level dumps எடுப்பவர் என்றால், அதைத் தொடருங்கள்: database dumps-உடன் கூடிய Nextcloud on Docker அமைப்பு-ல் உள்ள முறை இரண்டு கருவிகளுக்கும் பொருந்தும், ஏனெனில் ஒரு நேரடி 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 மூலம் நிர்வகிக்கப்படுகிறது; bucket-க்குள் இத்தகைய process இயங்காது. சிலர் 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, scrypt மூலம் கடவுச்சொல்லிலிருந்து key-ஐ உருவாக்குகிறது, இதைத் தவிர்க்க வழியில்லை. Borg, repokey mode-ல் encrypted key-ஐ repository-க்குள்ளேயே சேமிக்கிறது, எனவே passphrase மட்டும் இருந்தால் போதும். keyfile mode-ல், ~/.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 format-ஐ மாற்றுகிறது மற்றும் முறையான upgrade வழிமுறைகளை வழங்குகிறது. எனவே, இன்று தொடங்குவதால் உங்கள் தரவு சிக்கலில் சிக்காது.