---
title: "Restic vs Borg i 2026: hvilken passer til din Linux-server"
description: "Restic vs Borg til en Linux-server i en lille virksomhed i 2026: backends, append-only, nøgler, prune, Borg 2 i beta og en tabel over, hvornår du vælger hvad."
source: "https://wardio.net/da/guides/restic-vs-borg/"
---

**Backup**

# 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

**Det korte svar**

Vælg efter destination. Brug restic, hvis backuppen skal til S3-kompatibelt objektlager, Backblaze B2, Azure eller Google Cloud Storage, eller hvis Windows-maskiner skal bruge samme værktøj. Brug Borg 1.4, hvis du tager backup over SSH til en vært, der kører Borg, fx BorgBase eller en Hetzner Storage Box, og vil have append-only håndhævet pr. SSH-nøgle. Begge deduplikerer, komprimerer og krypterer på klienten. Hold Borg 2 ude af produktion. I september 2026 er den stadig en beta, og udviklerne siger det selv.

## 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

| Funktion | restic | Borg 1.4 |
| --- | --- | --- |
| Stabil, september 2026 | 0.19.1 (5. juli 2026) | 1.4.5 (juli 2026); Borg 2 er stadig i beta |
| Skriver til | Lokalt, SFTP, REST-server, S3-kompatibelt lager, B2, Azure, Google Cloud Storage, Swift, rclone | Lokal sti, eller SSH til en vært, der kører Borg |
| Kryptering | Altid slået til: AES-256-CTR med Poly1305-AES | Vælges ved init og ligger fast bagefter: AES-256-CTR med HMAC-SHA256 eller BLAKE2b; der findes ukrypterede tilstande |
| Komprimering | zstd, repositoryformat 2 (0.14.0 og senere) | lz4 som standard; zstd, zlib, lzma |
| Append-only | rest-server eller rclone med --append-only; på objektlager en nøgle, der kun kan slette låsefiler | borg serve --append-only pr. SSH-nøgle |
| Frigørelse af plads | forget, derefter prune (pakker om; 5 procent ubrugt er tilladt) | prune, derefter compact (tærskel på 10 procent) |
| CPU | Alle kerner som standard | Enkelttrådet |
| Windows | Native, med VSS-snapshots | WSL eller Cygwin, eksperimentelt |
| Wrapper | resticprofile | borgmatic |

## 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](/da/guides/restic-b2-object-lock/). 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](/da/guides/resticprofile-i-produktion/#ulemper).

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](/da/guides/restic-backblaze-lager-vokser/).

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](/da/guides/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

| Din situation | Vælg | Begrundelse |
| --- | --- | --- |
| Backuppen skal til S3-kompatibelt lager, B2, Azure eller Google Cloud Storage | **restic** | Borg 1.4 har ingen backend til objektlager |
| Du har et SSH-mål til backup: BorgBase, en Hetzner Storage Box, en anden server | **Borg 1.4** | Append-only håndhæves pr. SSH-nøgle på serveren |
| Windows-maskiner skal bruge samme værktøj | **restic** | Borg på Windows er eksperimentelt |
| En databaseserver, hvor wrapperen skal tage sig af dumps | **Borg med borgmatic** | Indbyggede dump-hooks |
| Serveren må ikke kunne slette sin egen historik, og der er ingen backupserver at drive | **restic med en nøgle til objektlageret, der kun kan slette låsefiler** | Udbyderen håndhæver det; prune kører et andet sted |
| Du er fristet af Borg 2 | **Borg 1.4 til produktion** | Det siger Borg-projektet selv |
| Brugere på desktopmaskiner vil have en grafisk brugerflade | **Kopia** | Officiel GUI |

## 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](/da/guides/backup-der-kan-gendannes/), 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](https://github.com/restic/restic/releases), restic-projektet på GitHub, 0.19.1 fra 5. juli 2026
2.  [restic changelog](https://github.com/restic/restic/blob/master/CHANGELOG.md), restic-projektet, posterne for 0.19.0 og 0.19.1
3.  [Preparing a new repository](https://restic.readthedocs.io/en/stable/030_preparing_a_new_repo.html), dokumentation til restic 0.19.1
4.  [Backing up](https://restic.readthedocs.io/en/stable/040_backup.html), dokumentation til restic 0.19.1
5.  [Working with repositories](https://restic.readthedocs.io/en/stable/045_working_with_repos.html), dokumentation til restic 0.19.1
6.  [Tuning parameters](https://restic.readthedocs.io/en/stable/047_tuning_parameters.html), dokumentation til restic 0.19.1
7.  [Removing backup snapshots](https://restic.readthedocs.io/en/stable/060_forget.html), dokumentation til restic 0.19.1
8.  [Encryption](https://restic.readthedocs.io/en/stable/070_encryption.html) og [References (design and threat model)](https://restic.readthedocs.io/en/stable/100_references.html), dokumentation til restic 0.19.1
9.  [rest-server README](https://github.com/restic/rest-server), restic-projektet på GitHub
10.  [rclone serve restic](https://rclone.org/commands/rclone_serve_restic/), dokumentation til rclone
11.  [Borg releases](https://github.com/borgbackup/borg/releases), BorgBackup-projektet på GitHub, 1.4.5 og 2.0.0b24
12.  [Borg 2 README](https://github.com/borgbackup/borg/blob/master/README.rst) og [Borg 2 upgrade notes and change log](https://borgbackup.readthedocs.io/en/master/changes.html), BorgBackup-projektet
13.  [borg serve (Borg 2 development documentation)](https://borgbackup.readthedocs.io/en/master/usage/serve.html), BorgBackup-projektet
14.  [Borg documentation](https://borgbackup.readthedocs.io/en/stable/), BorgBackup 1.4.5, herunder [Quick start](https://borgbackup.readthedocs.io/en/stable/quickstart.html), [General](https://borgbackup.readthedocs.io/en/stable/usage/general.html) og [Miscellaneous help (compression)](https://borgbackup.readthedocs.io/en/stable/usage/help.html)
15.  [borg init](https://borgbackup.readthedocs.io/en/stable/usage/init.html), [borg compact](https://borgbackup.readthedocs.io/en/stable/usage/compact.html) og [borg serve](https://borgbackup.readthedocs.io/en/stable/usage/serve.html), dokumentation til BorgBackup 1.4.5
16.  [Additional notes: append-only mode and rollback](https://borgbackup.readthedocs.io/en/stable/usage/notes.html), dokumentation til BorgBackup 1.4.5
17.  [Storage Box: SSH, rsync and BorgBackup](https://docs.hetzner.com/storage/storage-box/access/access-ssh-rsync-borg/), dokumentation fra Hetzner
18.  [BorgBase](https://www.borgbase.com/), BorgBase
19.  [borgmatic documentation](https://torsion.org/borgmatic/) og [borgmatic on PyPI](https://pypi.org/project/borgmatic/), 2.1.8 fra september 2026
20.  [resticprofile](https://github.com/creativeprojects/resticprofile), creativeprojects på GitHub, 0.33.1 fra 15. april 2026
21.  [Kopia features](https://kopia.io/docs/features/), [Ransomware protection](https://kopia.io/docs/advanced/ransomware-protection/), [Repository Server](https://kopia.io/docs/repository-server/) og [releases](https://github.com/kopia/kopia/releases), Kopia-projektet
22.  [rustic README](https://github.com/rustic-rs/rustic), rustic-rs på GitHub, og [rustic-rs on crates.io](https://crates.io/crates/rustic-rs), 0.11.4 fra 18. august 2026

## Spørgsmål

### Er restic eller Borg bedst til en Linux-server?

Ingen af dem er bedre generelt. Destinationen afgør det. restic skriver direkte til S3-kompatibelt objektlager, Backblaze B2, Azure, Google Cloud Storage, SFTP eller sin egen REST-server og kører native på Windows. Borg 1.4 skriver til en lokal sti eller over SSH til en vært, der kører Borg, fx BorgBase eller en Hetzner Storage Box, hvor append-only kan håndhæves pr. SSH-nøgle. Begge deduplikerer, komprimerer og krypterer på klienten.

### Er Borg 2.0 stabil endnu?

Nej. I september 2026 er den nyeste Borg 2-udgivelse 2.0.0b24, en beta udgivet 2. september 2026, og projektets README siger, at Borg 2 ikke skal bruges til backup i produktion. Betaversionerne kan ændre repositoryformatet, uden at der er nogen opgraderingsvej mellem dem. Borg 2 kan ikke bruge Borg 1.x-repositories direkte, så du kopierer arkiverne over med borg transfer. Den aktuelle stabile udgivelse er Borg 1.4.5.

### Understøtter restic komprimering?

Ja, siden restic 0.14.0, der indførte repositoryformat version 2. Det format er standard for nye repositories og komprimerer med zstd. Flaget --compression tager off, fastest, auto, better eller max, med auto som standard; fastest og better kom med 0.19.0. Ældre repositories kan opgraderes med restic migrate upgrade\_repo\_v2. Derefter komprimerer restic nye data, mens eksisterende filindhold bliver liggende, som det er, indtil restic prune --repack-uncompressed skriver det om.

### Er restic hurtigere end Borg?

Ingen af projekterne udgiver en benchmark mod det andet, og resultater fra tredjeparter er uenige, fordi de tester forskellige data, destinationer og indstillinger. Den klare forskel er tråde. restics dokumentation siger, at restic som standard bruger alle tilgængelige CPU-kerner, mens Borg 1.x udfører sit arbejde i en enkelt tråd, og i vores testmiljø brugte en Borg-backup aldrig mere end én kernes CPU-tid. Tag tid på en første backup og en fuld gendannelse af dine egne data med hvert værktøj, før du beslutter dig.

### Hvor passer Kopia ind i restic vs Borg vs Kopia?

Kopia ligger tættere på restic end på Borg. Det skriver direkte til S3-kompatibelt lager, Backblaze B2, Azure, Google Cloud Storage, SFTP og WebDAV, og dokumentationen dækker begrænsede adgangsnøgler og S3 Object Lock som beskyttelse mod ransomware. Det leveres også med en officiel grafisk brugerflade. Maskiner, der forbinder direkte til lageret, deler én adgangskode til repositoryet, så hver af dem kan læse det hele. Kopias Repository Server giver i stedet hver bruger sit eget login og viser kun brugerens egne snapshots. Den seneste udgivelse i september 2026 er 0.23.1.

**Er du i tvivl om, hvorvidt din nuværende backup kan gendannes?**

Den gratis gennemgang ender med en skriftlig vurdering, der blandt andet fortæller, om din backup kan gendannes, uanset hvilket værktøj der skriver den. [Se priserne](/da/priser/).

[Gratis servergennemgang](/da/kontakt/)