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

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

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-runshow 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 politikkenFlag 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 brugerKør schedule --all som root. Dokumentationen advarer mod at blande bruger- og systemtidsplaner i én kørsel.
4. Vid, hvilken status du læserresticprofile 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 nogetEn 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.

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 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 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), creativeprojects på GitHub
2. Getting started: file formats, resticprofile-dokumentationen
3. Configuration v2 proposal, resticprofile-dokumentationen
4. Profile reference og retention section reference, resticprofile-dokumentationen
5. Schedule configuration reference (capture-environment) og global section reference (restic-arguments-filter, restic-binary), resticprofile-dokumentationen
6. Schedules: retention scheduling deprecated, resticprofile-dokumentationen
7. Schedule configuration, systemd og schedule commands, resticprofile-dokumentationen
8. Command hooks, variables og inheritance, resticprofile-dokumentationen
9. Status file og Prometheus, resticprofile-dokumentationen
10. Windows Task Scheduler, resticprofile-dokumentationen
11. systemd/generate.go at v0.33.1 (unit file mode), resticprofiles kildekode
12. restic releases (0.19.1, 5. juli 2026), restic på GitHub
13. Removing backup snapshots, including security considerations in append-only mode, restic-dokumentationen
14. Working with repositories: checking integrity, restic-dokumentationen
15. Backing up: excluding files and VSS, restic-dokumentationen
16. Preparing a new repository: S3-compatible storage, restic-dokumentationen
17. cmd_check.go at v0.19.1 (exclusive lock), restics kildekode
18. repo/repo.go at v0.14.0 (append-only mode still allows deleting locks), rest-servers kildekode
19. pg_dump, PostgreSQL 18-dokumentationen
20. systemd.timer(5): Persistent= og systemd.exec(5): StandardOutput=, man7.org
21. WriteToTextfile, dokumentationen til Prometheus' Go-klient
22. Hardened Repository, Requirements and Limitations og How Immutability Works, Veeam Backup & Replication 13 User Guide
23. How Immutability Works (objektlager, blokgenerering) og Considerations and Limitations, Veeam Backup & Replication 13 User Guide
24. Licensing, Veeam Backup & Replication 13 User Guide, og Downloads (Community Edition, op til 10 workloads), Veeam
25. chattr(1): the immutable attribute, man7.org