Restic vs BorgBackup: எதை தேர்வு செய்வது?

Restic மற்றும் BorgBackup: ஒரே பத்தியில்

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

மீதமுள்ள வேறுபாடுகள் சிறியவை. இரண்டும் content-defined chunking மூலம் files-ஐப் பிரிக்கின்றன. எனவே 200 MB மாற்றம் ஏற்பட்ட 40 GB directory சுமார் 200 MB-ஐ upload செய்யும். இரண்டும் client பக்கத்திலேயே encrypt செய்கின்றன. இரண்டும் 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 என்பது கோப்புகளைக் கொண்ட ஒரு directory: config, keys/, snapshots/, index/ மற்றும் data/. இவை pack files-களால் நிரம்பியிருக்கும். அதை வாசிக்க வேறு எதுவும் தேவையில்லை. அதனால்தான் restic பல backends-களை இயக்க முடியும். blobs-களை put, get, list மற்றும் delete செய்யக்கூடிய எந்த 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 பக்கம் உண்மையான பணிகளைச் செய்கிறது: அது repository-ஐ வைத்திருக்கிறது, transaction-ஐ செயல்படுத்துகிறது, index தொடர்பான கேள்விகளுக்குப் பதிலளிக்கிறது. இதனால்தான் Borg-க்கு S3 backend இல்லை; மேலும் project அதனைச் சேர்க்கவில்லை. 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 முற்றிலும் இழக்கப்படும். காரணம், வடிவமைப்பிலேயே recovery path இல்லை.

Borg, repository உருவாக்கும்போது encryption-ஐத் தேர்வு செய்ய அனுமதிக்கிறது. இந்தத் தேர்வை பின்னர் மாற்ற முடியாது. borg init --encryption=repokey encrypted key-ஐ repository-க்குள் வைத்திருக்கும். எனவே passphrase மட்டும் இருந்தால் restore செய்யலாம். --encryption=keyfile key-ஐ client-இல் ~/.config/borg/keys/-ல் வைத்திருக்கும். எனவே ஒருவர் முழு repository-ஐத் திருடினாலும் அவரிடம் பயன்படுத்தக்கூடிய data இருக்காது. ஆனால் அந்த 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 தொடக்கத்திலிருந்தே சுருக்கத்தை ஆதரிக்கிறது. இயல்புநிலை lz4 ஆகும். எல்லாவற்றிற்கும் அதை இயக்கி வைத்திருக்க இது போதுமான வேகமானது. zstd, 1 முதல் 22 வரையிலான levels-ஐ ஏற்றுக்கொண்டு, இயல்புநிலையாக 3-ஐ பயன்படுத்துகிறது. zlib மற்றும் lzma, நேரத்தைவிட bytes முக்கியமான சூழல்களுக்காக உள்ளன. auto ஒவ்வொரு chunk-க்கும் heuristic-ஐ இயக்குகிறது. ஏற்கனவே சுருக்கப்பட்ட 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 இயல்புநிலையாக உள்ளது. --compression-ஐ auto, off அல்லது max values-ஆக அமைத்து compression-ஐ தேர்வு செய்யலாம். பழைய format 1 repository-ஐ migrate செய்யும் வரை அது சுருக்கப்படாமல் இருக்கும். ஆகவே, உங்கள் restic repository 0.14-க்கு முந்தையதாக இருந்து, அதை நீங்கள் ஒருபோதும் migrate செய்யவில்லை என்றால், text, logs மற்றும் database dumps ஆகியவற்றுக்கு இன்னும் முழு size-ஐ செலுத்துகிறீர்கள்.

Remote targets: 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, remote repository-ஐ அணுகுவதற்கு SSH மற்றும் remote server-ல் Borg installation தேவைப்படும். அங்குள்ள version, client-உடன் compatible-ஆக இருக்க வேண்டும். Remote server உங்களுடையது அல்ல என்றால் இது கூடுதல் சிக்கலை ஏற்படுத்தும். நீங்கள் ஏற்கனவே நிர்வகிக்கும் இரண்டாவது server ஆக அது இருந்தால் இந்தச் சிக்கல் இல்லை. அதற்குப் பதிலாக, இந்த இரண்டு கருவிகளில் ransomware-க்கு எதிராகக் கிடைக்கும் வலுவான கட்டுப்பாட்டை இது வழங்குகிறது: append-only SSH key. அந்த key, borg serve-ஐ இயக்குமாறு கட்டுப்படுத்துங்கள். அப்போது client-ஆல் archives-ஐச் சேர்க்க முடியும்; அவற்றை நீக்க முடியாது. எனவே breached 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 முறைகளைப் போலவே கவனமாகப் பாதுகாக்க வேண்டும்: backup account-க்கு restricted authorized_keys entry உடன் key-only SSH-ஐப் பயன்படுத்துங்கள்.

ஒவ்வொரு வடிவமைப்பும் குறிக்கும் வேகம்

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

தாமதம் உள்ள network link-இல் 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 வழியாகப் பெறும் index files மற்றும் pack files-இலிருந்து அது தன் நிலையை உருவாக்க வேண்டும். Request எண்ணிக்கையை நிர்வகிக்கக்கூடிய அளவில் வைத்திருக்க, upload செய்வதற்கு முன் பல சிறிய chunks-ஐ பெரிய pack files-ஆக இணைக்கிறது. அடுத்த run முழு index-ஐ மீண்டும் பெற வேண்டாம் என்பதற்காக ~/.cache/restic-இல் local cache-ஐ வைத்திருக்கிறது. அந்த cache-ஐ நீக்கினால், அதை மீண்டும் உருவாக்கும் நேரத்தில் அடுத்த backup மெதுவாகும். Millions of small files கொண்ட high latency link-இல், அதே தரவுக்கு Borg-ஐ விட restic மெதுவாகத் தோன்றும் நிலை இதுவாகும்.

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

பல இயந்திரங்களை lock செய்து backup எடுப்பது

Borg 1.4 முழு operation நடைபெறும் காலத்திலும் repository மீது exclusive lock எடுக்கிறது. ஒரே repository-க்கு ஒரே நேரத்தில் இரண்டு clients எழுத முடியாது: இரண்டாவது client முதலில் காத்திருந்து, பின்னர் lock timeout காரணமாக தோல்வியடையும். ஆதரிக்கப்படும் நடைமுறை, ஒவ்வொரு client-க்கும் ஒரு repository பயன்படுத்துவது. இதனால் deduplication ஒரு இயந்திரத்தின் repository-க்குள் மட்டுமே நடைபெறும். ஆகவே, ஒன்றுக்கொன்று மிகவும் ஒத்த பத்து servers ஒரே base system-ன் பத்து copies-ஐ சேமிக்கும்.

Restic ஒரே repository-க்கு பல clients ஒரே நேரத்தில் backup எடுக்க அனுமதிக்கிறது. காரணம், backup shared lock எடுக்கிறது; prune போன்ற maintenance work மட்டுமே exclusive lock எடுக்கிறது. ஒரே restic repository-ஐ பயன்படுத்தும் பத்து ஒத்த servers ஒன்றுக்கொன்று எதிராக deduplicate செய்யும். இரண்டாவது server முதல் server-க்குப் பிறகு backup எடுக்கும்போது, மிகக் குறைந்த தரவையே சேமிக்கும். இதன் ஆபத்து blast radius ஆகும்: அனைத்தையும் கொண்டிருக்கும் ஒரு password மற்றும் ஒரு repository மட்டுமே இருக்கும். ஆகவே password-ஐ இழந்தால், பத்து machines-ன் முழுத் தரவையும் இழப்பீர்கள்.

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-ஐச் சரிபார்த்து, ஏதேனும் சேதமடைந்திருந்தால் தெரிவிக்கும். Restore செய்யும் நேரத்தில் அதை முதன்முதலாக அறிதலைவிட இது மிகவும் சிறந்தது.

மீட்டெடுப்பே சரியான ஒரே சோதனை

இரண்டு tools-உம் 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 கோப்புகளை overwrite செய்யும்.

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

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

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

இலக்கு நீங்கள் கட்டுப்படுத்தும் Linux box ஆக இருந்தால், link-ல் latency இருந்து dataset-ல் millions of small files இருந்தால், ransomware-க்கு எதிரான கட்டுப்பாடாக append only SSH key வேண்டுமெனில், அல்லது ஒவ்வொரு job-க்கும் compression-ஐச் சரிசெய்ய விரும்பினால் Borg-ஐத் தேர்ந்தெடுக்கவும். இது பழைய tool ஆகும். இதன் stable series மெதுவாகவே மாறுகிறது. Backup software-ல் இது ஒரு நன்மையாகும்.

இரண்டும் சரியான தேர்வுகள். நீங்கள் ஒருபோதும் test செய்யாத தேர்வே தவறானது. நீங்கள் ஏற்கனவே application level dumps எடுக்கிறீர்கள் என்றால், அவற்றைத் தொடரவும்: database dumps கொண்ட Nextcloud on Docker setup-இல் உள்ள pattern இரு tools-க்கும் பொருந்தும். ஏனெனில் live database file-ஐ ஒரு சீரற்ற நேரத்தில் copy செய்வது database-ன் backup அல்ல.

FAQ

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

உள்ளக disk அல்லது வேகமான LAN-ல் இரண்டும் ஒரே அளவிலான வேகத்தைக் கொண்டிருக்கும். மூலத் தரவை வாசிக்கும் மற்றும் hash கணக்கிடும் வேகமே இரண்டிற்கும் பெரும்பாலும் வரம்பாக இருக்கும். மிக அதிக எண்ணிக்கையிலான சிறிய files கொண்ட தரவை அதிக latency உள்ள SSH இணைப்பில் காப்புப் பிரதி எடுக்கும்போது Borg பொதுவாக முன்னிலை பெறும். காரணம், தொலைதூரப் பக்கத்தில் இயங்கும் borg serve process, ஒவ்வொரு chunk-க்கும் network round trip தேவைப்படாமல் index கேள்விகளுக்குப் பதிலளிக்கும். Target object storage ஆக இருக்கும்போது restic பொதுவாக முன்னிலை பெறும். Borg அங்கு நேரடியாகச் செயல்படாது.

BorgBackup-ஐ S3 அல்லது Backblaze B2-க்கு காப்புப் பிரதி எடுக்கப் பயன்படுத்தலாமா?

நேரடியாகப் பயன்படுத்த முடியாது. Borg repository-ஐ SSH வழியாக borg serve process வழங்குகிறது. Bucket-க்குள் அத்தகைய process இயங்காது. சிலர் rclone மூலம் object storage-ஐ filesystem ஆக mount செய்து இதைச் சமாளிக்கின்றனர். இதை Borg project பரிந்துரைக்கவில்லை. காரணம், transaction நடுவில் mount துண்டிக்கப்பட்டால் repository சேதமடையலாம். Object storage தேவைப்பட்டால் restic-ஐப் பயன்படுத்தவும்.

ஒரே data-க்கு இரு tools-ஐயும் பயன்படுத்தலாமா?

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

repository password-ஐ இழந்தால் என்ன நடக்கும்?

இரண்டு tools-லுமே data-வை மீட்டெடுக்க முடியாது. restic, password-இலிருந்து scrypt மூலம் key-ஐ உருவாக்குகிறது. அதற்கு bypass இல்லை. Borg-ன் repokey mode-ல் encrypted key repository-க்குள் சேமிக்கப்படுகிறது. எனவே passphrase மட்டும் இருந்தால் restore செய்யலாம். keyfile mode-ல் ~/.config/borg/keys/-இலுள்ள key file-மும் தேவைப்படும். காப்புப் பிரதி எடுக்கப்படும் server-ல் சேமிக்கப்படாத password manager-ல் password-ஐ வைத்திருக்கவும். keyfile-ஐப் பயன்படுத்தினால் borg key export மூலம் Borg key-ஐ export செய்யவும்.

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

வேண்டாம். July 2026 நிலவரப்படி Borg 2.0 இன்னும் beta நிலையில் உள்ளது. அதன் பதிப்பு 2.0.0b22. Project இதை testing-க்கு மட்டும் எனக் குறிப்பிடுகிறது. Stable series 1.4 ஆகும். தற்போதைய பதிப்பு 1.4.5. இப்போது 1.4-ல் தொடங்கவும். Borg 2 repository format-ஐ மாற்றுகிறது மற்றும் ஆவணப்படுத்தப்பட்ட upgrade path-ஐ வழங்குகிறது. எனவே இன்று தொடங்குவது பின்னர் உங்களைத் தடுத்து நிறுத்தாது.