Restic of BorgBackup kiezen: welke tool is beter?

Restic versus BorgBackup, in één alinea

Restic en BorgBackup voeren in de kern dezelfde taak 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 waarvoor aan de ontvangende kant geen software vereist is. Borg vereist dat het programma borg is geïnstalleerd op de machine die de repository bevat, omdat een Borg-repository wordt beheerd 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 verschillen zijn van ondergeschikt belang. Beide tools splitsen bestanden op basis van inhoud (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 afzonderlijke bestanden kunt terugzetten. Per juli 2026 is restic bij versie 0.19.1 en de stabiele serie van Borg is 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 zou moeten implementeren.

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 zoveel backends aansturen. Elke opslaglocatie die blobs kan plaatsen, ophalen, vermelden 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 hier nooit mee via een eenvoudig transportprotocol. 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 vragen over de index. Dit is de reden waarom Borg geen S3-backend heeft en waarom het project er ook geen heeft toegevoegd. Er is immers geen proces dat binnen een bucket kan draaien.

Dat ene ontwerpkenmerk veroorzaakt het merendeel van de 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. Verliest u het wachtwoord, dan zijn de gegevens verloren, aangezien er volgens het ontwerp geen herstelpad 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 op een locatie 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 en gebruikt 3 als standaard, zlib en lzma zijn beschikbaar voor situaties waarin u meer waarde hecht aan bytes dan aan 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 bood 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.

Externe doelen: S3 versus SSH

Hier wordt doorgaans de keuze gemaakt.

Wanneer Restic verbinding maakt met S3, zijn enkel de inloggegevens in de omgeving vereist; er hoeft elders niets te draaien. Dit patroon werkt ook met een bucket die u zelf host, wat een veelvoorkomende combinatie is: draai MinIO voor een S3 API op uw eigen VPS en laat Restic hiernaar 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 verbinding maakt met een externe repository, is SSH vereist, evenals een Borg-installatie aan de andere kant. De versie daar moet compatibel zijn met de client. Dit zorgt voor frictie als u de externe server niet beheert. Als het echter een tweede server is die u al beheert, is dit geen probleem. Het biedt bovendien de sterkste bescherming tegen ransomware die beide tools bieden: een 'append-only' SSH-sleutel. Forceer de sleutel om borg serve uit te voeren; de client kan dan archieven toevoegen, maar niet verwijderen. Een gecompromitteerde machine kan zo zijn eigen geschiedenis niet wissen.

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

Restic heeft een vergelijkbare functionaliteit wanneer u de eigen REST-server draait, die een 'append-only' modus ondersteunt. Bij standaard S3 bereikt u hetzelfde effect via bucket-beleid of object lock; dit is de verantwoordelijkheid van de provider, niet van Restic. Beveilig ook het transport, aangezien de SSH-kant dezelfde zorg vereist als elke andere login: pas SSH met enkel sleutels en een beperkt authorized_keys-bestand toe op het back-upaccount.

Snelheid: wat elk ontwerp impliceert

Geen van beide projecten publiceert een benchmark die u voor uw eigen data moet vertrouwen, dus baseer uw oordeel 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-roundtrips 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 ze 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 werkt niet: de tweede wacht en faalt vervolgens met een lock timeout. Het ondersteunde patroon is één repository per client. Dit betekent ook dat deduplicatie 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, dedupliceren tegen elkaar, waardoor de tweede server en verder vaak zeer weinig opslagruimte verbruiken. De keerzijde is de omvang van de impact: één wachtwoord en één repository bevatten alles, dus het verlies van het wachtwoord betekent het verlies van alle tien.

Retentie: forget plus prune, versus prune plus compact

Beide tools scheiden het besluit "wat te bewaren" van het proces "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 (compact), resulteert in een repository die oneindig blijft groeien terwijl de lijst met archieven kort blijft. In restic verwijdert forget zonder --prune alleen de verwijzingen naar snapshots; de data blijft behouden 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 herstelactie.

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 voorloopslash, 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; verplaats u dus eerst naar een tijdelijke map, anders overschrijft u actieve bestanden met oude versies.

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

Welke tool is geschikt voor welke taak

Kies restic wanneer de bestemming object storage is, wanneer u één binary wilt zonder extra software op de doelserver, wanneer meerdere machines naar dezelfde locatie moeten dedupliceren, of wanneer iemand anders dan uzelf de restore moet uitvoeren. Het is een enkele statische binary die enkel een URL voor een repository vereist; operationeel is dit moeilijk te overtreffen.

Kies Borg wanneer de bestemming 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 afstemmen. Het is de oudere tool en de stabiele releasecyclus verloopt traag; bij back-upsoftware is dat een voordeel.

Beide zijn correcte keuzes. Het enige foute 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 geldige 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 en worden beide beperkt door de lees- en hashsnelheid van de bron. Borg wint doorgaans bij een SSH-verbinding met hoge latentie en veel kleine bestanden, omdat een borg serve-proces aan de ontvangende kant indexvragen beantwoordt zonder dat er per chunk een netwerk-round-trip 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, wat het Borg-project niet aanbeveelt, omdat een mount die halverwege een transactie wegvalt de repository kan beschadigen. Als u object storage nodig heeft, gebruik dan restic.

Kan ik beide tools op dezelfde data gebruiken?

Ja, en sommige gebruikers doen dit: Borg naar een tweede server voor een snelle lokale restore, 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 restores heeft getest.

Wat gebeurt er als ik het wachtwoord van de repository 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 de passphrase alleen volstaat voor herstel, en in keyfile-modus heeft u ook het sleutelbestand uit ~/.config/borg/keys/ nodig. Bewaar het wachtwoord in een wachtwoordmanager 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 labelt 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 levert een gedocumenteerd upgrade-pad, dus vandaag beginnen betekent niet dat u vastloopt.