Restic vs Borg til en Linux-server i en lille virksomhed

Du vil have krypteret backup af en eller nogle få Linux-servere til et andet sted, og mange af de sammenligninger, du finder, er flere år gamle eller citerer benchmarks, der modsiger hinanden. Versioner og status nedenfor er fra september 2026.

Af David Kabel · Opdateret 2026-09-24 · 13 min læsning

Status for begge projekter i september 2026

restic 0.19.1 udkom 5. juli 2026. Repositoryformat 2, som har været standard siden 0.14.0, komprimerer med zstd, så enhver sammenligning, der siger, at restic ikke kan komprimere, er forældet. Borgs stabile linje er 1.4, i øjeblikket 1.4.5 fra juli 2026.

Borg 2 har været i beta siden august 2022. Den nyeste, 2.0.0b24, kom 2. september 2026, og projektets README siger, at den ikke skal bruges til backup i produktion, fordi en ny beta kan betyde, at du skal oprette repositories forfra. Når den udkommer, skal du planlægge efter disse ændringer:

• Repositoryformat. 1.x-repositories er ikke kompatible; borg transfer --from-borg1 kopierer arkiverne over i et nyt.
• Kommandosyntaks. borg init bliver til borg repo-create, formen repo::archive udgår til fordel for -r, og i 2.0.0b24 staves selv --keep-last til prune som --keep, så du skal omskrive dine scripts.
• Lager. Borg 2 tilføjer repositories på SFTP, rclone og S3 eller B2, hvilket lukker afstanden til restic. Over SSH bruger nye repositories rest://-URL'er, som borg serve --rest leverer. ssh:// er der stadig til at læse 1.x-repositories.
• Append-only. Borg 2 fjerner tilstanden til fordel for rettigheder på repositoryet som no-delete, sat med borg serve --rest --permissions eller BORG_REPO_PERMISSIONS.

Restic vs Borg i overblik

Destinationen afgør det meste

Borg 1.4 skriver til en lokal sti eller over SSH til en maskine, der kører borg serve. Den har ingen backend til objektlager; uden Borg i den anden ende falder dokumentationen tilbage på at montere et fjernt filsystem som sshfs. Det er fint, hvis du har et SSH-mål. BorgBase hoster Borg-repositories, og nu også restic-repositories, med en append-only-tilstand. En Hetzner Storage Box tilbyder Borg 1.1, 1.2 og 1.4 med 1.2 som standard, så angiv --remote-path=borg-1.4 for at få 1.4 i serverens ende.

restic kræver intet installeret på destinationen: objektlager, en hvilken som helst SFTP-server, sin egen REST-server eller hvad rclone nu kan nå. Efter vores mening er det den enkleste måde for en lille virksomhed at have en kopi hos en anden udbyder, i et andet fejldomæne, uden at drive en ekstra maskine.

Append-only: så en hacket server ikke kan slette sin historik

Borg håndhæver det pr. SSH-nøgle med en tvungen kommando (forced command). Nøglen på den server, der tages backup af, kører borg serve --append-only; en separat administrationsmaskine har en nøgle med fuld adgang.

# ~/.ssh/authorized_keys on the Borg server
# Key held by the backed-up server: can add archives, cannot compact them away
command="borg serve --append-only --restrict-to-repository /srv/borg/web1",restrict ssh-ed25519 AAAA... web1
# Key held by a separate admin machine: full access for prune and compact
command="borg serve --restrict-to-repository /srv/borg/web1",restrict ssh-ed25519 AAAA... admin

Faren er, at append-only i 1.x kun forbyder kompaktering. Nøglen med append-only kan stadig køre borg prune eller borg delete. Arkiverne forsvinder fra listen, men dataene bliver liggende, og du kan rulle repositoryet tilbage, så længe borg compact ikke har kørt siden. I append-only-tilstand gør compact ingenting og melder ingen fejl. Så tjek arkivlisten, før du kører compact med admin-nøglen, ellers bliver angriberens sletninger permanente.

restic er afhængig af backenden. rest-server og rclone serve restic tager begge --append-only, og restics dokumentation bemærker, at få andre backends tilbyder sådan en tilstand. På objektlager er det tilsvarende en adgangsnøgle, der kan skrive, men kun må slette restics låsefiler, med versionering på bucketen, så du kan hente overskrevne objekter tilbage. restics dokumentation anbefaler at køre forget og prune fra en separat, velbeskyttet klient.

En nøgle helt uden ret til at slette er ikke nok. I vores MinIO-test kunne restic ikke fjerne sin egen lås, så hver backup efterlod en, og admin-værtens forget, prune og check stoppede derefter med "repository is already locked" og exitkode 11. Da vi tillod s3:DeleteObject kun under locks/, var det løst, mens forget med serverens nøgle stadig fik Access Denied:

{
  "Version": "2012-10-17",
  "Statement": [
    { "Effect": "Allow", "Action": ["s3:ListBucket", "s3:GetBucketLocation"],
      "Resource": ["arn:aws:s3:::web1-backups"] },
    { "Effect": "Allow", "Action": ["s3:GetObject", "s3:PutObject"],
      "Resource": ["arn:aws:s3:::web1-backups/*"] },
    { "Effect": "Allow", "Action": ["s3:DeleteObject"],
      "Resource": ["arn:aws:s3:::web1-backups/locks/*"] }
  ]
}

Den anden udbredte opskrift, s3:DeleteObject overalt uden s3:DeleteObjectVersion på en versioneret bucket, gør sletninger til slettemarkører. På MinIO var det ikke nok at udelade retten til versioner. Nøglen fjernede stadig en version for altid, indtil vi tilføjede en eksplicit Deny for s3:DeleteObjectVersion. Test din udbyder, før du stoler på det. For Backblaze B2, se hvad B2 Object Lock beskytter med restic. Opdelingen styrer adgang og gør ingen data uforanderlige. Ulemperne, og hvordan Veeams uforanderlige repositories klarer sig til sammenligning, står i guiden om resticprofile.

En angriber, der kan tilføje snapshots, kan også tilføje falske, som fortrænger dine rigtige under en politik i stil med --keep-weekly, og den næste rutinemæssige forget sletter de gode snapshots. restics dokumentation anbefaler --keep-within til append-only-repositories.

# On the admin host only. The backed-up server's key cannot delete.
export RESTIC_REPOSITORY=s3:https://s3.example.com/web1-backups
restic forget --keep-within 90d --prune
restic check --read-data-subset=5%

Ingen af tilstandene beskytter fortroligheden. restics trusselsmodel siger, at en angriber på en append-only-vært kan opsnappe adgangskoden og dekryptere tidligere og fremtidige backups, og Borgs append-only-tilstand tillader stadig læsning.

Nøgler og adgangskoder

restic krypterer altid og gemmer hovednøglen i repositoryet, pakket ind én gang pr. adgangskode. restic key add opretter en ekstra adgangskode, som du kan opbevare offline. Mister du alle adgangskoder, er dataene væk.

Borg låser tilstanden fast ved borg init: repokey gemmer den krypterede nøgle i repositoryet, keyfile gemmer den i klientens hjemmemappe. Du skal altid bruge nøgle og adgangsfrase sammen, så eksportér nøglen med borg key export og opbevar den adskilt fra både repository og server. Bruger du keyfile-tilstand, og serveren dør, overlever backupperne, men nøglen gør ikke.

Prune, og hvad det koster

restics forget fjerner snapshots, og prune frigør plads ved at slette ubrugte pakkefiler og pakke delvist brugte om. Ompakning betyder, at restic henter pakkefilerne ned og uploader dem igen. Som standard tolererer prune 5 procent ubrugte data for at begrænse det arbejde. En backup, der starter, mens prune holder sin eksklusive lås, fejler med det samme med exitkode 11, medmindre du giver den --retry-lock, og på en versioneret bucket efterlader hver ompakning gamle versioner. Det er grunden til, at et restic-repository på Backblaze B2 bliver ved at vokse.

Siden Borg 1.2 markerer borg prune kun data som slettet, og borg compact frigør dem, som standard i segmenter, hvor der ville blive sparet mindst 10 procent. Compact kræver ingen nøgle i 1.x, så den kan køre på backupserveren.

Ydelse, uden lånte benchmarks

Ingen af projekterne udgiver en direkte sammenlignende benchmark, og tal fra tredjeparter er uenige, fordi de tester forskellige data, destinationer og indstillinger. restics dokumentation siger, at restic som standard bruger alle tilgængelige CPU-kerner. Borg 1.x udfører sit arbejde i en enkelt tråd; dokumentationen til 1.4 skriver det ikke direkte, men i vores testmiljø brugte en Borg-backup aldrig mere end én kernes CPU-tid. Borg dokumenterer til gengæld, at chunks- og files-indekserne ligger i RAM og vokser med repositoryet; restic udgiver ingen tilsvarende vejledning i dimensionering. Betyder hastigheden noget, så tag tid på en første backup og en fuld gendannelse af dine egne data med hvert værktøj.

Wrappere: borgmatic og resticprofile

Uanset værktøj, så kør det gennem en wrapper frem for en håndskrevet cron-linje. borgmatic 2.1.8 fra september 2026 har indbyggede hooks til at dumpe PostgreSQL, MySQL, MariaDB, MongoDB og SQLite, tage snapshots af ZFS, Btrfs og LVM og rapportere til Healthchecks, ntfy og andre. På en databaseserver er det det stærkeste praktiske argument for Borg.

resticprofile 0.33.1 fra april 2026 tilføjer profiler, tidsplaner med systemd eller cron, kørsler af opbevaringsregler og check, HTTP-hooks og output til Prometheus. Til databaser kører du dumpet som en kommando før backuppen eller bruger restics backup --stdin-from-command, som ikke opretter et snapshot, hvis dumpet fejler. Guiden om resticprofile i produktion gennemgår opsætningen.

Kopia og rustic, kort

Kopia 0.23.1 fra juni 2026 ligger nærmere restic. Det skriver til S3-kompatibelt lager, B2, Azure, Google Cloud Storage, SFTP og WebDAV, dokumenterer S3 Object Lock som beskyttelse mod ransomware og leveres med en officiel GUI. rustic 0.11.4 fra august 2026 er en genimplementering i Rust, der læser og skriver restics repositoryformat; dens egen README kalder restic det mere modne projekt.

Valget efter din situation

Wardios eget valg

Vi bruger restic, styret af resticprofile, på alle servere, vi driver. Backuppen går til S3-kompatibelt objektlager i et andet fejldomæne end serveren. Borg 1.4 har ingen backend til objektlager, så destinationen afgjorde valget frem for hastigheden. Med et SSH-mål ville Borg og en append-only-nøgle være et fornuftigt valg. Uanset hvad, så test en gendannelse, før du stoler på den.

Faldgruber

• Compact gennem append-only-nøglen melder succes. Med nøglen fra den server, der tages backup af, tømte borg prune og borg delete arkivlisten og sluttede med exitkode 0. borg compact sluttede derefter også med 0 og uden output, og repositoryet fyldte det samme på disken. Kun arkivlisten viser skaden, så læs den fra administrationsmaskinen før enhver compact. Indtil da fik vi alle arkiver tilbage ved at fjerne de segmentfiler, der var skrevet efter den sidste gode post i repositoryets transactions-fil.
• Klienter afviser et repository, der er rullet tilbage. Efter den tilbagerulning fejlede den næste borg create fra serveren, der tages backup af, med "Cache, or information obtained from the security directory is newer than repository" og exitkode 2. borg delete --cache-only alene løste det ikke. Det gjorde det, da vi også slettede ~/.config/borg/security/REPOID/manifest-timestamp, som Borgs noter om tilbagerulning beskriver. Planlæg det trin for hver klient af repositoryet.
• En mistet keyfile låser dig ude. I et keyfile-repository fjernede vi ~/.config/borg/keys, og så fejlede borg list med "No key file for repository ... found", selv med den rigtige adgangsfrase. borg key import af en kopi, der var lavet tidligere med borg key export, gav adgang igen med det samme. Eksportér nøglen, når du opretter repositoryet, og opbevar den et andet sted end på serveren.
• En S3-nøgle uden sletteret efterlader restics låse. Hver backup skrev "error while unlocking: ... Access Denied" og sluttede alligevel med exitkode 0. Admin-værtens forget --prune og check fejlede derefter med exitkode 11, også da låsene var flere timer gamle, indtil den kørte restic unlock; så længe de var under 30 minutter gamle, fjernede unlock ingenting. En forget-kørsel med serverens nøgle efterlod også en eksklusiv lås, der fik den næste backup til at fejle, indtil administratoren kørte restic unlock --remove-all. Tillad sletning under locks/ som vist ovenfor.
• Skriveadgang tillader stadig overskrivning. Nøglen ovenfor, der kun må slette låse, erstattede en snapshotfil med en almindelig upload, og administratorens restic check meldte "repository contains errors". Versionering på bucketen havde bevaret originalen, og da vi kopierede den version tilbage, bestod check. Hold versionering slået til på restic-buckets, og lad ikke en livscyklusregel slette gamle versioner hurtigere, end du ville opdage et angreb.
• Borg 2 afviser ssh:// til nye repositories. 2.0.0b24 stoppede med "ssh:// is no longer supported for current repositories; use rest:// instead", og borg serve --append-only er et ukendt argument. Det, der virkede, var en tvungen kommando med borg serve --rest --backend FILE:/srv/borg2/web1 --permissions no-delete og en rest://host//srv/borg2/web1-URL. Backups kørte, og borg delete blev afvist med PermissionDenied. Regn med at skulle omskrive sidens nøgleopsætning til Borg 1.x, når du går over til Borg 2.

Sådan blev det testet. Den 23. september 2026 kørte vi restic 0.19.1 i containere med Debian 13.7 (trixie) under Docker på en Ubuntu 24.04-vært, mod et lokalt repository, SFTP på OpenSSH 10.0p2, rest-server 0.14.0 med og uden --append-only, rclone v1.75.1 med serve restic og rclone-backenden, og MinIO RELEASE.2025-09-07T16-13-09Z som S3-kompatibelt lager med begrænsede nøgler. Borg 1.4.5 og 2.0.0b24, installeret med pip på Python 3.13.5, skrev til lokale repositories og over SSH gennem de tvungne kommandoer ovenfor, og Borg 2 desuden til SFTP, MinIO og rclone. Vi installerede kun borgmatic 2.1.8 for at liste dens hooks. Ikke testet: rigtige konti hos Backblaze B2, Azure, Google Cloud Storage, Swift eller AWS S3, en Hetzner Storage Box, BorgBase, Windows, sshfs, og Kopia, rustic eller resticprofile ud over deres udgivelsesoplysninger og kildekode. AWS IAM kan behandle s3:DeleteObjectVersion anderledes end MinIO. Vi offentliggør ingen hastighedstal.

Kilder

1. restic releases, restic-projektet på GitHub, 0.19.1 fra 5. juli 2026
2. restic changelog, restic-projektet, posterne for 0.19.0 og 0.19.1
3. Preparing a new repository, dokumentation til restic 0.19.1
4. Backing up, dokumentation til restic 0.19.1
5. Working with repositories, dokumentation til restic 0.19.1
6. Tuning parameters, dokumentation til restic 0.19.1
7. Removing backup snapshots, dokumentation til restic 0.19.1
8. Encryption og References (design and threat model), dokumentation til restic 0.19.1
9. rest-server README, restic-projektet på GitHub
10. rclone serve restic, dokumentation til rclone
11. Borg releases, BorgBackup-projektet på GitHub, 1.4.5 og 2.0.0b24
12. Borg 2 README og Borg 2 upgrade notes and change log, BorgBackup-projektet
13. borg serve (Borg 2 development documentation), BorgBackup-projektet
14. Borg documentation, BorgBackup 1.4.5, herunder Quick start, General og Miscellaneous help (compression)
15. borg init, borg compact og borg serve, dokumentation til BorgBackup 1.4.5
16. Additional notes: append-only mode and rollback, dokumentation til BorgBackup 1.4.5
17. Storage Box: SSH, rsync and BorgBackup, dokumentation fra Hetzner
18. BorgBase, BorgBase
19. borgmatic documentation og borgmatic on PyPI, 2.1.8 fra september 2026
20. resticprofile, creativeprojects på GitHub, 0.33.1 fra 15. april 2026
21. Kopia features, Ransomware protection, Repository Server og releases, Kopia-projektet
22. rustic README, rustic-rs på GitHub, og rustic-rs on crates.io, 0.11.4 fra 18. august 2026