restic, Borg eller Kopia för att säkerhetskopiera servern till en annan plats

Det korta svaret

Välj restic om du vill ha det säkra valet: den var snabbast eller nästan snabbast i varje test, återställer fort, finns i Debian, och med dess REST-server i läget append-only kan en hackad server inte radera sina egna säkerhetskopior. Det är upplägget i vår restic-guide. Välj Borg om du sparar dina kopior på en server eller lagringstjänst som du når över SSH och värdesätter ett långt facit: den lagrade samma data på samma utrymme, men tog dubbelt så lång tid per säkerhetskopia på våra två kärnor, och kan inte skriva till S3 förrän Borg 2 är klar. Välj Kopia om du vill ha ett grafiskt gränssnitt, gallring och schema inbyggt i ett och samma kommando, eller objektlås på S3-lagring, och kan leva med mer minne, en större cache och mycket långsammare återställningar i vårt test.

Alla tre deduplicerar, komprimerar och krypterar på servern du säkerhetskopierar, så det ställe som lagrar dina kopior ser aldrig dina filer. Skillnaderna ligger i hastighet, i hur de skyddar gamla kopior och i hur mycket du själv måste sätta upp.

Det här testade vi

Vi installerade alla tre på en VC-P Alloy (2 vCPU, 8 GB) hos Melonslab med Debian 13:

• restic 0.18.0 och rest-server 0.13.0 från Debian, enligt vår restic-guide, med REST-servern i läget append-only, ett certifikat och ett lösenord per server.
• Borg (BorgBackup) 1.4.0 från Debian, med apt install borgbackup.
• Kopia 0.23.1 från Kopias eget apt-förråd, som det beskrivs i dess installationsdokumentation. Kopia finns inte i Debian.

Varje verktyg säkerhetskopierade samma mapp, 3,46 GB i 86 623 filer: källkoden till Linux 6.12 (86 600 små filer, 1,6 GB), tre filer på 400 MB med slumpdata i stället för videor eller foton, en logg från en webbserver på 300 MB och en pg_dump på 390 MB av en PostgreSQL-databas. Sedan ändrade vi ungefär 5 % av det: en ny fil på 100 MB, 15 MB mer logg, 3 000 ändrade källkodsfiler, en raderad mapp och 3 000 nya små filer, sammanlagt 175 MB ny data. Därefter körde vi en timmes skrivningar mot databasen, dumpade den igen och säkerhetskopierade en gång till.

Kopiorna gick till två sorters lagring:

• Över SSH, till en andra användare på samma server med en SSH-nyckel, som du skulle göra med en backupserver eller en lagringstjänst: SFTP för restic och Kopia, och borg serve för Borg. restic sparade också till sin REST-server.
• S3, till Garage på samma server, genom Caddy med HTTPS. Borg 1.4 kan inte skriva till S3, så här testade vi bara restic och Kopia.

Eftersom lagringen fanns på samma server spelade nätverket ingen roll: tiderna visar vad varje verktyg gör med två CPU-kärnor och en SSD. Före varje körning tömde vi sidcachen, så att varje verktyg läste filerna från disken, som vid en säkerhetskopiering på natten. Vi använde zstd-komprimering på nivå 3 i alla tre, så att storlekarna jämför samma sak, och mätte även Borgs standard, lz4, en gång. Varje fullständig återställning jämfördes fil för fil mot kontrollsummor av originalen, och alla stämde.

Siffrorna

Över SSH, det upplägg de flesta kommer att använda:

Där det står två siffror körde vi testet två gånger, den andra i ett nytt repo. Den andra säkerhetskopians 175 MB tog ungefär 141 MB i både restic och Borg efter komprimering. Den nya databasdumpen skilde sig lite från den gamla, och tog 5 MiB i restic och 4,5 MB i Borg.

Till S3-lagring och till restics REST-server:

Installationen tog några sekunder för var och en: apt install för restic och Borg, och för Kopia först dess signeringsnyckel och förråd. Stegen i restic-guiden, med REST-servern och dess certifikat, tog 13 sekunder att köra.

Installation

restic är ett enda program och finns i Debian. Den kan använda SFTP, S3 och S3-kompatibel lagring, Backblaze B2, Azure, Google Cloud Storage, sin egen REST-server och allt som rclone når. Du pekar ut ett repo med en adress och en lösenordsfil, och restic init skapar det. Debian 13 har 0.18.0, medan den senaste versionen är 0.19.1 från juli 2026: det som står i restic-guiden fungerar med Debians version.

Borg finns också i Debian, skrivet i Python med de tunga delarna i C. Över SSH behöver Borg vara installerat även på backupservern, eftersom klienten pratar med borg serve i andra änden, inte med vanlig SFTP. Det är också det som gör läget append-only möjligt. Lagringstjänster för säkerhetskopior har ofta stöd för Borg av just det skälet. Borg 1.4 når bara lokala mappar och SSH: inte S3. Borg 2, som lägger till SFTP, S3, B2 och rclone, har varit i betaversion länge, 2.0.0b25 i september 2026, och använder ett nytt format för repot som Borg 1 inte kan läsa.

Kopia är ett enda program, plus en valfri skrivbordsapp, KopiaUI, och ett webbgränssnitt i serverläget. Den når samma sorters lagring som restic, utom REST-servern. Den finns inte i Debian: du lägger till Kopias apt-förråd eller laddar ner en version från GitHub. Ett nytt repo komprimerar ingenting förrän du ställer in en policy, så kör kopia policy set --global --compression=zstd. Det har också en gallringspolicy påslagen från början, som raderar snapshots av sig själv (se nedan). Kopias kommandorad frågar GitHub en gång om dagen efter en nyare version, om du inte sätter KOPIA_CHECK_FOR_UPDATES=false. restic och Borg öppnade inga egna anslutningar.

Hastighet och minne

Borg 1.4 delar upp, komprimerar och krypterar i en enda tråd: under sin första säkerhetskopia använde den i snitt 65 % av en kärna, medan restic använde 133 %. På vår server med två kärnor gjorde det Borg långsammast på att säkerhetskopiera, ungefär dubbelt så lång tid som de andra två, både första gången och efter ändringen. Även utan ändringar tog Borg 47 sekunder, mot 8 till 14 för de andra: den mesta tiden gick åt i dess egen kod, till att läsa in cachen och skriva listan över 88 000 filer. Med Borgs standardkomprimering lz4 i stället för zstd tog första säkerhetskopian 4 minuter 18 sekunder, och repot blev 1 886 MiB i stället för 1 664.

Kopia var snabbast med den nya databasdumpen, 14 sekunder mot 38 för restic, och långsammast på att återställa. En fullständig återställning tog 5 minuter 15 sekunder över SFTP, tre gånger så lång tid som restic, och 14 minuter från Garage. Kopia hämtar varje lagrad bit för sig, och den här datan bestod av ungefär 100 000 bitar, medan restic hämtade hela packfiler. Under Kopias återställning från S3 använde Garage det mesta av en CPU-kärna för att svara. Med 32 parallella arbetare i stället för standardens 8 tog det ändå 13 minuter. Lagring som klarar små läsningar bättre än en Garage på en server med två kärnor skulle minska skillnaden, men det testade vi inte. Kopia sparade dessutom en kopia av allt den återställde i sin cache, 2,4 GB här: standardgränsen är 5 GB.

Minnet var ungefär lika för restic och Borg, omkring 140 till 150 MB under en säkerhetskopiering, men Borg behöver också 80 till 100 MB för borg serve på backupservern. restic använde 250 MB när den skrev till S3. Kopia använde 400 till 450 MB. Inget av dem kör något mellan säkerhetskopiorna, utom restics REST-server, som använde som mest 22 MB, och Kopias server om du väljer att köra den.

Ta bort gamla kopior

Alla tre tar bort gamla snapshots enligt en regel, till exempel "behåll 7 dagliga, 4 veckovisa och 6 månatliga", och frigör sedan det utrymme som bara de använde.

restic gör båda med restic forget --prune. Att behålla 1 av 4 snapshots tog 7 sekunder över SFTP. Med REST-servern i läget append-only kan servern du säkerhetskopierar inte göra det: i restic-guiden rensar backupservern repot själv, och behöver repots lösenord för det. Sedan restic 0.18 behåller en regel också den äldsta snapshoten så länge det finns färre än regeln kräver, så med kopior från en enda dag behöll vår server två.

Borg delar upp det i två steg: borg prune tar bort arkiv, 8 sekunder, och borg compact frigör utrymmet, 2 sekunder här. compact behöver ingen nyckel, så det kan köras på backupservern utan lösenordet.

Kopia tillämpar sin gallringspolicy av sig själv efter varje snapshot. Standarden behåller de 10 senaste, plus 48 timvisa, 7 dagliga, 4 veckovisa, 24 månatliga och 3 årliga snapshots. Utrymmet frigörs av underhåll, som Kopia också kör av sig själv: en snabb omgång varje timme och en fullständig varje dygn, från den användare och värd som skapade repot. Det fullständiga underhållet tar bara bort data som har varit oanvänd en tid, som en säkerhetsmarginal: direkt efter att vi tagit bort tre snapshots hittade det 17 MB oanvänt, ansåg det för nytt och lät det ligga kvar. Med --safety=none tog det bort det på 23 sekunder.

Kontrollera säkerhetskopiorna

• restic check läser repots index och listan över varje snapshot, fil och mapp, och kontrollerar att all data de pekar på finns. Det tog 8 sekunder. restic check --read-data laddar också ner och dekrypterar varje bit och kontrollerar dess hash, 54 sekunder. --read-data-subset 10% läser en tiondel i taget, som restic-guiden gör varje månad.
• borg check kontrollerar repot på backupservern, varje segment mot dess kontrollsumma, utan nyckeln, och sedan arkiven med nyckeln. Det tog 27 sekunder. --verify-data dekrypterar också varje bit och kontrollerar dess autentiseringskod, 1 minut 44 sekunder.
• kopia snapshot verify kontrollerar att varje fil och mapp i varje snapshot pekar på data som finns, på 6 sekunder. Med --verify-files-percent=100 läser och dekrypterar den också varje fil, vilket tog 6 minuter 27 sekunder, av samma skäl som dess återställningar är långsamma.

Ingen av dem hittade några fel.

Kryptering

Alla tre krypterar på servern du säkerhetskopierar, innan något lämnar den, och autentiserar det de läser tillbaka, så att en ändrad eller skadad bit upptäcks. Ingen av dem sparar en kopia av ditt lösenord: tappar du det, är säkerhetskopiorna också förlorade.

• restic tar fram en nyckel ur ditt lösenord med scrypt. Parametrarna anpassas när du skapar repot: våra var N=32768, r=8, p=2. Den nyckeln låser upp en slumpad huvudnyckel, som krypterar all data med AES-256 i CTR-läge och autentiserar den med Poly1305-AES. Snapshots, filnamn och mappar är krypterade. Lagringen kan se storlek och antal på packfilerna och när de skrevs, och varje nyckelfil visar i klartext användarnamnet och värdnamnet som skapade den.
• Borg 1.4 tar fram nyckeln som låser upp dess nycklar med PBKDF2-HMAC-SHA256, 100 000 iterationer, vilket står emot lösenordsgissning sämre än scrypt. Data krypteras med AES-256 i CTR-läge och autentiseras med HMAC-SHA256, eller med BLAKE2b i lägena -blake2, som är snabbare på processorer utan SHA-instruktioner, som vår. Med repokey sparas den krypterade nyckeln i repot, och med keyfile bara på din server, så att lösenordet inte räcker ensamt. Borgs dokumentation säger att den inte döljer storleken på bitarna den sparar, och att den inte kan hålla data hemlig när flera servrar skriver till samma repo. Borg 2 går över till modern autentiserad kryptering och Argon2.
• Kopia tar fram nyckeln med scrypt (N=65536, r=8, p=1) och krypterar med AES-256-GCM som standard, eller ChaCha20-Poly1305. Snapshots, filnamn och mappar är krypterade, och de lagrade blobbarna har hashar som namn. Repots formatfil visar i klartext vilken version av Kopia som skapade det, dess unika id och nyckelinställningarna.

Skydd mot en hackad server

En säkerhetskopia som servern kan radera skyddar inte om någon tar över servern, eller om ett utpressningsvirus krypterar den. Varje verktyg har ett sätt att låta en server lägga till kopior men inte ta bort dem, och vi försökte radera kopior genom vart och ett:

• restic med rest-server --append-only, som i restic-guiden: restic forget misslyckades med 403 Forbidden, och alla snapshots fanns kvar. Utskriften däremellan ser ut som om snapshots togs bort, och restic 0.18.0 avslutade med status 0, så kontrollera med restic snapshots i stället för att lita på statuskoden.
• Borg med borg serve påtvingat i backupserverns authorized_keys, för nyckeln från servern du säkerhetskopierar:

  command="borg serve --restrict-to-repository /home/borg/web1 --append-only",restrict ssh-ed25519 AAAA... root@web1
  

  
  borg prune såg ut att fungera, och borg list visade ett arkiv i stället för fyra. Ingenting var ändå raderat på disken. Enligt Borgs dokumentation tog vi bort filerna från den senaste transaktionen på backupservern, rensade klientens cache, och alla fyra arkiven var tillbaka. Det fungerar bara tills någon kör borg compact i vanligt läge, vilket gör raderingarna permanenta, så kontrollera innan du kör compact. Nästa säkerhetskopia tog längre tid, eftersom Borg byggde om sin cache.
• Kopia med sin repo-server, där klienterna ansluter till Kopia på backupservern i stället för direkt till lagringen. Som standard får en klient radera sina egna snapshots. Vi ändrade den regeln till APPEND med kopia server acl, och sedan misslyckades kopia snapshot delete med access denied, och snapshotsen låg kvar. Servern har repots lösenord och kör underhållet. Kopia kan också sätta objektlås på lagring i S3, Azure och Google Cloud, så att inget kan raderas före ett visst datum, inte ens med lagringens nycklar. Garage har inte stöd för objektlås, så det testade vi inte.

restic har inget eget stöd för objektlås, och Borg 1.4 kan inte använda S3 alls. I alla tre fallen kan den som tar över själva backupservern fortfarande radera allt där, så håll inloggningen till den servern skild från servrarna den säkerhetskopierar.

Köra varje natt

Inget av de tre behöver en tjänst som körs hela tiden på servern du säkerhetskopierar: en systemd-timer som startar en tjänst en gång per natt fungerar för alla. restic-guiden har hela upplägget, med en varning vid inloggning när en säkerhetskopiering misslyckas. För Borg och Kopia använde vi samma timer, OnCalendar=*-*-* 02:00 med RandomizedDelaySec=1h och Persistent=true, och de här tjänsterna, som kördes och blev klara utan fel.

Borg, med lösenfrasen i /etc/borg/passphrase (chmod 600) och backupserverns adress i stället för backup.example.com:

[Unit]
Description=Back up this server with Borg
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
Environment=BORG_REPO=ssh://borg@backup.example.com/home/borg/web1
Environment="BORG_PASSCOMMAND=cat /etc/borg/passphrase"
Nice=10
IOSchedulingClass=idle
ExecStart=/usr/bin/borg create --compression zstd,3 --exclude-caches ::{hostname}-{now} /etc /home /srv
ExecStartPost=/usr/bin/borg prune --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --glob-archives {hostname}-*

Kopia sparar repots lösenord bredvid sin konfiguration efter kopia repository create eller connect, läsbart bara för root, så tjänsten behöver ingen egen hemlighet. Den behöver däremot sökvägen till konfigurationen: en systemtjänst har ingen hemkatalog satt, och då svarar Kopia repository is not connected. Gallring och underhåll körs som en del av snapshoten:

[Unit]
Description=Back up this server with Kopia
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
Environment=KOPIA_CONFIG_PATH=/root/.config/kopia/repository.config KOPIA_CHECK_FOR_UPDATES=false
Nice=10
IOSchedulingClass=idle
ExecStart=/usr/bin/kopia snapshot create /etc /home /srv

KopiaUI och Kopias server kan också ta snapshots enligt ett eget schema, som du ställer in i policyn. På en server är timern enklare att hålla koll på med systemctl --failed.

Licens och hur projekten mår

Vi kontrollerade projektens förråd den 14 oktober 2026.

• restic har licensen BSD 2-Clause, och det har rest-server också. Projektet startade 2014, har 36 500 stjärnor på GitHub, och 46 personer gjorde ändringar det senaste året, de flesta av en huvudutvecklare. Den senaste versionen är 0.19.1 från juli 2026. Inget företag står bakom, och det finns ingen betalversion.
• Borg har licensen BSD 3-Clause. Det startade 2015 som en fork av Attic, har 13 800 stjärnor, och 26 personer gjorde ändringar det senaste året, de flesta av dess mångåriga huvudutvecklare, som arbetar på Borg 2. Den senaste stabila versionen är 1.4.5 från juli 2026; Debian 13 har 1.4.0. Det finns ingen betalversion.
• Kopia har licensen Apache 2.0. Det startade 2015, har 14 300 stjärnor, och 26 personer gjorde ändringar det senaste året. Den senaste versionen är 0.23.1 från juni 2026. Versionsnumret är fortfarande under 1.0. Det finns ingen betalversion.

Alla tre är gratis. Det du betalar för är lagringen: en andra server eller en S3-tjänst.

Vilken ska du välja

• De flesta servrar: restic. Följ vår restic-guide. Den var snabb på att säkerhetskopiera och återställa, använde lite minne, finns i Debian, och dess REST-server i läget append-only vägrade radera något när vi försökte. Dess svagheter: backupservern behöver repots lösenord för att ta bort gamla kopior, Debians version ligger efter den senaste, och en nekad radering kan ändå avslutas med status 0.
• Säkerhetskopior till en SSH-server eller lagringstjänst: Borg. Den är beprövad, liten och lagrade datan lika kompakt som de andra, och borg compact körs utan nyckeln. På en liten server var den dubbelt så långsam, läget append-only tar emot en radering och lämnar åt dig att rulla tillbaka den för hand, den har den äldsta nyckelhärledningen av de tre, och den har inget S3 förrän Borg 2, vars nya format innebär att du måste flytta dina kopior.
• Ett grafiskt gränssnitt, alla regler på ett ställe eller objektlås på S3: Kopia. Ett kommando säkerhetskopierar, gallrar och kör underhåll, och dess repo-server kan neka radering per användare. Den använde tre gånger så mycket minne, cachen kan växa till 5 GB, den komprimerar ingenting förrän du ställer in en policy, och dess återställningar tog tre till tolv gånger så lång tid som restics i vårt test. Den finns inte i Debian, så uppdateringar kommer från Kopias eget förråd.

Vilket som helst av dem kan köras på servern du redan har: det är säkerhetskopiorna som behöver utrymmet, inte farten. För backupservern har paketet Micro 250 GB lagring, nog för deduplicerade kopior av många servrar. Vill du hellre ha S3 än en andra server med SSH, fungerar Garage på en andra server med restic och Kopia.