---
title: "resticprofile-eksempler: en produktionsopsætning forklaret"
description: "Komplet resticprofile-opsætning til en Linux-server: S3-repository, hooks til databasedump, systemd-tidsplaner, med oprydning og check på en separat maskine."
source: "https://wardio.net/da/guides/resticprofile-i-produktion/"
---

**Backup**

# resticprofile-eksempler: en produktionskonfiguration forklaret

Den officielle dokumentation beskriver hver nøgle, resticprofile accepterer, én referenceside ad gangen. Den viser ikke, hvordan de passer sammen på en server, du er afhængig af, eller hvor opbevaringsreglerne hører hjemme, når serveren ikke må slette sine egne backups.

Af David Kabel · Opdateret 2026-09-26 · 18 min læsning

**Det korte svar**

En resticprofile-opsætning til produktion består af to konfigurationsfiler. Serverens profil indeholder repositoryet, en env-file med en lagernøgle, der ikke kan slette data, en password-file, kilder og excludes, et databasedump i `run-before` og en systemd-tidsplan. Fordi den nøgle ikke kan slette backupdata, kører `forget`, `prune` og `check` fra en anden profil på en administrationsmaskine med `keep-within`\-regler og `read-data-subset`. Begge eksempler nedenfor er YAML, kontrolleret mod resticprofile 0.33.1.

## Versioner og filformat

Alt her er kontrolleret mod resticprofile 0.33.1, den nyeste udgivelse (15. april 2026), og restic 0.19.1 (5. juli 2026). resticprofile læser TOML, YAML, JSON og HCL, og dokumentationen anbefaler TOML eller YAML. Eksemplerne er YAML, og begge giver de forventede restic-kommandolinjer med den versions `show` og `--dry-run`.

Begge filer erklærer `version: "1"`. Konfigurationsformat 2 findes, men den aktuelle dokumentation kalder det stadig en forhåndsversion, der er »kun til test og feedback«, så en produktionsfil bør ikke afhænge af det. Længere nede betyder det noget, at en retention-sektion i version 1 gør ingenting, før du slår den til, og at nogle nedarvede lister flettes ind i forælderens liste efter position i stedet for at erstatte den.

## To maskiner, to profiler

Serveren tager backup med en lagernøgle, der ikke kan slette data, så den, der kompromitterer serveren, ikke kan ødelægge dens historik. restics dokumentation beskriver konsekvensen: `forget` og `prune` »kræver fuld læse-, skrive- og sletteadgang til repositoryet«, og den anbefalede opsætning for append-only-repositories er en separat, velbeskyttet klient til den vedligeholdelse. Derfor har serverprofilen slet ingen opbevaringsregler. En anden profil, på en administrationsmaskine som serveren ikke kan nå, fjerner gamle snapshots, kører prune og kontrollerer dataene. [Oprydningen af versioner på Backblaze B2](/da/guides/restic-backblaze-lager-vokser/) hører også til dér.

Administrationsmaskinen har også en kopi af repositoryets adgangskode. restic advarer om, at mistes adgangskoden, er dataene uopretteligt tabt, og en adgangskode, der kun findes på serveren, forsvinder sammen med serveren.

## Serverprofilen

```
# /etc/resticprofile/profiles.yaml on the server (web1)
version: "1"

web1:
  repository: "s3:https://objects.example.net/acme-web1-restic"
  password-file: "/etc/resticprofile/web1.key"
  env-file:
    - "/etc/resticprofile/web1.env"
  lock: "/run/resticprofile-web1.lock"
  status-file: "/var/lib/resticprofile/status.json"
  prometheus-save-to-file: "/var/lib/node_exporter/textfile/resticprofile.prom"

  backup:
    source:
      - "/etc"
      - "/home"
      - "/srv"
      - "/var/www"
      - "/var/backups/db"
    exclude:
      - "node_modules"
      - "/home/*/.cache"
    exclude-file: "excludes.txt"
    exclude-caches: true
    tag:
      - "web1"
    extended-status: true

    run-before: "runuser -u postgres -- pg_dump --format=custom shop > /var/backups/db/shop.dump"
    run-after-fail: 'logger -t resticprofile "web1 backup failed: $ERROR_MESSAGE"'
    run-finally: "rm -f /var/backups/db/shop.dump"

    schedule: "*-*-* 01:30"
    schedule-permission: system
    schedule-lock-wait: 2h
    schedule-log: "/var/log/resticprofile-web1.log"
    schedule-after-network-online: true
```

```
# /etc/resticprofile/web1.env   (owner root, mode 600)
# Storage key that can delete only restic's lock files. The key that can delete data stays on the admin host.
AWS_ACCESS_KEY_ID=server-key-id
AWS_SECRET_ACCESS_KEY=server-key-secret
# AWS_DEFAULT_REGION=eu-central-1   only if your provider needs a region
```

```
# on web1, as root, once
install -d -m 700 /etc/resticprofile /var/backups/db
install -d -m 755 /var/lib/resticprofile
install -d -m 755 /var/lib/node_exporter/textfile   # or your textfile collector's directory
resticprofile generate --random-key > /etc/resticprofile/web1.key
# write web1.env as shown above, then
chmod 600 /etc/resticprofile/web1.key /etc/resticprofile/web1.env
# copy web1.key to the admin host before anything else
```

### Repository og hemmeligheder

`repository` bruger restics format for S3-kompatibelt lager, `s3:https://host/bucket`. restic læser lagernøglerne fra `AWS_ACCESS_KEY_ID` og `AWS_SECRET_ACCESS_KEY`, som ligger i den dotenv-fil, `env-file` peger på. Repositoryets adgangskode ligger i `password-file`. Kun root kan læse de to filer, så YAML-filen indeholder ingen hemmeligheder, og du kan lægge den i versionsstyring.

Serverens nøgle skal have én snæver sletterettighed. restic fjerner sin låsefil til sidst i hver kommando, og med en nøgle, der ikke kan slette noget, efterlader hver kørsel sin lås. Backuppen slutter stadig med exitkode 0, men administrationsmaskinens `check` og `forget` fejler derefter med "repository is already locked". Tillad kun sletninger under `locks/`. Det er også det, restics rest-server tillader i append-only-tilstand. På MinIO efterlod denne politik ingen låse og nægtede stadig at slette snapshots:

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

Standardværdien for `schedule-capture-environment` modarbejder opdelingen af hemmeligheder. Den er `RESTIC_*`, så alle RESTIC\_-variabler, der findes, når du kører `resticprofile schedule`, havner i den genererede systemd-unit som en `Environment=`\-linje, og resticprofile 0.33.1 skriver unit-filer med filrettighederne 0644. En eksporteret `RESTIC_PASSWORD` i den shell kan derefter læses af alle lokale konti, og `systemctl show` viser den for dem, selv hvis du strammer filens rettigheder. Kør `schedule` fra en ren shell, eller sæt `schedule-capture-environment: []` i den sektion, der indeholder tidsplanen.

### Kildestier, excludes og tags

Et `exclude`\-mønster uden skråstreg foran matcher en hel komponent i stien hvor som helst, så `node_modules` udelader alle mapper med det navn. En skråstreg foran forankrer mønstret i roden. `exclude-file` tager ét mønster pr. linje med `#`\-kommentarer, og en relativ sti slås op i forhold til den mappe, konfigurationsfilen ligger i. En sti, der står direkte i `source`, bliver altid gemt, men excludes filtrerer stadig indholdet: angiver du `/srv/app/node_modules` som kilde, mens `node_modules` er udeladt, indeholder snapshottet kun den tomme mappe. `exclude-caches` springer indholdet over i enhver mappe, der er markeret med en CACHEDIR.TAG-fil, og beholder selve tag-filen.

`tag` sætter en etiket på hvert snapshot, og den kan administrationsprofilen bruge. Kører du `resticprofile web1.backup --tag keep` før en risikabel opgradering, får snapshottet tagget `keep`, og vedligeholdelsespolitikkens `keep-tag` fjerner aldrig det snapshot.

### Databasedumpet

Dumpet ligger i `run-before` i sektionen `backup`. På profilens rodniveau ville det køre før hver restic-kommando, profilen kører, også `snapshots`. pg\_dump laver en konsistent eksport, selv mens databasen er i brug.

En hook, der slutter med en anden exitkode end 0, afbryder kørslen og udløser `run-after-fail`, som modtager `ERROR_MESSAGE`, `ERROR_EXIT_CODE` og `ERROR_STDERR`. Efter min mening er det den rigtige standard, for et snapshot, der mangler sin database, uden at nogen har bemærket det, er en fejl, du først opdager under en gendannelse. Oprydning hører til i `run-finally` frem for `run-after`, fordi `run-after` kun kører, når alt er lykkedes, og en nat, hvor kørslen fejler, ellers ville efterlade et ukrypteret dump på disken indtil næste vellykkede kørsel.

### Planlægning med systemd

`schedule` tager systemds kalendersyntaks, så `systemd-analyze calendar "*-*-* 01:30"` viser næste kørsel. Med `schedule-permission: system` skriver resticprofile `resticprofile-backup@profile-web1.service` og en tilhørende timer i /etc/systemd/system, og jobbet kører som root. Standardtimeren sætter `Persistent=true`, så en kørsel, der blev sprunget over, mens maskinen var slukket, starter, når timeren er aktiv igen efter opstart. Vil du ændre rettighedsniveauet senere, så fjern tidsplanen først, ret konfigurationen, og planlæg igen.

`lock` er resticprofiles egen låsefil, som forhindrer, at to kørsler af profilen overlapper. `schedule-lock-wait` er, hvor længe en planlagt kørsel venter på den lås og på restics repository-lås. Det betyder noget her, fordi `check`, `forget` og `prune` i restic 0.19.1 alle tager en eksklusiv lås, og administrationsmaskinen kører dem mod det samme repository. `schedule-log` sender output til en fil, som resticprofile skriver videre i, men aldrig roterer, så giv den en logrotate-regel, eller udelad nøglen, så lægger systemd output i journalen i stedet. `schedule-after-network-online` tilføjer `After=network-online.target`. Det styrer kun rækkefølgen. Unit-filen får ingen `Wants=`\-linje, så den venter kun på netværket, hvis noget andet på maskinen trækker det target ind.

Unit-filen kalder `resticprofile run-schedule`, som læser konfigurationen på ny hver gang. Ændringer i kilder, excludes eller hooks gælder fra næste kørsel. At ændre, hvornår et job kører, eller som hvem, kræver `resticprofile schedule` igen.

### Status og målinger

`status-file` gemmer et JSON-resumé af seneste backup, forget og check: om det lykkedes, tidspunkt, fejl og varighed. resticprofile gemmer resultatet af forget under nøglen `retention`, så det er det navn, du skal kigge efter i din overvågning. `prometheus-save-to-file` skriver målinger i Prometheus' tekstformat, kun for backup-kommandoen. Peg den på mappen til din textfile collector, og behold endelsen .prom, som node\_exporter forventer. `extended-status: true` tilføjer antal filer og bytes på bekostning af restics normale fremdriftsvisning. resticprofile opretter ingen af de to filers mapper, og derfor opretter opsætningen ovenfor dem begge.

## Retention kontra forget

Begge ender i `restic forget`. Forskellen er, hvornår det kører, og hvad det udvælger.

| Aspekt | Sektionen `retention` | Sektionen `forget` |
| --- | --- | --- |
| Hvornår den kører | Inde i `resticprofile backup`, før eller efter backuppen | Når du kører `resticprofile forget`, eller efter sin egen tidsplan |
| Slås til med | `after-backup: true` eller `before-backup: true`. I version 1 er ingen af dem standard, så keep-regler alene gør ingenting | Altid aktiv, når den kaldes |
| Efter en mislykket backup | `after-backup` springes over: den kører kun efter en vellykket backup | Uafhængig af backups |
| Hvilke snapshots | Tilføjer backuppens `source`\-liste som `--path`, medmindre du sætter `path` | Præcis de flag, du skriver |
| Planlægning | Forældet: planlæg `forget` i stedet | Understøttet |
| Sletterettigheder kræves på | Den server, der kører backuppen | Den maskine, der kører den |

Standardværdien for `path` er den lumske. restic tager kun de snapshots i betragtning, der indeholder alle de angivne stier, så når du tilføjer en mappe til `source`, holder retention op med at matche de snapshots, der blev taget før ændringen, og fjerner dem aldrig. Den sidste række er grunden til, at retention ikke kan ligge på en append-only-server.

## Administrationsmaskinens vedligeholdelsesprofil

```
# /etc/resticprofile/profiles.yaml on the admin host
version: "1"

# Shared rules only: no repository, no schedule, never run directly.
policy:
  forget:
    keep-within: "14d"
    keep-within-weekly: "3m"
    keep-within-monthly: "1y"
    keep-tag:
      - "keep"
    prune: true
  check:
    read-data-subset: "{{ .Now.Day }}/31"

web1:
  inherit: policy
  repository: "s3:https://objects.example.net/acme-web1-restic"
  password-file: "/etc/resticprofile/keys/web1.key"
  env-file:
    - "/etc/resticprofile/web1-admin.env"   # the key that CAN delete
  status-file: "/var/lib/resticprofile/web1.json"
  forget:
    schedule: "Sun 03:00"
    schedule-permission: system
    schedule-lock-wait: 2h
    schedule-log: "/var/log/resticprofile-web1-forget.log"
  check:
    schedule: "*-*-* 05:30"
    schedule-permission: system
    schedule-lock-wait: 2h
    schedule-log: "/var/log/resticprofile-web1-check.log"
```

Politikken beholder alle snapshots fra de seneste 14 dage, det nyeste i hver uge i tre måneder og det nyeste i hver måned i et år. I restics varigheder betyder `m` måneder. Valget af den almindelige `keep-within` er bevidst. restics dokumentation advarer om, at en angriber med append-only-adgang kan tilføje affaldssnapshots. En regel baseret på antal, som at beholde tre ugentlige snapshots, beholder så de falske og fjerner de rigtige. Dokumentationen anbefaler `keep-within` til netop denne opsætning, fordi den beholder alle snapshots i vinduet, også de rigtige. De inddelte former `keep-within-daily`, `-weekly` og `-monthly` beholder kun det nyeste snapshot i hver dag, uge eller måned, så et plantet snapshot, der er et par minutter nyere end hvert rigtigt, fortrænger det, præcis som ved en regel baseret på antal. Ud over 14 dage gælder den risiko for de ugentlige og månedlige regler, og derfor bør administrationsmaskinen se på uventede snapshots, før vinduet løber ud. restic måler vinduerne fra det nyeste snapshot og ignorerer snapshots dateret i fremtiden. `prune: true` tilføjer `--prune`, så restic kun kører prune, når forget har fjernet noget.

`read-data-subset` bruger skabelonen `.Now.Day`, så check den 23. henter og verificerer gruppe 23 af 31, omkring 1/31 af pakkefilerne. En måned med 31 dage læser hver gruppe én gang, mens kortere måneder springer de højeste grupper over indtil næste lange måned. En procentdel som `5%` er enklere, men restic gør opmærksom på, at tilfældige delmængder ikke garanterer fuld dækning. Uanset hvad koster det download-trafik hos lagerudbyderen at læse data.

Profilen `policy` indeholder kun reglerne, og hver servers profil arver fra den. Hold listeværdier ét sted, og kontrollér resultatet med `show`. I version 1 under 0.33.1 fletter resticprofile `source` og `exclude` ind i forælderens liste efter indeks, mens `tag` og `keep-tag` erstatter forælderens liste helt. En `source` med ét element i barnet erstatter altså kun forælderens første post.

## Kommandoer, du skal køre, før du stoler på det

```
# on the admin host, once, before the first backup
resticprofile web1.init

# on the server
resticprofile web1.show               # the profile as resticprofile resolved it
resticprofile --dry-run web1.backup   # print hooks and restic command, run nothing
resticprofile web1.backup             # one real run, end to end
resticprofile schedule --all          # install every schedule in the file
resticprofile status --all            # the installed systemd timers
systemctl list-timers 'resticprofile-*'

# on the admin host
resticprofile web1.forget --dry-run   # restic lists what the policy would remove
resticprofile web1.check              # today's slice of the data, by hand
resticprofile schedule --all
```

1.  **Sammenlign show med dry-run**: `show` udskriver den færdige profil med nedarvningen anvendt. `--dry-run` før `web1.backup` udskriver hver hook og restic-kommandolinjen og kører intet. Sammenlign de to, for `restic-arguments-filter`, som er slået til som standard, fjerner flag, restic ikke genkender. En fejlstavet `keep-within-daly` optræder derfor i det ene og forsvinder i det andet.
2.  **Lad restic bedømme politikken**: Flag efter kommandoen går videre til restic, så `web1.forget --dry-run` på administrationsmaskinen får restic til at liste, hvad den ville beholde og fjerne, uden at fjerne noget.
3.  **Planlæg alt som den samme bruger**: Kør `schedule --all` som root. Dokumentationen advarer mod at blande bruger- og systemtidsplaner i én kørsel.
4.  **Vid, hvilken status du læser**: `resticprofile status` viser de installerede timere og journallinjer på niveau warning eller højere fra den seneste måned. Med `schedule-log` sat viser en mislykket natlig kørsel sig kun dér som systemds linje "Failed with result 'exit-code'", uden årsagen. Statusfilen og loggen indeholder resultatet.
5.  **Gendan noget**: En kontrol uden fejl viser kun, at repositoryet er intakt. Om det indeholder det, du har brug for, finder du først ud af ved at gendanne. [Gendan til en testmaskine, og tag tid på det](/da/guides/backup-der-kan-gendannes/).

## På Windows

De samme nøgler virker. resticprofile planlægger via Opgaveplanlægning (Task Scheduler) på Windows 10 eller nyere. Installation af en `system`\-tidsplan kræver administratorrettigheder, som resticprofile selv beder om, mens `user` beder om kontoens adgangskode. `schedule-start-when-available`, tilføjet i 0.33.0, kører en backup, der blev sprunget over, mens maskinen var slukket, og `use-fs-snapshot: true` i backup-sektionen lader restic læse låste filer via VSS. Finder resticprofile ikke restic.exe, så angiv den fulde sti som `restic-binary` under `global`. Opdelingen i to profiler fungerer uændret. Skal du stadig vælge værktøj, så læs [restic kontra Borg](/da/guides/restic-vs-borg/) først.

## Ulemperne ved append-only-opdelingen, og hvordan Veeam står i sammenligning

Opdelingen beskytter historikken ved at holde én rettighed væk fra serveren. Det er adgangsstyring og gør ingen data uforanderlige. Omkostningerne bør vejes op mod et produkt, der er bygget op om uforanderlighed, som Veeam Backup & Replication 13.

-   **Administrationsnøglen kan stadig ødelægge alt.** Risikoen flytter til administrationsmaskinen og login til lagerkontoen. Den, der kompromitterer en af dem, kan slette hele repositoriet, og intet i dette design forhindrer det.
-   **En ekstra maskine, der skal køre og overvåges.** Opbevaringsregler, prune og check sker kun på administrationsmaskinen. Stopper den, udløber intet, bucketen bliver ved med at vokse, og ingen opdager det, medmindre dens kørsler overvåges lige så tæt som backupperne.
-   **Sletning er ikke det eneste angreb.** Objektlager har ingen separat rettighed til at overskrive, så serverens nøgle kan skrive hen over et eksisterende objekt, og på Backblaze B2 kan den skjule filer. Versionering bevarer originalerne, men at få dem tilbage er manuelt arbejde, version for version, og kun muligt, indtil oprydningsjobbet fjerner ikke-aktuelle versioner. Oprydningens tidsgrænse er dit vindue til at opdage det.
-   **Opbevaringsreglerne kan snydes.** Serveren kan tilføje snapshots, og plantede snapshots slår regler baseret på antal ud af spillet, som faldgruben nedenfor viser. Derfor anbefaler restics dokumentation `keep-within` til append-only-repositories.
-   **Serveren kan stadig læse alle backups.** Den har repositoriets adgangskode, så en ubuden gæst kan dekryptere alle tidligere og fremtidige snapshots. Opdelingen beskytter kun tilgængeligheden.
-   **Ingen konsol.** Tidsplaner, alarmer, rapportering og gendannelsestest skal du selv bygge og holde kørende.

Veeam løser det første og det tredje punkt på en anden måde. Et hærdet repository hos Veeam er en Linux-server, hvor backupfiler ifølge dokumentationen hverken kan flyttes, ændres eller slettes, men godt kan kopieres, i en uforanderlighedsperiode på 7 til 9.999 dage. Veeam bruger loginoplysningerne fra opsætningen én gang og gemmer dem ikke, så en kompromitteret backupserver kan ikke nå den. På objektlager sætter Veeam S3 Object Lock i compliance-tilstand på hvert objekt, den uploader, og styrer låsen pr. backupkæde. Det kan restic ikke. Den kører på en låst bucket, men sætter eller forlænger aldrig selv en lås, som [guiden om Object Lock](/da/guides/restic-b2-object-lock/) viser.

Veeams løsning har sine egne omkostninger:

-   **Mere infrastruktur.** En backupserver og derudover en dedikeret Linux-maskine med lokalt eller blokbaseret lager til det hærdede repository. NFS og SMB er ikke tilladt, et repository kan ikke deles mellem flere backupservere, og Veeam Agent for Linux må ikke være installeret på den.
-   **Root på repository-værten er det svage punkt.** Uforanderligheden er filsystemets immutable-attribut. På vores ext4-testsystem fjernede `chattr -i` som root attributten, og filen kunne derefter slettes. Veeams eget appliance-image tillader ikke SSH på et hærdet repository og lader dig ikke slå multifaktorgodkendelse fra, medmindre Security Officer-konti er slået til. Et håndbygget repository kræver samme disciplin.
-   **Mere lagerplads.** Et hærdet repository accepterer kun fremadrettede inkrementelle backups med periodiske fulde backups, og en uforanderlig fil kan først flettes eller slettes, når perioden er udløbet. På objektlager lægger Veeam en blokgenerering på 10 dage oven i låsens udløb, og dokumentationen advarer om, at en uforanderlighedsperiode, der er længere end jobbets opbevaringstid, giver ekstra omkostninger.
-   **Bucketen tilhører Veeam.** Den skal have Object Lock og versionering fra oprettelsen, ingen standardopbevaring og ingen livscyklusregler, som Veeam skriver ikke understøttes og kan få backup og gendannelse til at fejle.
-   **En licens ud over ti workloads.** Community Edition er gratis til op til 10 workloads. Derudover skal du have en betalt licens, der tælles i instanser pr. beskyttet workload. Veeams licensside nævner også, at den Linux-baserede Veeam Software Appliance kun understøtter gendannelse i Community Edition.

Til en eller få Linux-servere på objektlager mener vi, at restic-opdelingen er lille, billig og nem at scripte, og dens svage punkter er kendte og kan testes. Har du brug for backups, som ingen, heller ikke du selv, kan slette i en fast periode, eller kører du allerede VMware eller Hyper-V, giver Veeams hærdede repository eller repository med Object Lock dig det, og det gør dette design ikke. Midt imellem ligger restic på en bucket med Object Lock, med de begrænsninger, der er beskrevet i den guide.

## Faldgruber

-   **En nøgle, der ikke kan slette, efterlader låse.** Helt uden sletterettighed skrev hver serverkommando "Remove(<lock/...>) failed: Access Denied" og sluttede stadig med exitkode 0. Administrationsmaskinens `check` fejlede derefter med "repository is already locked" og exitkode 11. `schedule-lock-wait` venter kun. Da låsen var ældre end `restic-stale-lock-age`, som er 1h som standard, gav resticprofile op og foreslog `force-inactive-lock`. Tillad enten sletninger under `locks/` som vist ovenfor, eller sæt `force-inactive-lock: true` på administrationsprofilen, som så kørte `restic unlock` og lod check gå igennem.
-   **En forget på serveren blokerer alle senere backups.** Da vi kørte `web1.forget` med servernøglen, fik den "Access Denied" og sluttede med exitkode 3, men efterlod en eksklusiv lås, som serveren ikke kunne fjerne, og næste backup fejlede med exitkode 11, indtil administrationsmaskinen kørte `unlock`. Hold forget, prune og unlock på administrationsmaskinen.
-   **Keep-within-regler pr. dag kan snydes.** I et testrepository med 84 natlige snapshots efterlod ét plantet snapshot 30 minutter efter hvert rigtigt kun ét rigtigt snapshot under `keep-within-daily: 14d` med de ugentlige og månedlige regler ovenfor. Med `keep-within: 14d` i stedet overlevede alle 14 rigtige snapshots fra de seneste to uger ved siden af de falske.
-   **En ændret kildeliste efterlader gamle snapshots.** restic forget grupperer snapshots efter vært og stiliste og måler hvert vindue fra gruppens nyeste snapshot. I et repository, hvis kildeliste blev ændret i juni 2025, beholdt denne politik, kørt den 23. september 2026, stadig 20 snapshots med den gamle liste og ville beholde dem på ubestemt tid. Rummer repositoryet én server, så tilføj `group-by: "host"` i sektionen `forget`. Det samlede begge lister i testen.
-   **En manglende mappe giver kun en advarsel.** Før textfile-mappen fandtes, loggede hver backup "saving prometheus file ... no such file or directory" og sluttede med exitkode 0, så målingerne aldrig dukkede op, uden at noget meldte fejl. En `status-file` i en manglende mappe opfører sig på samme måde. Kontrollér, at begge filer findes efter første kørsel.
-   **Opfangede variabler er synlige for alle brugere.** Med `RESTIC_PASSWORD` eksporteret skrev `schedule` den ind i unit-filen (filrettigheder 0644), og `systemctl show -p Environment` viste den for kontoen nobody. En ny kørsel af `schedule` fra en ren shell skrev unit-filen om uden den, og `schedule-capture-environment: []` stoppede opfangningen helt.

**Sådan blev det testet.** Den 23. september 2026 byggede vi resticprofile fra tagget v0.33.1 med Go 1.26.8 og kørte det med 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, med én nøgle uden `s3:DeleteObject` og én med fulde rettigheder. Serveren og administrationsmaskinen var to Debian 13-containere med systemd 257 som PID 1 og PostgreSQL 17.11 til dump-hooken. Vi kørte begge eksempler, som de står, bortset fra endpoint og nøgler, startede unit-filerne manuelt og kontrollerede Persistent= ved at stoppe og genstarte en container, ikke ved en rigtig genstart. Ikke testet: en kommerciel S3-udbyder, Windows og Opgaveplanlægning, hvor vi bygger på dokumentationen, node\_exporter, der læser .prom-filen, og rotationen af check over en hel måned, hvor vi kun renderede dag 23. Afsnittet om ulemper bygger på disse test og de linkede guides. Sammenligningen med Veeam bygger på dokumentationen til Veeam version 13 og er ikke testet, bortset fra at vi den 26. september 2026 fjernede immutable-attributten som root med `chattr -i` (e2fsprogs 1.47.0, ext4) og derefter slettede filen.

## Kilder

1.  [resticprofile releases (v0.33.1, 15. april 2026)](https://github.com/creativeprojects/resticprofile/releases), creativeprojects på GitHub
2.  [Getting started: file formats](https://creativeprojects.github.io/resticprofile/configuration/getting_started/), resticprofile-dokumentationen
3.  [Configuration v2 proposal](https://creativeprojects.github.io/resticprofile/configuration/v2/), resticprofile-dokumentationen
4.  [Profile reference](https://creativeprojects.github.io/resticprofile/reference/profile/) og [retention section reference](https://creativeprojects.github.io/resticprofile/reference/profile/retention/), resticprofile-dokumentationen
5.  [Schedule configuration reference (capture-environment)](https://creativeprojects.github.io/resticprofile/reference/nested/scheduleconfig/) og [global section reference (restic-arguments-filter, restic-binary)](https://creativeprojects.github.io/resticprofile/reference/global/), resticprofile-dokumentationen
6.  [Schedules: retention scheduling deprecated](https://creativeprojects.github.io/resticprofile/schedules/), resticprofile-dokumentationen
7.  [Schedule configuration](https://creativeprojects.github.io/resticprofile/schedules/configuration/), [systemd](https://creativeprojects.github.io/resticprofile/schedules/systemd/) og [schedule commands](https://creativeprojects.github.io/resticprofile/schedules/commands/), resticprofile-dokumentationen
8.  [Command hooks](https://creativeprojects.github.io/resticprofile/configuration/run_hooks/), [variables](https://creativeprojects.github.io/resticprofile/configuration/variables/) og [inheritance](https://creativeprojects.github.io/resticprofile/configuration/inheritance/), resticprofile-dokumentationen
9.  [Status file](https://creativeprojects.github.io/resticprofile/monitoring/status/) og [Prometheus](https://creativeprojects.github.io/resticprofile/monitoring/prometheus/), resticprofile-dokumentationen
10.  [Windows Task Scheduler](https://creativeprojects.github.io/resticprofile/schedules/task_scheduler/), resticprofile-dokumentationen
11.  [systemd/generate.go at v0.33.1 (unit file mode)](https://github.com/creativeprojects/resticprofile/blob/v0.33.1/systemd/generate.go), resticprofiles kildekode
12.  [restic releases (0.19.1, 5. juli 2026)](https://github.com/restic/restic/releases), restic på GitHub
13.  [Removing backup snapshots, including security considerations in append-only mode](https://restic.readthedocs.io/en/stable/060_forget.html), restic-dokumentationen
14.  [Working with repositories: checking integrity](https://restic.readthedocs.io/en/stable/045_working_with_repos.html), restic-dokumentationen
15.  [Backing up: excluding files and VSS](https://restic.readthedocs.io/en/stable/040_backup.html), restic-dokumentationen
16.  [Preparing a new repository: S3-compatible storage](https://restic.readthedocs.io/en/stable/030_preparing_a_new_repo.html), restic-dokumentationen
17.  [cmd\_check.go at v0.19.1 (exclusive lock)](https://github.com/restic/restic/blob/v0.19.1/cmd/restic/cmd_check.go), restics kildekode
18.  [repo/repo.go at v0.14.0 (append-only mode still allows deleting locks)](https://github.com/restic/rest-server/blob/v0.14.0/repo/repo.go), rest-servers kildekode
19.  [pg\_dump](https://www.postgresql.org/docs/current/app-pgdump.html), PostgreSQL 18-dokumentationen
20.  [systemd.timer(5): Persistent=](https://man7.org/linux/man-pages/man5/systemd.timer.5.html) og [systemd.exec(5): StandardOutput=](https://man7.org/linux/man-pages/man5/systemd.exec.5.html), man7.org
21.  [WriteToTextfile](https://pkg.go.dev/github.com/prometheus/client_golang/prometheus#WriteToTextfile), dokumentationen til Prometheus' Go-klient
22.  [Hardened Repository](https://helpcenter.veeam.com/docs/vbr/userguide/hardened_repository.html), [Requirements and Limitations](https://helpcenter.veeam.com/docs/vbr/userguide/hardened_repository_limitations.html) og [How Immutability Works](https://helpcenter.veeam.com/docs/vbr/userguide/hardened_repository_immutability.html), Veeam Backup & Replication 13 User Guide
23.  [How Immutability Works (objektlager, blokgenerering)](https://helpcenter.veeam.com/docs/vbr/userguide/hiw_immutability_os.html) og [Considerations and Limitations](https://helpcenter.veeam.com/docs/vbr/userguide/os_immutability_limitations.html), Veeam Backup & Replication 13 User Guide
24.  [Licensing](https://helpcenter.veeam.com/docs/vbr/userguide/licensing.html), Veeam Backup & Replication 13 User Guide, og [Downloads (Community Edition, op til 10 workloads)](https://www.veeam.com/products/downloads.html), Veeam
25.  [chattr(1): the immutable attribute](https://man7.org/linux/man-pages/man1/chattr.1.html), man7.org

## Spørgsmål

### Hvad er forskellen på retention og forget i resticprofile?

Begge kører restic forget. Sektionen retention kører den inde i backup-kommandoen, før eller efter backuppen, og kun når before-backup eller after-backup er sat. I konfigurationsversion 1 er ingen af dem slået til som standard. Den giver også backuppens kildeliste med som --path, medmindre du selv angiver noget andet. Sektionen forget konfigurerer den selvstændige forget-kommando og kan have sin egen tidsplan. At planlægge retention direkte er forældet til fordel for forget.

### Hvordan planlægger jeg resticprofile check?

Tilføj schedule, schedule-permission og schedule-lock-wait i profilens check-sektion, og kør derefter resticprofile schedule. Sæt read-data-subset i samme sektion, så hver kørsel henter og verificerer en del af pakkefilerne frem for kun repositoryets struktur. I restic 0.19.1 tager check en eksklusiv lås, så kør den uden for backupvinduet, og giv backuppen en schedule-lock-wait, der er lang nok til at vente den ud.

### Hvordan planlægger resticprofile backups på Linux?

Når systemd er til stede, skriver resticprofile schedule en service og en timer med navnet resticprofile-backup@profile-NAME og aktiverer dem. Nøglen schedule bruger systemds kalendersyntaks, så systemd-analyze calendar kan teste den. Med schedule-permission: system havner unit-filerne i /etc/systemd/system og kører som root. Servicen kalder resticprofile run-schedule, som læser konfigurationen igen ved hver kørsel. Du skal kun køre resticprofile schedule igen, når du ændrer, hvornår eller som hvem et job kører.

### Virker resticprofile på Windows?

Ja. Den planlægger via Windows Opgaveplanlægning (Task Scheduler) på Windows 10 eller nyere og bruger de samme konfigurationsnøgler. At installere en tidsplan med schedule-permission: system kræver en prompt med administratorrettigheder, og user beder om kontoens adgangskode. Siden version 0.33.0 kører schedule-start-when-available en backup, der blev sprunget over, mens maskinen var slukket. Tilføj use-fs-snapshot: true i backup-sektionen, så restic læser låste filer via VSS.

### Hvordan virker exclude-mønstre i resticprofile?

resticprofile giver exclude og exclude-file videre til restic, så restics regler for mønstre gælder. Et mønster uden skråstreg foran matcher en hel komponent i stien hvor som helst, så node\_modules udelader alle mapper med det navn, mens en skråstreg foran forankrer mønstret i roden. En relativ sti i exclude-file slås op i forhold til den mappe, konfigurationsfilen ligger i. En sti, der står direkte i source, bliver altid gemt, men excludes filtrerer stadig indholdet, så en kildemappe, hvis eget navn matcher en exclude, bliver gemt tom.

### Er en append-only-nøgle til restic lige så sikker som uforanderlige backups i Veeam?

Nej. En append-only-nøgle er adgangsstyring. Serveren, der tages backup af, kan ikke slette sin historik, men det kan den, der har administrationsnøglen eller adgang til lagerkontoen, og serverens nøgle kan stadig overskrive objekter, så gendannelse afhænger af versionering på bucketen. Veeams hærdede repositories og repositories med Object Lock gør backupfiler umulige at slette i en fastsat periode, også for en kompromitteret backupserver. restic-opdelingen er billigere og enklere, men den gør ikke backupperne uforanderlige.

**Vil du have resticprofile passet for dig?**

Alle servere, Wardio driver, tager backup med resticprofile til lager i et andet fejldomæne, med planlagt integritetskontrol. [Se priserne](/da/priser/).

[Gratis servergennemgang](/da/kontakt/)