Zum Inhalt

Cloud-Native unveränderliche Backups: Restic, S3 Object Lock (WORM), Rabin-Fingerprinting & rclone-Backends

Erstellt: 06.11.2026 Aktualisiert: 06.11.2026

Management Summary: Während BorgBackup primär für POSIX-Server mit SSH-Zugang konzipiert ist, erfordern moderne Multi-Cloud- und Objektspeicher-Architekturen ein statisches Backup-Binary, das nativ mit AWS S3 / MinIO / Cloudflare R2 / Backblaze B2, SFTP, rclone und rest-server ohne serverseitigen Daemon kommuniziert. Dieser Leitfaden beschreibt das Produktiv-Deployment von Restic, inklusive Rabin-Karp-Polynom-Chunking, AES-256-CTR + Poly1305-AES-Verschlüsselung, S3 Object Lock (COMPLIANCE / GOVERNANCE WORM) und deklarativer Steuerung via resticprofile.

  • Daemonloser Objektspeicher-Zugriff

    Überträgt deduplizierte, verschlüsselte Packfiles direkt auf S3-kompatible Buckets (MinIO, Wasabi, B2, R2), SFTP oder über 40 Cloud-Anbieter via rclone:.

  • S3 Object Lock (WORM) Unveränderlichkeit

    Kombiniert Restic mit S3 Object Lock oder rest-server --append-only für revisionssicheren Write-Once-Read-Many-Schutz vor Ransomware.

  • Rabin-Polynom-Chunking

    Teilt Dateien anhand ihres Inhalts mit gleitenden Rabin-Fingerprints (512 KiB bis 8 MiB) in kompakte pack-Blobs auf.

  • Deklaratives resticprofile-Management

    Verwaltet Multi-Repository-Profile, native Systemd-Timer, ionice/nice-Ressourcenlimits und Prometheus-Metriken strukturiert in YAML.

1. Architektur: Rabin-Fingerprinting, Packfiles & Multi-Backend-Speicher

Im Gegensatz zu klassischen Archivierern implementiert Restic ein inhaltsadressiertes Speicherformat (CAS). Dateien werden über ein irreduzibles Grad-53-Polynom in $\text{GF}(2)[x]$ zerlegt (Rabin-Fingerprinting). Einzelne verschlüsselte Blobs werden zu ~16-MiB-Packfiles gebündelt, um übermäßige API-Anfragen an Objektspeicher zu vermeiden:

%%{init: {'flowchart': {'wrappingWidth': 600, 'subGraphTitleMargin': {'top': 15, 'bottom': 15}}}}%%
flowchart TB
    subgraph ClientNode["Produktiv-Node (Restic Go-Binary)"]
        FS["Quell-Dateisystem<br/>+ Stdin DB Streams"]
        Rabin["Rabin Polynom-Chunker<br/>SHA-256 Inhaltsadressierung"]
        Packer["zstd Kompression +<br/>AES-256-CTR / Poly1305 Pack"]
    end

    subgraph StorageBackends["Zero-Knowledge Remote-Ziele"]
        S3WORM[("S3 / MinIO / B2 Bucket<br/>Object Lock WORM aktiv")]
        RestSrv[("Self-Hosted rest-server<br/>--append-only + Prometheus")]
    end

    FS --> Rabin
    Rabin -->|"Deduplizierte Blobs"| Packer
    Packer -->|"HTTPS PUT ~16MiB Packs"| S3WORM
    Packer -->|"HTTP/2 TLS mTLS"| RestSrv

Entscheidungsmatrix: Restic vs. BorgBackup

Kriterium Restic (Statisches Go-Binary) BorgBackup (Python + C-Erweiterungen)
Server-Voraussetzung Keine (Einfacher Speicher: S3, B2, SFTP, HTTP, rclone) Erfordert installiertes borg-Binary auf dem SSH-Ziel für schnelle Deduplizierung
Geteiltes Multi-Host-Repo Nativ (Mehrere Hosts können parallel in denselben S3-Bucket sichern und Deduplizierung teilen) Einzel-Host-Lock pro Repository empfohlen
Chunking-Algorithmus Rabin-Karp-Polynom über $\text{GF}(2^{53})$ Buzhash zyklischer rollender Hash
Krypto-Primitiv AES-256-CTR + Poly1305-AES MAC (scrypt KDF) AES-256-CTR + HMAC-SHA256 oder AES-256-OCB / BLAKE2b

2. Initialisierung & Datenbank-Streaming im RAM

Hinterlegen Sie Zugangsdaten in einer geschützten Datei /etc/restic/env.conf (chmod 0600):

/etc/restic/env.conf
export RESTIC_REPOSITORY="s3:https://s3.eu-central-003.backblazeb2.com/nejat-sovereign-backups/prod-cluster"
export RESTIC_PASSWORD_FILE="/etc/restic/repo.pw"
export AWS_ACCESS_KEY_ID="003a1b2c3d4e5f0000000001"
export AWS_SECRET_ACCESS_KEY="K003..."
export RESTIC_COMPRESSION="max"

Initialisieren Sie das Repository und sichern Sie PostgreSQL-Dumps direkt über die Standardeingabe:

Restic initialisieren & PostgreSQL via stdin sichern
source /etc/restic/env.conf

# 1. Inhaltsadressiertes Repository initialisieren
restic init

# 2. pg_dumpall ohne temporäre Festplattendatei direkt in Restic streamen
sudo -u postgres pg_dumpall --clean \
  | restic backup --stdin --stdin-filename postgresql_cluster.sql --tag database,postgres

# 3. Dateisystem-Pfade sichern und Cache-Verzeichnisse ausschließen
restic backup /etc /opt /var/vmail \
  --one-file-system \
  --exclude-caches \
  --exclude="/opt/*/logs" \
  --tag filesystem

3. Automatisierung via resticprofile

Mit resticprofile lassen sich Backup-Aufgaben, Aufbewahrungsfristen und Systemd-Timer deklarativ verwalten:

/etc/resticprofile/profiles.yaml
version: "1"

global:
  ionice: true
  ionice-class: 2
  ionice-level: 6
  nice: 15
  priority: low
  prometheus-save-to-file: "/var/lib/node_exporter/textfile_collector/restic.prom"

default:
  repository: "s3:https://s3.eu-central-003.backblazeb2.com/nejat-sovereign-backups/prod-cluster"
  password-file: "/etc/restic/repo.pw"
  env-file: "/etc/restic/s3.env"
  compression: "auto"
  lock: "/run/resticprofile-default.lock"

  backup:
    source:
      - "/etc"
      - "/opt"
      - "/var/vmail"
    exclude-caches: true
    one-file-system: true
    schedule: "*-*-* 02:30:00"
    schedule-permission: system
    check-before: false
    run-before:
      - "docker exec postgres-db pg_dumpall -U postgres > /opt/db_backups/pg_cluster.sql"
    run-after:
      - "shred -u /opt/db_backups/pg_cluster.sql"

  retention:
    before-backup: false
    after-backup: true
    keep-daily: 14
    keep-weekly: 8
    keep-monthly: 12
    keep-yearly: 3
    prune: true

  check:
    schedule: "Sun *-*-* 04:00:00"
    read-data-subset: "10%"

Systemd-Timer mit einem Befehl aktivieren:

Systemd-Timer über resticprofile registrieren
sudo resticprofile schedule --all
sudo resticprofile status

4. Selbst gehostetes Ziel: rest-server im Append-Only-Modus

Betreiben Sie auf einem lokalen NAS oder Bare-Metal-Server Restic's offiziellen HTTP/2-Backend-Dienst (rest-server) mit aktivierter Append-Only-Absicherung:

/opt/rest-server/compose.yaml
services:
  rest-server:
    image: restic/rest-server:latest
    container_name: restic-rest-server
    restart: unless-stopped
    ports:
      - "127.0.0.1:8000:8000/tcp"
    environment:
      OPTIONS: "--append-only --private-repos --prometheus --no-auth"
    volumes:
      - /mnt/zfs_vault/restic:/data:Z

Sicheres Pruning im --append-only-Modus

Ist --append-only aktiv (oder der S3-IAM-Schlüssel auf PutObject/GetObject ohne DeleteObject beschränkt), kann der Client neue Snapshots schreiben, aber keine alten löschen. Das regelmäßige Bereinigen (restic forget --prune) erfolgt über einen isolierten Cronjob direkt auf dem Speicherserver mit separaten Administratorrechten.

5. Verifikation, Bit-Rot-Prüfung & Diff-Analyse

Snapshots vergleichen & Integrität stichprobenartig prüfen
source /etc/restic/env.conf

# 1. Snapshots gruppiert auflisten
restic snapshots

# 2. Geänderte Dateien und Byte-Delta zwischen den letzten zwei Snapshots vergleichen
restic diff $(restic snapshots --json | jq -r '.[-2].short_id') $(restic snapshots --json | jq -r '.[-1].short_id')

# 3. Repository-Index prüfen und 10 % der Datenblöcke zur Bit-Rot-Erkennung herunterladen und verifizieren
restic check --read-data-subset=10%