Restic of BorgBackup: welke back-up kiest u?

Restic versus BorgBackup in één alinea

Restic en BorgBackup voeren in de kern dezelfde taak uit: gededupliceerde, versleutelde en incrementele back-ups van een Linux-server. Het verschil dat de keuze bepaalt, is waar de back-up wordt opgeslagen. Restic ondersteunt S3 en andere API's voor objectopslag rechtstreeks. Een bucket is daardoor een volwaardig doel waarvoor aan de andere kant niets hoeft te worden geïnstalleerd. Voor Borg moet het programma borg zijn geïnstalleerd op de machine waarop de repository staat. Een Borg-repository wordt namelijk beschikbaar gesteld door een proces, niet door een bestandssysteem of een API. Als uw doel objectopslag is, is dat al voldoende om te kiezen. Als uw doel een tweede Linux-machine is die u beheert, komt Borg in aanmerking en is het vaak sneller.

Al het andere zijn kleinere verschillen. Beide programma's splitsen bestanden op met op inhoud gebaseerde chunking. Een directory van 40 GB waarin 200 MB is gewijzigd, uploadt daardoor ongeveer 200 MB. Beide programma's versleutelen gegevens op de client. Beide koppelen een snapshot met FUSE (filesystem in userspace), zodat u één bestand kunt kopiëren. In juli 2026 is restic versie 0.19.1 en is de stabiele reeks van Borg 1.4, momenteel 1.4.5. Borg 2.0 verkeert al jaren in de bèt fase en is nog steeds uitsluitend als testing gemarkeerd. Daarom moet u vandaag 1.4 implementeren.

Het repositorymodel is het werkelijke verschil

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

Een Borg-repository bestaat ook uit bestanden op schijf, maar Borg gebruikt daarvoor nooit een eenvoudig transportprotocol. Voor een externe repository start Borg via SSH borg serve aan de externe kant en gebruikt het zijn eigen protocol om met dat proces te communiceren. De serverkant voert daadwerkelijk werk uit: deze beheert de repository, past de transactie toe en beantwoordt vragen over indexen. Daarom heeft Borg geen S3-backend en heeft het project er geen toegevoegd. Er is geen proces dat in een bucket kan worden uitgevoerd.

Dat ene ontwerpfeit 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 twee kan worden uitgeschakeld

Restic is altijd versleuteld. Er is geen modus zonder versleuteling. restic init vraagt om een wachtwoord, leidt daar met scrypt een sleutel uit af en versleutelt en authenticeert elk pack-bestand dat daarna wordt geschreven. Als u het wachtwoord verliest, zijn de gegevens weg, omdat er bewust geen herstelmogelijkheid bestaat.

Borg maakt versleuteling een keuze bij het aanmaken van de repository. Die keuze is permanent. borg init --encryption=repokey bewaart de versleutelde sleutel in de repository, zodat alleen de wachtwoordzin voldoende is om te herstellen. --encryption=keyfile bewaart de sleutel op de client in ~/.config/borg/keys/. Iemand die de volledige repository steelt, heeft dan nog steeds niets. U moet daarom een afzonderlijke back-up van dat sleutelbestand maken, anders zijn uw archieven onleesbaar. Voor elke modus bestaat een -blake2-variant die met BLAKE2b in plaats van HMAC-SHA256 authenticeert. Deze is sneller op hardware zonder SHA-versnelling. --encryption=none bestaat ook. Dat is een reële keuze wanneer de repository op een versleutelde schijf staat die u zelf beheert.

De praktische regel: repokey-blake2 voor een normale serverback-up, keyfile wanneer de repository zich op een locatie bevindt die u niet volledig vertrouwt, en nooit none op een gehuurde machine.

Compressie en waarom restic dit pas later kreeg

Borg ondersteunt vanaf het begin compressie. De standaardinstelling is lz4, omdat deze snel genoeg is om altijd ingeschakeld te laten. zstd accepteert niveaus van 1 tot 22 en gebruikt standaard niveau 3. zlib en lzma zijn bedoeld voor situaties waarin bestandsgrootte belangrijker is dan verwerkingstijd. auto gebruikt per chunk een heuristiek, zodat al gecomprimeerde gegevens niet opnieuw worden gecomprimeerd.

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

Restic ondersteunde helemaal geen compressie tot repository-indeling 2, waarvoor restic 0.14.0 of nieuwer nodig is. Indeling 2 is nu de standaard voor een nieuwe repository. U stelt compressie in met --compression en de waarden auto, off of max. Een bestaande repository met indeling 1 blijft ongecomprimeerd totdat u deze migreert. Als uw restic-repository ouder is dan 0.14 en u deze nooit hebt gemigreerd, gebruikt u nog steeds de volledige opslagruimte voor tekst, logbestanden en databledumps.

Externe doelen: S3 versus SSH

Hier wordt de keuze meestal gemaakt.

Restic heeft voor toegang tot S3 alleen referenties in de omgeving nodig. Er hoeft verder nergens iets te draaien. Ditzelfde patroon werkt met een bucket die u zelf host. Dat is een veelgebruikte combinatie: voer MinIO uit 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

Voor toegang tot een externe repository heeft Borg SSH nodig, evenals een Borg-installatie aan de externe kant. De versie daar moet compatibel zijn met de client. Dat is een beperking als de externe kant niet van u is. Het vormt geen probleem als de externe kant een tweede server is die u al beheert. In dat geval krijgt u de sterkste bescherming tegen ransomware die een van beide hulpprogramma's biedt: een SSH-sleutel die alleen toevoegingen toestaat. Dwing de sleutel om borg serve uit te voeren. De client kan dan archieven toevoegen, maar niet verwijderen. Een gecompromitteerde machine kan daardoor zijn eigen historie niet wissen.

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

Restic heeft alleen een gelijkwaardige optie wanneer u de eigen REST-server uitvoert. Deze ondersteunt een modus die alleen toevoegingen toestaat. Bij gewone S3 bereikt u hetzelfde effect met een bucket policy of object lock. Dat wordt door de provider geregeld en niet door restic. Beperk ook het transport, want voor de SSH-kant is dezelfde zorgvuldigheid nodig als voor elke andere aanmelding: pas SSH met alleen sleutels en een beperkte authorized_keys-vermelding toe op het backupaccount.

Snelheid: wat elk ontwerp inhoudt

Geen van beide projecten publiceert een benchmark die u zonder meer op uw eigen gegevens kunt toepassen. Baseer uw beoordeling daarom op de werking.

Borg via SSH is snel op een verbinding met hoge latentie, omdat de serverzijde intelligent is. De client stelt een vraag. Het externe borg serve-proces beantwoordt die vraag aan de hand van de repository-index. De transactie wordt op één plaats vastgelegd. Het opzoeken van chunks leidt niet voor elk klein bestand tot een afzonderlijke netwerkreis.

Restic op objectopslag heeft geen serverzijde. Daarom moet het zijn overzicht opbouwen uit indexbestanden en packbestanden die het via HTTP ophaalt. Om het aantal aanvragen beheersbaar te houden, voegt het veel kleine chunks samen in grotere packbestanden voordat het deze uploadt. Het houdt ook een lokale cache bij in ~/.cache/restic, zodat de volgende run niet de volledige index opnieuw hoeft op te halen. Verwijdert u die cache, dan is de volgende back-up traag terwijl de cache opnieuw wordt opgebouwd. Op een verbinding met hoge latentie en miljoenen kleine bestanden is dit het scenario waarin restic trager aanvoelt dan Borg voor dezelfde gegevens.

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

Vergrendeling en back-ups van meerdere machines

Borg 1.4 vergrendelt de repository exclusief gedurende de hele bewerking. Twee clients die tegelijkertijd naar één repository schrijven, werken niet: de tweede wacht en mislukt daarna door een time-out bij de vergrendeling. Het ondersteunde patroon is één repository per client. Deduplicatie vindt daardoor alleen plaats binnen de repository van één machine. Tien vrijwel identieke servers slaan dan tien kopieën van hetzelfde basissysteem op.

Met Restic kunnen meerdere clients tegelijkertijd back-ups naar één repository maken, omdat een back-up een gedeelde vergrendeling gebruikt. Alleen onderhoudstaken zoals prune vereisen een exclusieve vergrendeling. Tien vergelijkbare servers die naar één restic-repository verwijzen, dedupliceren onderling. De tweede server en volgende servers slaan daardoor vaak zeer weinig gegevens op. Het risico is wel groter: één wachtwoord en één repository bevatten alles. Als u het wachtwoord verliest, verliest u de toegang tot alle tien back-ups.

Bewaartermijn: vergeten en opruimen versus opruimen en comprimeren

Beide tools scheiden het bepalen van wat u wilt behouden van het terugwinnen van de ruimte. Bij beide moet u de tweede stap 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 hetzelfde en het is belangrijk om die duidelijk te benoemen. In Borg verwijdert borg prune archieven, maar maakt het niet automatisch schijfruimte vrij. De ruimte komt terug wanneer borg compact wordt uitgevoerd. Een cron-taak die alleen opruimt en nooit comprimeert, laat een repository dus onbeperkt groeien terwijl de archieflijst kort blijft. In restic verwijdert forget zonder --prune alleen verwijzingen naar snapshots. De gegevens blijven behouden totdat prune wordt uitgevoerd.

Voer restic check uit na het opruimen. Hiermee controleert u de structuren van de repository en krijgt u te horen of er iets beschadigd is. Dat is veel beter dan dit pas tijdens een herstelactie te ontdekken.

Herstellen: de enige test die telt

Beide tools koppelen een snapshot, zodat u deze kunt doorzoeken. Dit is de snelste manier om één bestand terug te zetten.

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 in een archief worden opgeslagen zonder de voorloopslash. Daarom is etc/nginx correct. /etc/nginx vindt niets en extraheert niets, zonder foutmelding die uitlegt waarom. Bij het extraheren wordt ook naar de huidige werkdirectory geschreven. Ga daarom eerst naar een tijdelijke werkdirectory. Anders overschrijft u actieve bestanden met oude exemplaren.

Welke tool u ook kiest, de planning is slechts de helft van het werk. Voer volgens een planning die u daadwerkelijk controleert een herstelbewerking uit naar een tijdelijke werkdirectory. Doe dit op dezelfde manier als in de volledige handleiding de restic-back-uphandleiding voor een VPS, met een systemd-timer.

Welke keuze is geschikt voor welke taak

Kies restic als het doel object storage is, als u één binary wilt gebruiken en aan de andere kant geen software wilt installeren, als meerdere machines hun gegevens onderling moeten dedupliceren of als degene die de restore uitvoert mogelijk niet uzelf is. Het is één statische binary met een URL voor een repository. Operationeel is dat moeilijk te overtreffen.

Kies Borg als het doel een Linux-systeem is dat u beheert, als de verbinding latency heeft en de dataset uit miljoenen kleine bestanden bestaat, als u de append-only SSH-key wilt gebruiken als bescherming tegen ransomware of als u compressie per taak wilt instellen. Het is de oudere tool. De stabiele reeks ontwikkelt zich langzaam. Bij backupsoftware is dat een voordeel.

Beide zijn correcte keuzes. De verkeerde keuze is degene die u nooit test. Als u al dumps op applicatieniveau maakt, moet u die behouden. Het patroon in de Nextcloud op Docker-configuratie met databasedumps is op beide tools van toepassing, omdat een live databasebestand dat op een willekeurig moment wordt gekopieerd geen backup van een database is.

FAQ

Is restic of BorgBackup sneller?

Op een lokale schijf of een snel LAN liggen ze dicht bij elkaar. Beide worden uiteindelijk beperkt door de lees- en hashsnelheid op de bron. Borg presteert doorgaans beter via een SSH-verbinding met hoge latentie en zeer veel kleine bestanden, omdat een borg serve-proces aan de andere kant indexvragen beantwoordt zonder per chunk een afzonderlijke netwerkroundtrip. Restic presteert doorgaans beter wanneer het doel object storage is, waar Borg helemaal niet naartoe kan.

Kan BorgBackup een back-up maken naar S3 of Backblaze B2?

Niet rechtstreeks. Een Borg-repository wordt via SSH aangeboden door het borg serve-proces. In een bucket draait geen dergelijk proces. U kunt dit omzeilen door object storage met rclone als bestandssysteem te koppelen. 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 hebt.

Kan ik beide hulpprogramma's op dezelfde gegevens uitvoeren?

Ja, sommige gebruikers doen dit: Borg naar een tweede server voor snel lokaal herstel, en restic naar object storage voor de externe kopie. Ze delen niets. Daardoor betaalt u de kosten voor lezen en hashen twee keer en moet u twee wachtwoorden veilig opslaan. Doe dit alleen als u beide herstelprocedures hebt getest.

Wat gebeurt er als ik het repositorywachtwoord verlies?

De gegevens kunnen met beide hulpprogramma's niet worden hersteld. Restic leidt de sleutel met scrypt af van het wachtwoord en er is geen omweg. Borg in de repokey-modus slaat de versleutelde sleutel op in de repository, zodat alleen de passphrase nodig is voor herstel. In de keyfile-modus hebt u ook het sleutelbestand uit ~/.config/borg/keys/ nodig. Bewaar het wachtwoord in een wachtwoordmanager die niet op de server staat waarvan u een back-up maakt. Exporteer de Borg-sleutel met borg key export als u keyfile gebruikt.

Moet ik wachten op Borg 2.0?

Nee. In juli 2026 is Borg 2.0 nog steeds een bètaversie, namelijk 2.0.0b22. Het project markeert deze versie uitsluitend als geschikt voor tests. De stabiele reeks is 1.4, momenteel 1.4.5. Begin nu met 1.4. Borg 2 wijzigt de repositoryindeling en biedt een gedocumenteerd upgradepad. Als u vandaag begint, raakt u daardoor niet geblokkeerd.