Restic of BorgBackup kiezen: de verschillen uitgelegd

Restic versus BorgBackup, in één alinea

Restic en BorgBackup voeren beide dezelfde kerntaak uit: het maken van gededupliceerde, versleutelde, incrementele back-ups van een Linux-server. Het verschil dat de keuze bepaalt, is de locatie waar de back-up wordt opgeslagen. Restic ondersteunt S3 en andere object storage-API's standaard, waardoor een bucket een volwaardig doel is zonder dat er aan de ontvangende kant software geïnstalleerd hoeft te worden. Borg vereist dat het programma borg is geïnstalleerd op de machine die de repository beheert, omdat een Borg-repository wordt bediend door een proces en niet door een bestandssysteem of API. Als uw doel object storage is, dan is dat direct het antwoord. Als uw doel een tweede Linux-machine is die u zelf beheert, dan is Borg een optie en vaak sneller.

Alle overige aspecten zijn van ondergeschikt belang. Beide tools splitsen bestanden op basis van content-defined chunking, waardoor een map van 40 GB die voor 200 MB is gewijzigd, ook ongeveer 200 MB aan data uploadt. Beide versleutelen de data aan de clientzijde. Beide bieden de mogelijkheid om een snapshot te mounten via FUSE (filesystem in userspace), zodat u individuele bestanden kunt kopiëren. Per juli 2026 is restic bij versie 0.19.1 en is de stabiele serie van Borg 1.4, op versie 1.4.5. Borg 2.0 bevindt zich al jaren in bèta en wordt nog steeds als testversie aangemerkt, dus 1.4 is de versie die u vandaag de dag zou moeten inzetten.

Het repository-model is het werkelijke verschil

Een restic-repository is een map met bestanden: config, keys/, snapshots/, index/ en data/ vol met pack-bestanden. Er is niets anders nodig om deze te lezen. Daarom kan restic met zoveel backends werken. Elke opslaglocatie die blobs kan plaatsen, ophalen, weergeven en verwijderen, kan een restic-repository bevatten. Dit is hoe één binary lokale paden, SFTP, een eigen REST-server, S3, Backblaze B2, Azure, Google Cloud Storage en alles wat rclone kan bereiken, ondersteunt.

Een Borg-repository bestaat ook uit bestanden op schijf, maar Borg communiceert nooit via een eenvoudig transportprotocol met deze bestanden. Voor een externe repository start Borg borg serve aan de andere kant via SSH en spreekt het zijn eigen protocol met dat proces. De serverzijde verricht daadwerkelijk werk: het beheert de repository, voert de transactie uit en beantwoordt indexvragen. Dit is de reden waarom Borg geen S3-backend heeft en waarom het project er nog geen heeft toegevoegd. Er is immers geen proces dat binnen een bucket kan draaien.

Dat ene ontwerpkenmerk veroorzaakt de meeste praktische verschillen hieronder.

# 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

Versleuteling: een van de opties kan worden uitgeschakeld

Restic is altijd versleuteld. Er bestaat geen modus zonder versleuteling. restic init vraagt om een wachtwoord, leidt daar met scrypt een sleutel uit af, en elk pack-bestand dat daarna wordt geschreven is versleuteld en geauthenticeerd. Als u het wachtwoord verliest, zijn de gegevens verloren, aangezien er volgens het ontwerp geen herstelmethode bestaat.

Borg maakt versleuteling een keuze bij het aanmaken van de repository, en deze keuze is permanent. borg init --encryption=repokey bewaart de versleutelde sleutel in de repository, waardoor de passphrase alleen volstaat voor herstel. --encryption=keyfile bewaart de sleutel op de client in ~/.config/borg/keys/; hierdoor heeft iemand die de volledige repository steelt nog steeds niets, maar moet u dat sleutelbestand apart back-uppen, anders zijn uw archieven onleesbaar. Elke modus heeft een -blake2-variant die authenticeert met BLAKE2b in plaats van HMAC-SHA256, wat sneller is op hardware zonder SHA-versnelling. --encryption=none bestaat ook, en dit is een reële keuze wanneer de repository op een versleutelde schijf staat die uw eigendom is.

De praktische regel: repokey-blake2 voor een normale server-back-up, keyfile wanneer de repository ergens staat die u niet volledig vertrouwt, en gebruik nooit none op een gehuurde machine.

Compressie, en waarom restic dit pas laat kreeg

Borg past vanaf het begin compressie toe. De standaard is lz4, gekozen omdat deze snel genoeg is om voor alles ingeschakeld te laten. zstd accepteert niveaus 1 tot 22 met 3 als standaard, zlib en lzma zijn beschikbaar voor situaties waarin bytes belangrijker zijn dan minuten, en auto voert een heuristiek per chunk uit zodat reeds gecomprimeerde data niet dubbel wordt verwerkt.

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

Restic had helemaal geen compressie tot repository-formaat 2, waarvoor restic 0.14.0 of nieuwer vereist is. Formaat 2 is nu de standaard voor een nieuwe repository en compressie wordt ingesteld met --compression op de waarden auto, off of max. Een oude repository in formaat 1 blijft ongecomprimeerd totdat u deze migreert. Als uw restic-repository dus van vóór 0.14 dateert en u deze nooit heeft gemigreerd, betaalt u nog steeds de volledige opslagruimte voor tekst, logs en database-dumps.

Remote targets: S3 versus SSH

Hier wordt doorgaans de keuze gemaakt.

Wanneer Restic S3 benadert, zijn er enkel credentials in de omgeving nodig en hoeft er nergens anders iets te draaien. Hetzelfde patroon werkt voor een bucket die u zelf host, wat een veelvoorkomende combinatie is: draai MinIO voor een S3 API op uw eigen VPS en laat Restic daarnaar verwijzen.

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

Wanneer Borg een remote repository benadert, is SSH vereist, evenals een Borg-installatie aan de andere kant. Bovendien moet de versie daar compatibel zijn met de client. Dit zorgt voor frictie als u de andere kant niet beheert. Het is echter geen enkel probleem als de andere kant een tweede server is die u al beheert. Het biedt u de sterkste bescherming tegen ransomware die een van beide tools biedt: een append-only SSH-key. Forceer de key om borg serve uit te voeren; de client kan dan archieven toevoegen, maar niet verwijderen. Een gecompromitteerde machine kan op die manier zijn eigen geschiedenis niet wissen.

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

Restic heeft een equivalent, maar alleen wanneer u de eigen REST-server draait, die een append-only modus ondersteunt. Bij standaard S3 bereikt u hetzelfde effect via bucket-policy of object lock; dit is de taak van de provider en niet van Restic. Beveilig ook het transport, aangezien de SSH-kant van dit proces dezelfde zorg verdient als elke andere login: pas key-only SSH met een beperkte authorized_keys entry toe op het backup-account.

Snelheid: wat elk ontwerp impliceert

Geen van beide projecten publiceert een benchmark die u voor uw eigen data moet vertrouwen; baseer uw oordeel daarom op het mechanisme.

Borg over SSH is snel op een verbinding met latentie omdat de serverzijde intelligent is. De client stelt een vraag, het externe borg serve-proces beantwoordt deze vanuit de repository-index en de transactie wordt op één plek doorgevoerd. Het opzoeken van chunks resulteert niet in netwerk-round-trips voor elk klein bestand.

Restic op object storage heeft geen serverzijde, dus moet het zijn beeld opbouwen uit indexbestanden en pack-bestanden die het via HTTP ophaalt. Om het aantal verzoeken binnen de perken te houden, verpakt het veel kleine chunks in grotere pack-bestanden voordat deze worden geüpload, en houdt het een lokale cache bij in ~/.cache/restic zodat de volgende run niet de volledige index opnieuw hoeft op te halen. Verwijder die cache en de volgende back-up is traag terwijl deze opnieuw wordt opgebouwd. Op een verbinding met hoge latentie en miljoenen kleine bestanden is dit het scenario waarin restic trager aanvoelt dan Borg bij dezelfde data.

Op een lokale schijf of een snel LAN wordt het verschil grotendeels kleiner en worden beide tools uiteindelijk beperkt door de snelheid waarmee ze de bron kunnen lezen en hashen.

Vergrendeling en back-ups van meerdere machines

Borg 1.4 legt een exclusieve vergrendeling op de repository voor de gehele operatie. Twee clients die tegelijkertijd naar één repository schrijven, werken niet: de tweede client wacht en faalt vervolgens met een lock timeout. Het ondersteunde patroon is één repository per client. Dit betekent ook dat ontdubbeling alleen plaatsvindt binnen de repository van één machine, waardoor tien nagenoeg identieke servers tien kopieën van hetzelfde basissysteem opslaan.

Restic staat toe dat meerdere clients tegelijkertijd back-ups maken naar één repository, omdat een back-up een gedeelde vergrendeling gebruikt en alleen onderhoudswerkzaamheden zoals prune een exclusieve vergrendeling vereisen. Tien vergelijkbare servers die naar één restic-repository wijzen, ontdubbelen tegen elkaar, waardoor de tweede server en de daaropvolgende servers vaak zeer weinig opslagruimte innemen. De keerzijde is de impact bij verlies: één wachtwoord en één repository bevatten alles, dus het verlies van het wachtwoord betekent het verlies van alle tien de back-ups.

Retentie: forget plus prune, versus prune plus compact

Beide tools maken onderscheid tussen "bepalen wat bewaard blijft" en "ruimte vrijmaken", en bij beide moet u de tweede stap handmatig uitvoeren.

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

De valkuil is bij beide tools identiek en het is belangrijk dit duidelijk te benoemen. In Borg verwijdert borg prune archieven, maar dit maakt op zichzelf geen schijfruimte vrij. Ruimte komt pas vrij wanneer borg compact wordt uitgevoerd. Een cron job die wel opschoont (prune) maar nooit comprimeert, resulteert in een repository die blijft groeien terwijl de lijst met archieven kort blijft. In restic verwijdert forget zonder --prune alleen de verwijzingen naar snapshots; de data blijft staan totdat een prune-actie wordt uitgevoerd.

Voer restic check uit na het opschonen. Dit verifieert de structuren van de repository en geeft aan of er schade is, wat aanzienlijk beter is dan dit pas ontdekken tijdens een restore.

Herstellen, de enige test die telt

Beide tools koppelen een snapshot zodat u er doorheen kunt bladeren. Dat is de snelste manier om één bestand terug te halen.

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

Let op de padnotatie in borg extract. Paden binnen een archief worden opgeslagen zonder de voorloop-slash, dus etc/nginx is correct en /etc/nginx komt met niets overeen en extraheert niets, zonder foutmelding die aangeeft waarom. Extractie schrijft bovendien naar de huidige werkmap; ga dus eerst naar een tijdelijke map, anders overschrijft u actieve bestanden met oude versies.

Een herstelactie die zonder fouten voltooit, is nog geen bewijs, omdat de applicatie erboven een eigen definitie heeft van wat een volledig herstel is: een Immich-server die is herbouwd vanuit een kopie van de Postgres-datamap komt terug met alle foto's op schijf, maar met een tijdlijn die niets toont. Dit is precies het probleem dat Immich back-uppen en herstellen moet omzeilen.

Welke tool u ook kiest, het schema is slechts de helft van het werk. Voer een herstel uit naar een tijdelijke map volgens een timer die u daadwerkelijk controleert, op dezelfde manier als in de volledige handleiding in de restic back-upgids voor een VPS met een systemd-timer wordt gedaan.

Welke tool is geschikt voor welke taak

Kies restic wanneer het doel object storage is, wanneer u één binary wilt zonder software aan de ontvangende kant, wanneer meerdere machines naar dezelfde locatie moeten dedupliceren, of wanneer de persoon die de restore uitvoert niet uzelf bent. Het is een enkele statische binary met een URL voor een repository, en dat is operationeel gezien moeilijk te overtreffen.

Kies Borg wanneer het doel een Linux-server is die u beheert, wanneer de verbinding latentie heeft en de dataset uit miljoenen kleine bestanden bestaat, wanneer u een append-only SSH-key wilt als beveiliging tegen ransomware, of wanneer u compressie per taak wilt afstellen. Het is de oudere tool, de stabiele serie ontwikkelt zich langzaam, en bij back-upsoftware is dat een voordeel.

Beide zijn correcte keuzes. Het verkeerde antwoord is de back-up die u nooit test. Als u al dumps op applicatieniveau maakt, blijf dat dan doen: het patroon in de Nextcloud op Docker-opstelling met database-dumps is van toepassing op beide tools, omdat een live databasebestand dat op een willekeurig moment wordt gekopieerd, geen back-up van een database is.

FAQ

Zijn restic of BorgBackup sneller?

Op een lokale schijf of een snel LAN liggen de prestaties dicht bij elkaar; beide worden uiteindelijk beperkt door de lees- en hashsnelheid van de bron. Borg wint doorgaans bij een SSH-verbinding met hoge latentie en zeer veel kleine bestanden, omdat een borg serve-proces aan de ontvangende kant indexvragen beantwoordt zonder dat er per chunk een netwerk-roundtrip nodig is. Restic wint meestal wanneer het doel object storage is, waar Borg in het geheel niet mee kan werken.

Kan BorgBackup back-ups maken naar S3 of Backblaze B2?

Niet rechtstreeks. Een Borg-repository wordt bediend door het borg serve-proces via SSH, en een dergelijk proces draait niet binnen een bucket. Gebruikers omzeilen dit door object storage als bestandssysteem te mounten met rclone. Het Borg-project raadt dit echter af, omdat een mount die halverwege een transactie wegvalt de repository kan beschadigen. Gebruik restic als u object storage nodig heeft.

Kan ik beide tools op dezelfde data gebruiken?

Ja, en sommige gebruikers doen dit: Borg naar een tweede server voor een snelle lokale restore, en restic naar object storage voor de offsite-kopie. Ze delen niets, dus u betaalt de lees- en hashkosten dubbel en u moet twee wachtwoorden veilig bewaren. Doe dit alleen als u beide restore-procedures heeft getest.

Wat gebeurt er als ik het repository-wachtwoord verlies?

De data is bij beide tools onherstelbaar. Restic leidt de sleutel af van het wachtwoord met scrypt en er is geen omweg mogelijk. Borg in repokey-modus slaat de versleutelde sleutel op in de repository, waardoor alleen de passphrase nodig is voor herstel. In keyfile-modus heeft u ook het sleutelbestand uit ~/.config/borg/keys/ nodig. Bewaar het wachtwoord in een wachtwoordbeheerder die niet op de server staat waarvan een back-up wordt gemaakt, en exporteer de Borg-sleutel met borg key export als u keyfile gebruikt.

Moet ik wachten op Borg 2.0?

Nee. Sinds juli 2026 is Borg 2.0 nog steeds bèta, op versie 2.0.0b22, en het project bestempelt dit uitsluitend als testversie. De stabiele serie is 1.4, momenteel 1.4.5. Begin nu met 1.4. Borg 2 wijzigt het repository-formaat en bevat een gedocumenteerd upgradepad, dus vandaag beginnen levert geen problemen op voor de toekomst.