Backblaze B2 Object Lock med restic: hvad den beskytter

Du har slået Object Lock til og kørt restic forget --prune, og kommandoen lykkedes, så filerne er væk fra listen. Låsen virker, men den beskytter noget andet, end du gik ud fra, og forskellen afgør, om den ville redde dig.

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

Når restic sletter fra en låst bucket

B2-buckets er altid versionerede, og Object Lock beskytter den enkelte version af en fil frem for filnavnet. En sletning efter navn fjerner intet. B2 indsætter en slettemarkør, som B2's native API kalder en hide marker (skjulemarkør), og den tidligere version bliver liggende. Backblaze skriver: »Ingen af Object Lock-tilstandene forhindrer dig i at uploade en ny version af et låst objekt… Du kan også skjule et låst objekt, så det ikke vises i objektlister.« Låsen afviser sletning af selve versionen, før dens opbevaringstid udløber. Resultatet for restic afhænger af, hvordan backenden sletter.

restics dokumentation anbefaler under alle omstændigheder det S3-kompatible API til B2, og om S3-backenden står der, at den »kun vil skjule filer, der ikke længere er nødvendige«. Prune kører til ende som normalt, men frigør intet, før låsen på hver skjult version er udløbet, og en livscyklusregel eller et oprydningsjob sletter den.

Beskyttelsen mod forskellige angribere

Opsætningen skal stoppe en angriber, der har overtaget serveren og dens backupnøgle. Er nøglen append-only, uden rettigheden deleteFiles, kan angriberen skjule filer og uploade nye versioner oven på gamle navne, men ikke slette en eneste version. Over for den angriber tilføjer Object Lock ikke meget. Object Lock gør først en forskel over for nøgler, der kan slette.

Den vigtigste begrænsning er, at standardopbevaringstiden tælles fra hver fils upload. restic deduplicerer, så nattens snapshot genbruger pakkefiler fra dengang, dataene første gang blev taget backup af, og deres låse kan for længst være udløbet. Med 30 dages opbevaringstid kan en, der kan slette, stadig fjerne en gammel pakkefil og ødelægge alle snapshots, der bruger den, også gårsdagens. restics vedligeholder sagde det ligeud i 2023: »for at garantere, at et snapshot kan gendannes i en bestemt periode, skal alle relevante filer være beskyttet med en tilstrækkeligt lang Object Lock. Det virker derfor ikke bare at sætte en Object Lock én gang.«

restic kan ikke sætte eller forlænge låse, og kildekoden i version 0.19.1 indeholder ingen kode til Object Lock. Kopia forlænger låse under vedligeholdelse, på B2 kun via sin S3-backend. Er uforanderlighed på snapshotniveau et ufravigeligt krav, afgør det dit valg af værktøj. restic vs Borg sammenligner, hvordan alternativerne håndterer append-only.

Omkostningen

Object Lock er i sig selv gratis. Du betaler almindelig lagerpris for hver låst version: 6,95 USD pr. TB om måneden til B2's pay-as-you-go-pris i september 2026. En skjult version bliver liggende, indtil dens lås er udløbet, og en livscyklusregel eller et oprydningsjob sletter den. Livscyklusregler kører én gang om dagen og springer låste versioner over.

Lad D være antallet af dage, du beholder en version, efter at den er skjult, altså det vindue, som guiden om lagervækst beder dig dimensionere, og lad R være standardopbevaringstiden. Er R ikke længere end D, lægger Object Lock lidt eller intet til regningen, fordi intet af det, låsen holder på, ville være blevet slettet tidligere. Omkostningen viser sig, når R er længere end D, for eksempel med Keep only the last version, hvor D er én dag. Så bliver hver fil, som prune skjuler inden for R dage efter dens upload, faktureret, indtil låsen udløber.

Compliance-opbevaring kan ikke forkortes, og Backblazes dokumenterede vej ud af at have låst for meget i for lang tid er at lukke kontoen. Standardopbevaringstiden låser desuden alt, der uploades, inklusive skrald, som en angriber uploader med serverens nøgle, og som du så betaler for at beholde i R dage. I governance-tilstand kan en separat opbevaret nøgle med bypassGovernance og deleteFiles fjerne det. I compliance-tilstand kan intet fjerne det.

Dimensionér opbevaringstiden efter din opdagelsestid

D og R måler forskellige ting. D tælles fra det tidspunkt, en fil bliver skjult, så den beskytter alt, også gamle pakkefiler, mod serverens nøgle. R tælles fra upload, så den beskytter kun nye uploads, men mod alle nøgler. Begge bør være længere end den tid, det ville tage dig at opdage en kompromittering og handle. Lad ikke regningen bestemme dem. Bliver alarmerne læst én gang om ugen, og kan den, der læser dem, være væk i to uger, er alt under en måned ikke et sikkerhedsnet.

Med en append-only-nøgle bør du også skrive forget-politikker med --keep-within. restics dokumentation anbefaler det, fordi en angriber kan tilføje falske snapshots, der skubber de rigtige ud af en politik som »behold tre ugentlige«.

Object Lock sammen med en append-only-nøgle og et oprydningsjob

Object Lock er et ekstra sikkerhedsnet under et append-only-design og erstatter det ikke. I det design kan den maskine, der tages backup af, ikke slette sin egen historik, og prune kører fra en separat administrationsmaskine. Designet har sine egne ulemper, og guiden dér sammenligner dem med Veeams uforanderlige repositories.

Serverens nøgle får lov at liste, læse og skrive i sin egen bucket og intet andet: ingen deleteFiles, ingen bypassGovernance, ingen rettigheder til opbevaringstid eller bucket-indstillinger. Backblaze dokumenterer, at sletning efter navn kræver writeFiles, mens sletning af en bestemt version kræver deleteFiles.

# On the admin machine, never on the server being backed up.
# One key per server, limited to its bucket, without deleteFiles.
b2 key create --bucket acme-restic web1-backup \
  listBuckets,listAllBucketNames,listFiles,readFiles,writeFiles

# The long listing shows every key's capabilities. Check them.
b2 key list --long

# On the server: restic through the S3-compatible API.
export AWS_ACCESS_KEY_ID=<keyID of web1-backup>
export AWS_SECRET_ACCESS_KEY=<applicationKey of web1-backup>
restic -r s3:s3.<region>.backblazeb2.com/acme-restic/web1 snapshots

Administrationsmaskinen kører forget, prune og oprydningen af versioner med en nøgle, der har deleteFiles, men ikke bypassGovernance. Brug også backenden s3: dér. restics backend b2: sletter permanent alle ulåste versioner, når nøglen tillader det, og springer dermed dit oprydningsvindue over. Oprydningen skal behandle en afvist sletning af en låst version som normalt og gå videre. backend cleanup-hidden i rclone fjerner alle gamle versioner frem for dem, der er ældre end en skæringsdato, så det er det forkerte værktøj her.

At slå låsen til på en eksisterende bucket kræver to ændringer. Fordi en fejl i compliance-tilstand ikke kan gøres om, er den forsigtige rækkefølge governance først og derefter compliance, når en hel opbevaringsperiodes regninger stemmer med dit skøn.

# With a key that can change bucket settings, not the server's key.
# One-way switch: Object Lock cannot be disabled afterwards.
b2 bucket update --file-lock-enabled acme-restic

# Nothing is locked until a default retention exists, and it only
# applies to files uploaded from now on.
b2 bucket update --default-retention-mode governance \
  --default-retention-period "30 days" acme-restic

# Check isFileLockEnabled, defaultRetention and lifecycleRules.
b2 bucket get acme-restic

Gendannelse efter et angreb

1. Tilbagekald serverens nøgleKør b2 key delete med nøglens ID fra administrationsmaskinen. Angriberen mister adgangen, og din historik forbliver uændret.
2. Stop uret for gamle versionerSæt oprydningsjobbet for versioner på pause, og hæv daysFromHidingToDeleting i livscyklusreglen. Reglerne kører én gang om dagen, så gør det, før du begynder at analysere.
3. Vælg et tidspunkt før kompromitteringenBrug det tidligste tegn i dine detektionsdata, hvad enten det er en alarm, et mærkeligt snapshot eller en uventet upload.
4. Kopiér repositoryet, som det så ud dengangMed --b2-version-at viser rclone bucketen, som den var på det tidspunkt, inklusive filer, der er skjult siden. rclone nægter at skrive i den tilstand, så kopieringen kan ikke gøre skaden værre. Du skal have lokal plads til hele repositoryet.
5. Kontrollér, før du stoler på denFjern de låsefiler, kopien måtte have med, kør restic check --read-data på den, gendan derefter, og få applikationen op at køre.
6. Genopbyg, og start på en friskByg en ny server med nye nøgler og et nyt repository eller en ny bucket, med den verificerede kopi som udgangspunkt. At gøre filerne synlige igen på stedet kræver deleteFiles og fjerner ikke de versioner, der er uploadet oven på originalerne.

# On a clean machine. b2admin is an rclone remote on a key that can
# list and read the bucket. --b2-version-at permits no writes.
rclone copy --b2-version-at 2026-09-01T00:00:00Z \
  b2admin:acme-restic/web1 /srv/restore/web1

# The copy includes any lock file that existed at that moment, and
# check refuses to start past it. Nothing else uses this copy.
restic -r /srv/restore/web1 unlock --remove-all
restic -r /srv/restore/web1 check --read-data
restic -r /srv/restore/web1 snapshots
restic -r /srv/restore/web1 restore latest --target /srv/restore/files

Øv det, før du får brug for det, og tag tid på det. Se guiden om backup, der kan gendannes.

Derfor tror folk, at Object Lock ikke virker

Sletningerne lykkes. B2 tillader med vilje, at låste filer bliver skjult. b2 ls -r --versions på repositoryets sti viser, at versionerne stadig er der.

Der er ingen standardopbevaringstid. At slå Object Lock til låser ikke noget i sig selv. Filer bliver først uforanderlige, når der er sat en standardopbevaringstid.

Filerne er ældre end opbevaringstiden. Du kan slå Object Lock til på en eksisterende bucket, men kun den ene vej og ikke på en replikeringskilde eller en begrænset bucket som fx et snapshot. Standardopbevaringstiden dækker kun filer, der uploades bagefter. Backblazes side om Object Lock siger det, men hjælpeteksten til bucket create i b2 5.0.0 siger stadig, at indstillingen ikke kan ændres efter oprettelsen. bucket update --file-lock-enabled gør det. Andre S3-kompatible lagre opfører sig anderledes: MinIO nægter at slå Object Lock til på en eksisterende bucket.

En nøgle kan gå udenom. Governance-tilstand binder kun nøgler uden bypassGovernance.

En livscyklusregel skjuler aktuelle filer. daysFromUploadingToHiding skjuler alle versioner, låste eller ej, og så kan restic ikke læse sine egne pakkefiler.

Faldgruber

• Prune gør bucketen større. På en testbucket i governance-tilstand sluttede forget --prune med exitkode 0 og rapporterede 14,3 MiB tilbage, mens de lagrede bytes steg fra 22,5 MB til 30,0 MB. Den ompakkede pakkefil er en ny upload, og de pakkefiler, den erstattede, bliver liggende som låste, skjulte versioner. Regn med, at hver prune lægger til regningen, indtil de låse udløber, og mål bucketen med b2 bucket get --show-size, som tæller skjulte versioner med. Det gør restics tal ikke.
• En udløbet lås på en gammel pakkefil ødelægger nye snapshots. Vi tog backup to gange og lod derefter låsene fra første kørsel udløbe, hvilket vi simulerede ved at forkorte dem med en bypass-nøgle. En nøgle, der kunne slette versioner, men ikke gå udenom låsen, fjernede de to pakkefiler og blev afvist på de to nyere. restic check rapporterede derefter begge pakkefiler som manglende, og restic restore latest gendannede kun den ene fil, der var tilføjet i anden kørsel. Hold vinduet for skjulte versioner længere end din opdagelsestid. Låsen alene dækker ikke gamle pakkefiler.
• Serverens nøgle skal stadig kunne skjule. Med en nøgle helt uden sletterettighed skrev hver restic-kørsel error while unlocking med Access Denied, sluttede med exitkode 0 og efterlod sin låsefil. Efter én forget-kørsel med den nøgle fik dens eksklusive lås alle senere kommandoer, også backups, til at slutte med exitkode 11 og "repository is already locked", og en almindelig restic unlock fra en anden maskine ville ikke fjerne en lås, der var under 30 minutter gammel. Det gjorde kun unlock --remove-all. På B2 undgår nøglen ovenfor det, fordi writeFiles dækker sletning efter navn, som skjuler. På andet S3-lager skal du tillade s3:DeleteObject og nægte s3:DeleteObjectVersion. Den nøgle kørte backup, forget og prune uden problemer og kunne stadig ikke slette en version.
• At gøre alt synligt igen bringer restics egne sletninger tilbage. Da vi fjernede alle slettemarkører efter et simuleret angreb, kom fire forældede låsefiler tilbage, et snapshot som forget havde fjernet, og dublerede indeksposter, mens den overskrevne config-fil stadig fejlede med "ciphertext verification failed". Det sletter også registreringen af, hvornår hver fil blev skjult, så senere kopier fra et bestemt tidspunkt indeholder det hele. Kopiér i stedet bucketen, som den så ud på et bestemt tidspunkt, eller fjern kun markører, der er nyere end kompromitteringen.
• Kopien fra et bestemt tidspunkt kan indeholde låsefiler. En kopi taget på et tidspunkt, hvor en restic-kommando holdt en lås, fik restic check på kopien til at slutte med exitkode 11 og "repository is already locked". Kør restic unlock --remove-all på kopien først, som i kommandoerne ovenfor. Intet andet bruger den.

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, mc RELEASE.2025-08-13T08-35-41Z og rclone 1.75.1, hvis --s3-version-at er S3-tvillingen til --b2-version-at. Vi testede versionerede buckets og buckets i governance- og compliance-tilstand, en nøgle uden sletterettighed og en nøgle, der kun kan skjule, et angreb med overskrivning og skjulning, og gendannelse både fra en kopi fra et bestemt tidspunkt og ved at kopiere gamle versioner tilbage, hver gang afsluttet med restic check --read-data. Vi kontrollerede kun kommandoerne til b2 mod parseren og hjælpeteksten i b2 5.0.0. Vi testede intet mod en rigtig Backblaze B2-konto. B2's skjulemarkører og 401-svar, backenden b2:, livscyklusregler, nøglerettigheder, hovednøglen, priser og lukning af konto bygger på Backblazes og restics dokumentation og kildekode. Vi satte udløb via livscyklusregler op i MinIO, men observerede det ikke, fordi den korteste periode er én dag.

Kilder

1. Object Lock, Backblaze B2-dokumentation
2. How to Enable Object Lock with the Backblaze B2 Native API, Backblaze
3. How to Enable Object Lock or a Legal Hold on an Existing Bucket, Backblaze
4. Lifecycle Rules, Backblaze B2-dokumentation
5. S3-Compatible App Keys, Backblaze
6. Application Key Capabilities, Backblaze
7. b2_delete_file_version, Backblaze B2 Native API
8. S3 Delete Object, Backblaze B2 S3-Compatible API
9. Digging Deeper Into Object Lock, Pat Patterson, Backblazes blog, 28. november 2023
10. B2 Cloud Storage pricing, Backblaze, tjekket september 2026
11. B2 command-line tool documentation, Backblaze, version 5.0.0
12. Managing Object Lock, Amazon S3 User Guide
13. Preparing a new repository: Backblaze B2, restic-dokumentationen
14. Removing backup snapshots: security considerations in append-only mode, restic-dokumentationen
15. Changelog 0.13.0: upload checksums for S3, enabling Object Lock buckets, restic, 26. marts 2022
16. Changelog 0.15.0: B2 falls back to hiding files, restic, 12. januar 2023
17. B2 backend source, Remove, restic
18. Issue 3491: forget fails with B2 and object locks, restic, august 2021
19. Backblaze Object Lock / Ransomware protection, restic-forummet, september 2023
20. Backblaze B2, rclone-dokumentationen
21. Ransomware protection, Kopia-dokumentationen