---
title: "Restic på Backblaze B2: derfor bliver lageret ved at vokse"
description: "Versionering kan ikke slås fra på B2, og den anbefalede livscyklusregel følger ikke med restic. Her er, hvad Backblaze bekræftede, da vi eskalerede sagen."
source: "https://wardio.net/da/guides/restic-backblaze-lager-vokser/"
---

**Backup**

# Restic på Backblaze B2: derfor bliver repositoryet ved at vokse

Backuppen er 400 GB, og bucketen fylder over en terabyte. Intet er i stykker, den livscyklusregel, alle anbefaler, er slået til, og alligevel bliver forskellen ved med at vokse.

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

**Det korte svar**

Backblaze B2-buckets er altid versionerede, og versionering kan ikke slås fra. Når restic kører prune eller pakker om gennem det S3-kompatible API, som restics dokumentation anbefaler til B2, bliver sletningerne til skjulemarkører, og B2 beholder den gamle version. Livscyklusreglen *Keep only the last version of the file* skal rydde dem op, men den følger ikke med den måde, restic omskriver pakkefiler på. Backblaze-supporten bekræftede hullet, da vi eskalerede det, og deres egen løsning er at køre en ekstern oprydning, der lister versionerne, beholder den aktuelle og sletter resten.

## Årsagen til forskellen

1.  **B2-buckets er altid versionerede, og det kan ikke slås fra**: Versionering er en fast egenskab ved platformen. Backblaze-supporten bekræftede, at der ikke findes nogen mulighed for at slå det fra. Hver sletning, restic sender gennem det S3-kompatible API, som restics dokumentation anbefaler til B2, bliver til en skjulemarkør, og B2 beholder den tidligere version bag markøren. restics egen b2:-backend opfører sig anderledes. Med en nøgle, der har deleteFiles, sletter den versionerne permanent.
2.  **restic sletter og erstatter hele tiden**: Prune pakker data om. Den fjerner gamle pakkefiler og skriver nye. På et almindeligt filsystem frigør det plads. På B2 giver det to objekter, hvor der før var ét.
3.  **Den anbefalede livscyklusregel følger ikke med**: Keep only the last version of the file er den regel, restics egen dokumentation og de fleste vejledninger peger på. Den hjælper, men den passer ikke til den måde, restic pakker om på, og den efterlader skjulte versioner.
4.  **Så repositoryet vokser, uden at backuppen gør**: Det synlige symptom er en bucket, der er flere gange så stor, som restic melder. Der er intet galt med backuppen. Lagerregningen tæller bare versioner med, som ingen kan bruge.

## Backblazes svar

Vi løb ind i det på tværs af flere kunders repositories og eskalerede det. Backblazes Technical Support Engineering-team skrev: livscyklusreglen *stemmer ikke altid præcist overens med restics oprydning og ompakning, især når restic sletter eller erstatter pakkefiler på måder, der efterlader skjulte versioner.*

I stedet for en anden livscyklusregel anbefalede de at lade restic styre sit repository som normalt og bagefter køre en separat oprydningsproces, der fjerner de gamle skjulte versioner. De anerkendte også, at deres egen vejledning til restic ikke dækker det, og gav det videre til deres dokumentationsteam.

I vores kunders repositories har bucketen fyldt omkring to til tre gange den forventede størrelse på repositoryet. Tallet er vores egen observation på tværs af flere konti. Backblaze har ikke målt det, så brug det som en størrelsesorden, og regn ikke med, at det er fast.

## Et råd, du skal ignorere

Det første råd, vi fik, var at sætte `daysFromUploadingToHiding` til 1. Gør det ikke på en restic-bucket. Det skjuler alle filer, også den aktuelle version, cirka 24 til 48 timer efter upload, så restic ikke længere kan læse sine egne pakkefiler, og gendannelser fejler. Supporten rettede det i den næste besked. Rådet ser harmløst ud, og fejlen viser sig først den dag, du skal gendanne, så lad feltet være tomt.

## Det skal du gøre i stedet

Lad *Keep only the last version of the file* være slået til, for den fjerner noget af ophobningen. Kør derefter en oprydning, der lister objektversioner, beholder alle aktuelle objekter og sletter ikke-aktuelle versioner, der har været skjult længere end en fastsat grænse. Det er den løsning, Backblaze foreslår. På en testbucket skar sådan en oprydning 129 MB lagrede versioner ned til de 30 MB, restic brugte, og `restic check --read-data` bestod bagefter.

**Placeringen.** Sletning af objektversioner kræver sletterettigheder. Har du bevidst begrænset backupnøglen, så en kompromitteret server ikke kan ødelægge sin egen historik, må oprydningen ikke ligge på den server. Så giver du den nøjagtig den rettighed tilbage, du fjernede. Oprydningen hører til på en separat administrationsmaskine, som serveren, der tages backup af, ikke kan nå.

**Opbevaringstiden.** Gamle versioner er det eneste, der beskytter dig mod en angriber, der har serverens adgangsoplysninger og overskriver objekter. På S3-kompatibelt lager er `PutObject` selve overskrivningen, og der findes ingen separat rettighed at holde tilbage. Sletter du dem, frigør du plads og fjerner den beskyttelse. Fastsæt opbevaringstiden efter, hvor lang tid du ville være om at *opdage* et indbrud, og lad ikke lagerregningen bestemme den. En uges historik er intet sikkerhedsnet, hvis du ville være en måned om at få øje på problemet.

## Når restic er det forkerte værktøj

Kræver en regulering ægte write-once-opbevaring, når du ikke derhen med det her alene. restic kører godt nok på en bucket med Object Lock, fordi sletningerne bliver til skjulemarkører i stedet for at fjerne låste versioner. restic kan derimod ikke sætte eller forlænge låse. Hver fil er derfor kun beskyttet i en fast periode efter upload, mens aktuelle snapshots stadig afhænger af ældre pakkefiler, hvis låse er udløbet. [Guiden om Object Lock](/da/guides/restic-b2-object-lock/) gennemgår, hvad den kombination beskytter mod, og hvad den ikke beskytter mod. En tidligere version af denne guide sagde, at restic holder op med at virke under Object Lock. Det var forkert, og vi har rettet det.

## Faldgruber

-   **restics tal er ikke regningen.** Efter fem runder med backup og prune på en versioneret testbucket uden udløbsregel meldte `restic stats --mode raw-data` 27,2 MiB, mens bucketen rummede 129 MB i 60 versioner, 4,3 gange de 30 MB i aktuelle objekter. En enkelt prune havde allerede fordoblet det. Mål med `b2 bucket get --show-size`, som tæller skjulte versioner med, frem for med restic.
-   **Regn versioners alder fra det tidspunkt, de blev skjult, ikke uploadet.** En ikke-aktuel versions eget tidsstempel er dens uploadtidspunkt. Med en grænse på 30 sekunder valgte en oprydning, der brugte det, to pakker, som prune havde skjult 12 sekunder tidligere, fordi de var blevet uploadet 47 sekunder før det. Tag alderen fra den næste nyere version eller skjulemarkør for samme navn, sådan som Backblazes livscyklusregler tæller. Den udgave af oprydningen beholdt begge pakker.
-   **Låste versioner kan ikke slettes.** På en testbucket i compliance-tilstand afviste MinIO oprydningen på alle 12 skjulte versioner med "Object is WORM protected", en HTTP 400. Backblaze dokumenterer 401 access\_denied i samme situation. Et script, der stopper ved den første fejl, når aldrig resten. Log afvisningen, spring versionen over, og lad en senere kørsel slette den, når låsen udløber.
-   **En backupnøgle helt uden sletteret efterlader forældede låse.** Med en nøgle, der kun måtte liste, læse og skrive, skrev hver restic-kørsel `error while unlocking` med Access Denied og efterlod sin låsefil. En enkelt `forget` med den nøgle efterlod en eksklusiv lås, der fik alle senere backups til at slutte med exitkode 11, indtil admin-værten kørte `restic unlock --remove-all`. Backblaze dokumenterer, at `writeFiles` dækker sletning ved navn, så en B2-nøgle uden `deleteFiles` stadig kan skjule sine låse. På andet S3-lager skal du kun tillade `s3:DeleteObject` under `locks/` og eksplicit nægte `s3:DeleteObjectVersion`. På MinIO var det ikke nok at udelade retten til at slette versioner.

**Sådan blev det testet.** Den 23. september 2026 kørte vi restic 0.19.1 mod MinIO RELEASE.2025-09-07T16-13-09Z i Docker på en Ubuntu 24.04-vært, som S3-kompatibel erstatning for B2, med AWS CLI 1.46.1 og mc RELEASE.2025-08-13T08-35-41Z: gentagne runder med backup og prune på en versioneret bucket, et script til oprydning af versioner med begge måder at regne alder på, efterfulgt af `restic check --read-data`, en bucket i compliance-tilstand og begrænsede nøgler. Vi testede intet mod en rigtig Backblaze B2-konto. At versionering på B2 ikke kan slås fra, hvor godt reglen *Keep only the last version* følger med, og hvad supporten fortalte os, bygger på Backblazes dokumentation og vores korrespondance, og tallet to til tre gange kommer fra kundekonti. Vi satte udløb via livscyklusregler op i MinIO, men observerede det ikke, fordi den korteste periode er én dag.

## Kilder

1.  [Preparing a new repository: Backblaze B2](https://restic.readthedocs.io/en/stable/030_preparing_a_new_repo.html), dokumentation til restic
2.  [B2 backend source, Remove](https://github.com/restic/restic/blob/master/internal/backend/b2/b2.go), restic
3.  [Lifecycle Rules](https://www.backblaze.com/docs/cloud-storage-lifecycle-rules), dokumentation til Backblaze B2
4.  [S3-Compatible App Keys](https://www.backblaze.com/docs/cloud-storage-s3-compatible-app-keys), Backblaze
5.  [b2\_delete\_file\_version](https://www.backblaze.com/apidocs/b2-delete-file-version), Backblaze B2 Native API
6.  [B2 command-line tool documentation](https://b2-command-line-tool.readthedocs.io/en/master/), Backblaze, version 5.0.0

## Spørgsmål

### Kan jeg slå versionering fra på en Backblaze B2-bucket?

Nej. B2-buckets er altid versionerede, og der er ingen indstilling til at slå det fra. Backblaze-supporten bekræftede det direkte. Når du sletter en fil ved navn, opretter B2 en skjulemarkør og fjerner ingen data. Det er derfor, livscyklusregler overhovedet findes.

### Løser livscyklusreglen "Keep only the last version of the file" restics lagervækst?

Kun delvist. Backblazes Technical Support Engineering-team bekræftede, at reglen ikke altid passer til restics oprydning og ompakning, især hvor restic sletter eller erstatter pakkefiler på måder, der efterlader skjulte versioner. De anbefaler en ekstern oprydningsproces frem for en anden livscyklusregel.

### Skal jeg sætte daysFromUploadingToHiding til 1 på en restic-bucket?

Nej. Det skjuler alle filer, også den aktuelle version, cirka 24 til 48 timer efter upload, så restic ikke længere kan læse sine egne pakkefiler, og gendannelser holder op med at virke. Lad feltet daysFromUploadingToHiding være tomt på en restic-bucket. Kun daysFromHidingToDeleting er sikkert at sætte.

### Hvor skal oprydningsscriptet køre?

På en separat administrationsmaskine, som serveren, der tages backup af, ikke kan nå. Sletning af objektversioner kræver sletterettigheder, og et append-only-backupdesign holder netop den rettighed væk fra serveren.

**Betaler du for versioner, som ingen kan gendanne fra?**

Den gratis gennemgang ser på, hvad din backup koster i forhold til det, den beskytter. [Den bredere guide om backup](/da/guides/backup-der-kan-gendannes/) dækker resten.

[Gratis servergennemgang](/da/kontakt/)