Verschlüsselte Off-Site-Backups: 3-2-1 auf Ihrem eigenen Offshore-VPS

Ein Snapshot ist kein Backup

Der Snapshot in Ihrem Panel ist eine wirklich nützliche Sache, und Sie sollten vor jeder riskanten Änderung einen anlegen. Er ist aber trotzdem kein Backup, und der Unterschied ist keine Pedanterie — er ist die vollständige Liste der Situationen, die Sie eigentlich überstehen wollen. Ein Snapshot liegt auf demselben Host, im selben Konto, hinter denselben Zugangsdaten wie die Maschine, die er schützt. Er beantwortet genau eine Frage gut: Wie mache ich die letzten zwanzig Minuten rückgängig? Alle anderen Fragen beantwortet er nicht. Ist das Konto weg, ist der Snapshot mit ihm weg. Ist die Region nicht erreichbar, ist es der Rollback auch nicht. Erreicht ein Eindringling das Panel, erreicht er auch die Snapshots. Und waren die Daten bereits beschädigt, als der Snapshot gemacht wurde, haben Sie die Beschädigung mit bewundernswerter Treue bewahrt.

Dasselbe gilt für die zwei Dinge, die am häufigsten mit Backups verwechselt werden. RAID ist kein Backup: Es schützt davor, dass eine Festplatte stirbt, und es repliziert rm -rf mit voller Geschwindigkeit auf den Spiegel. Replikation ist aus demselben Grund kein Backup — sie ist darauf ausgelegt, die zweite Kopie so schnell wie möglich identisch zur ersten zu machen, auch dann, wenn die erste Kopie gerade eben zerstört wurde. Bei einem no-KYC-Anbieter ist der Konto-Zweig dieser Liste schärfer als anderswo: Die Registrierung ist ein Benutzername, ein Passwort und acht Wiederherstellungscodes, ganz ohne E-Mail oder Dokument irgendwo im Ablauf, es gibt also keine Support-Leiter zu erklimmen, wenn Sie sie verlieren. Das ist das Produkt, das wie vorgesehen funktioniert. Es bedeutet auch, dass die Kopie, die wirklich zählt, die ist, die nicht über die Zugangsdaten erreichbar ist, die Sie vielleicht verlieren.

3-2-1, neu geschrieben für einen Server, den niemand identifizieren kann

Die alte Regel gilt weiterhin: drei Kopien von allem, was Ihnen wichtig ist, auf zwei verschiedenen Systemen, eine davon Off-Site. Die moderne Erweiterung, die man als 3-2-1-1-0 schreibt, fügt die zwei Klauseln hinzu, die 2026 am meisten zählen — eine Kopie, die unveränderlich oder offline ist, und null Fehler bei der Verifizierung. Auf einen einzelnen Server übertragen heißt das: Kopie eins sind die Live-Daten; Kopie zwei ist der anbieterseitige Snapshot oder das Add-on für tägliche verschlüsselte Backups, das den gewöhnlichen Fehler um zwei Uhr morgens ohne jeden Aufwand Ihrerseits abfängt; Kopie drei ist ein verschlüsseltes Repository auf einer zweiten Maschine, in einer anderen Region, über die die erste Maschine keinerlei Löschbefugnis hat. Nur die dritte Kopie übersteht den Verlust des Kontos der ersten Maschine, und nur die dritte Kopie gehört Ihnen in dem Sinn, dass niemand sonst gezwungen werden kann, sie herauszugeben.

Seien Sie sich bewusst, was „Off-Site“ wirklich bedeutet. Ein weiteres Rack im selben Gebäude ist in keinem relevanten Sinne Off-Site, und eine andere Region unter demselben Recht ist nur die halbe Miete — ein einzelnes rechtliches Instrument, das eine Maschine erreicht, sollte nicht automatisch auch die andere erreichen. Bei 6 Regionen zur Auswahl ist das eine Entscheidung, die Sie einmal beim Deploy treffen und nie wieder anfassen. Es lohnt sich aber, es unumwunden zu sagen: Zwei Server sind hier immer noch zwei Server bei einem Anbieter, was ein korreliertes Risiko bleibt, egal wie gut die Isolation ist. Wenn Ihr Bedrohungsmodell tatsächlich den Verlust von uns einschließt, gehört die dritte Kopie an einen ganz anderen Ort — eine Maschine zu Hause, das Rack eines Freundes, ein anderer Anbieter auf einem anderen Kontinent. Alles in diesem Guide funktioniert identisch, egal wo das Ziel lebt; das Einzige, was sich ändert, ist die Adresse in einer einzigen Umgebungsvariable.

Verschlüsseln, bevor die Daten die Maschine verlassen

Das Ziel sollte ein Ort sein, der Bytes speichert, die es nicht lesen kann. Das ist keine Richtlinie, die Sie von einem Anbieter akzeptieren, es ist eine Eigenschaft, die Sie selbst bauen: Die Daten werden auf der Quelle in Chunks zerlegt, komprimiert, verschlüsselt und authentifiziert, und was über die Leitung geht, ist bereits undurchsichtig. Borgs repokey- und keyfile-Modi verschlüsseln jeden Chunk mit AES-256 im Counter-Modus und authentifizieren ihn, und die -blake2-Varianten tauschen HMAC-SHA256 gegen BLAKE2b, was auf modernen 64-Bit-CPUs messbar schneller ist. Dateiinhalte, Dateinamen und das Archiv-Manifest, das sie auflistet, sind alle verschlüsselt; das Ziel enthält nur nummerierte Segmentdateien und einen Index, den es nicht interpretieren kann. restic bietet dieselbe Grundstruktur mit anderer Technik im Hintergrund. So oder so ist das richtige mentale Modell: Sie mieten Festplattenspeicher, kein Vertrauen.

Zwei ehrliche Einschränkungen. Erstens, was trotzdem durchsickert: Wer auch immer die Zielfestplatte in der Hand hält, sieht, wie viele Daten ankommen und wann sie ankommen. Repository-Größe und Schreibzeitpunkt sind sichtbar, selbst wenn der Inhalt es nicht ist — für die meisten Menschen irrelevant, für einige wenige nicht. Zweitens: Verschlüsselung im Ruhezustand auf dem Ziel — LUKS auf der Backup-Box — schützt davor, dass die Festplatte das Gebäude verlässt, nicht vor der laufenden Maschine, und ergänzt clientseitige Verschlüsselung also, statt sie zu ersetzen. Und dann der Teil, der Leute ruiniert: Bei repokey lebt das Schlüsselmaterial innerhalb des Repositorys, verpackt durch Ihre Passphrase, sodass der Verlust des Repositorys auch den Schlüssel verliert; bei keyfile lebt es nur auf der Quelle, sodass der Verlust der Quelle jedes Archiv verliert, das Sie je erstellt haben. Keins von beiden ist sicher, bevor Sie den Schlüssel exportiert und den Export irgendwo abgelegt haben, das keine der beiden Maschinen ist. Erledigen Sie das in Schritt drei, nicht „später“.

Borg, restic, rclone: eins wählen und wissen, warum

Zwei Werkzeuge sind hier richtige Antworten, und die Wahl hängt wirklich vom Ziel ab. Borg macht Deduplizierung auf Chunk-Ebene, Kompression und authentifizierte Verschlüsselung, und — der Grund, warum es das durchgearbeitete Beispiel weiter unten ist — es bringt einen echten serverseitigen Append-Only-Modus mit, den Sie über einfaches SSH kostenlos bekommen, ganz ohne Daemon zum Betreiben und ohne zusätzlichen Port zum Öffnen. Es braucht borg installiert auf beiden Seiten und spricht sein eigenes Protokoll. restic bietet dieselben Garantien und ist dabei Backend-unabhängig: SFTP, S3-kompatibler Objektspeicher, Backblaze B2, oder sein eigener rest-server. Auf einem reinen SFTP-Ziel muss nichts installiert werden, was praktisch ist, aber Append-Only hängt dann von rest-server --append-only oder einer Bucket-Policy ab statt von einer SSH-Beschränkung. Faustregel: Borg, wenn das Ziel ein Server ist, den Sie kontrollieren, restic, wenn es Objektspeicher ist oder wenn Sie ein Werkzeug für viele verschiedene Backends wollen.

Was Sie nicht verwenden sollten, weil es der häufigste Weg ist, wie das hier schiefgeht. rclone ist ein Synchronisationswerkzeug. Sein crypt-Remote gibt Ihnen zwar clientseitige Verschlüsselung, aber ein Sync pflanzt Löschungen fort — die Datei, die Sie um 03:00 Uhr verloren haben, wird um 03:15 Uhr gewissenhaft auch vom Ziel entfernt, genau das Versagen, das Sie eigentlich überleben wollten. Es ist hervorragend geeignet, um ein fertiges Borg- oder restic-Repository an einen dritten Ort zu schieben; ein Backup ist es nicht. Derselbe Einwand gilt für ein blankes rsync --delete in einem Cronjob, das ein Spiegel ist, der sich als Backup verkleidet hat. tar | gpg auf einen entfernten Pfad ist ein echtes Backup, aber ohne Deduplizierung, ohne Aufbewahrungslogik, und mit einer Wiederherstellung, die bedeutet, eine ganze Kette von Inkrementen durchzugehen, um eine einzige Datei zurückzubekommen. Verwenden Sie die Werkzeuge, die dafür entworfen wurden; sie liegen für jede in diesem Guide erwähnte Distribution fertig als Paket vor.

Append-Only, sonst löscht der Eindringling auch Ihre Backups

Hier ist das Szenario, das ein Backup-System von einem Backup-Skript unterscheidet. Jemand bekommt root auf Ihrer Produktionsbox — über die Anwendung, eine Abhängigkeit, einen geleakten Schlüssel, wie spielt keine Rolle. Das Erste, was kompetente Ransomware tut, und das Erste, was ein kompetenter Mensch tut, ist, nach den Backups zu suchen, denn ein Opfer mit funktionierenden Backups zahlt nicht und gerät nicht in Panik. Ihr nächtlicher Job läuft unbeaufsichtigt, seine Zugangsdaten liegen also zwangsläufig auf genau dieser Maschine. Kann der Job Archive löschen, kann der Eindringling Archive löschen, und Sie erfahren es genau in dem Moment, in dem Sie sie brauchen. Das ist kein hypothetischer Ausfallmodus; es ist der normale.

Die Lösung ist klein, und sie ist die wichtigste Zeile in diesem Guide. Binden Sie auf dem Ziel den automatisierten Schlüssel an einen einzigen Befehl in authorized_keys: command="borg serve --append-only --restrict-to-path /srv/borg",restrict. Dieser Schlüssel kann jetzt genau eine Sache tun — Daten zu einem Repository unter einem Pfad hinzufügen. Er kann keine Shell bekommen, keinen Port weiterleiten, Ihr Dateisystem nicht auflisten und kein einziges Archiv entfernen. Das Schlüsselwort restrict (OpenSSH 7.2 und später) schaltet die pty-Zuweisung und jede Art von Weiterleitung mit einem einzigen Wort ab, sodass die Beschränkung nicht verrottet, wenn neue Optionen dazukommen. Jetzt die ehrliche Einschränkung, die die meisten Tutorials auslassen: Während Append-Only aktiv ist, sehen borg prune und borg compact so aus, als würden sie erfolgreich laufen, geben aber tatsächlich nichts frei — die Löschung wird in einer Transaktion festgehalten, die die nächste Append-Only-Sitzung zurückrollt. Die Aufbewahrung braucht deshalb einen zweiten, uneingeschränkten Schlüssel, den Sie von Hand von Ihrem Laptop aus benutzen und niemals auf der Quelle speichern. Zwei Schlüssel, zwei Aufgaben: Der nächtliche kann nur schreiben; der Wartungsschlüssel kann löschen und lebt irgendwo, wo die kompromittierte Maschine nicht hinreicht. Halten Sie diesen Schlüssel auch für einen anderen Zweck griffbereit — ein Job, der mitten im Lauf abgebrochen wird, hinterlässt eine veraltete Sperre, und borg break-lock ist ein Schreibvorgang.

Wo die zweite Kopie leben sollte

Backups sind die eine Arbeitslast, bei der Latenz keine Rolle spielt, ignorieren Sie also den üblichen Reflex, die Maschine in die Nähe Ihrer Nutzer zu stellen, und entscheiden Sie sich stattdessen nach Recht und Unabhängigkeit. Ein anderes Land als die Produktion ist das Minimum; eine andere Rechtsfamilie ist besser. Unsere Regionen beantworten jeweils eine andere Frage — Rumänien ist das Flaggschiff, wo DMCA-Hinweise schlicht nicht bearbeitet werden, die Schweiz steht außerhalb der EU hinter ungewöhnlich strengen Datenschutzgesetzen, Island hat das IMMI-Framework, Panama hat kein verpflichtendes Gesetz zur Vorratsdatenspeicherung und keinen Schnellweg für ausländische Anfragen, Malaysia stellt eine Kopie vollständig außerhalb der Reichweite der Five-Eyes, und die Niederlande sind der Peering-Hub. Welchen Offshore-Standort sollten Sie wählen? arbeitet die Kompromisse gründlich durch; für ein Backup-Ziel lautet die Antwort meist „wo auch immer die Produktion nicht ist“. Ports sind bei jedem Plan unlimitiert, sodass der erste vollständige Upload nur dadurch begrenzt wird, wie schnell die Quelle ihre eigene Festplatte lesen kann, nicht durch ein Transfer-Kontingent, das Sie sich einteilen müssten.

Die Dimensionierung ist weniger dramatisch, als man erwartet. Deduplizierung plus zstd bedeutet, dass das Repository normalerweise nur einen Bruchteil der Quelle ausmacht, und nach dem ersten Lauf gehen nur noch geänderte Chunks über die Leitung — ein vielbeschäftigter 40-GB-Server mit einer normalen Änderungsrate pendelt sich bei ein paar hundert Megabyte pro Nacht ein, sodass ein Jahr täglicher Archive weit weniger Festplattenplatz kostet als ein Jahr täglicher Tarballs. Der kleinste Plan auf der Leiter ist ein völlig ausreichendes Ziel; steigen Sie nur höher, wenn Sie eine tiefe Historie von etwas wirklich Großem aufbewahren, und lesen Sie die genauen Spezifikationen auf der Planseite, statt einer Zahl zu vertrauen, die in einem Guide steht, wo sie veralten würde. Eine Regel für die Box selbst: Geben Sie ihr sonst keine Aufgabe. Kein Webserver, keine Datenbank, kein öffentlicher Dienst außer SSH mit Schlüssel. Ein Backup-Ziel, das nebenbei auch ein Hobbyprojekt hostet, ist ein Backup-Ziel mit der Angriffsfläche dieses Hobbyprojekts, und es sollte die volle Behandlung der ersten Stunde bekommen, bevor es auch nur ein einziges Archiv empfängt.

Ein Backup, das Sie nicht wiederhergestellt haben, ist ein Gerücht

Backup-Systeme versagen selten laut. Sie versagen, weil ein Exclude-Muster still und leise das Datenverzeichnis verschluckt hat, oder weil eine Datenbank Datei für Datei kopiert wurde, während noch Schreibvorgänge liefen, und der Dump sich in einer verstümmelten Tabelle wiederherstellt, oder weil der Timer seit sechs Wochen hinter einem Distributions-Upgrade fehlschlägt und niemand die Mail-Spool liest. Der einzige Test, der irgendetwas davon aufdeckt, ist eine Wiederherstellung. Machen Sie das nach Zeitplan: Wählen Sie zufällig ein Archiv, extrahieren Sie es in ein Wegwerf-Verzeichnis, diffen Sie eine Handvoll Dateien gegen die Produktion, starten Sie die Datenbank aus dem Dump und führen Sie eine Abfrage aus, und notieren Sie sich, wie lange das Ganze gedauert hat. Diese Zahl ist Ihre tatsächliche Wiederherstellungszeit — nicht die, die Sie angenommen hatten — und sie ist der einzige Wert, den es sich lohnt, sich selbst um drei Uhr morgens vorzusagen. Machen Sie den Wiederherstellungstest mindestens einmal von einer komplett leeren Maschine aus, denn das ist das echte Szenario: ein frischer VPS, eine Passphrase aus Ihrem Passwort-Manager, ein exportierter Schlüssel von wo auch immer Sie ihn hingelegt haben, und sonst nichts.

Monitoring verdient dieselbe Skepsis, die Sie auf den Rest des Stacks angewendet haben. Der Standardrat ist ein Dead-Man's-Switch eines Drittanbieters, den Ihr Job bei Erfolg anpingt, was still einem externen Dienst Ihre Hostnamen, Ihren Zeitplan und den Moment verrät, in dem Ihre Infrastruktur nicht mehr gesund ist — eine seltsame Sache, um sie an eine Maschine zu hängen, die Sie bewusst gekauft haben, ohne irgendwo eine Identität zu hinterlassen. Sie brauchen ihn nicht. Aktualität lässt sich vom Ziel aus überprüfen, ganz ohne den Schlüssel: Die neueste Segmentdatei im Repository trägt einen Zeitstempel, sodass ein Fünf-Zeilen-Cronjob auf der Backup-Box, der Alarm schlägt, wenn seit fünfundzwanzig Stunden nichts angekommen ist, nichts kostet und nichts preisgibt. Auch für die Integrität gibt es eine schlüssellose Prüfung — borg check --repository-only läuft lokal auf dem Ziel und validiert die Segmentstruktur, ohne je Ihre Daten zu sehen. Führen Sie den tiefen --verify-data-Durchlauf gelegentlich von der Quelle aus mit dem Wartungsschlüssel aus, wo der Schlüssel hingehört.

Was es kostet, und wo es im Stack sitzt

Die Wirtschaftlichkeit ist nicht knapp. Ein zweiter VPS ab $8.00/Monat, finanziert aus demselben Prepaid-Guthaben mit Aufladungen ab $30.00, online in etwa 15 min, gegen die Kosten, alles zu verlieren, was auf der ersten Maschine liegt. Betreiben Sie ihn zusätzlich zu den anbieterseitigen Backups, nicht anstelle von ihnen: Das Add-on für tägliche verschlüsselte Backups fängt den Fall „falsches Verzeichnis gelöscht“ ohne jeden Aufwand Ihrerseits und ohne Nachdenken um drei Uhr morgens ab, während das, was Sie hier aufgebaut haben, die Kopie ist, die Ihnen bleibt, wenn das Konto, die Region oder der Anbieter das ist, was verschwunden ist. Sie decken unterschiedliche Ausfälle ab, und keine ersetzt die andere, was genau der Sinn davon ist, bis drei zu zählen.

Es lohnt sich, damit zu enden, wo Backups im Verhältnis zu allem anderen stehen, denn das sind vier Kontrollen, die unabhängig voneinander versagen. Was der Host über Sie weiß, ist die erste, und hier ist es fast nichts — ein Benutzername und ein Krypto-Guthaben, das Thema von Hosting anonym bezahlen. Welches Recht gilt, ist die zweite, entschieden davon, wo die Hardware steht, statt davon, wo Sie sitzen. Was die Maschine erlaubt, ist die dritte, das ist die erste Stunde nach dem Deploy, und die liegt allein bei Ihnen zu konfigurieren. Und was die Maschine überlebt, ist die vierte — die einzige, die ein Versprechen ist, das Sie Ihrem zukünftigen Ich geben, und die einzige, an die Sie niemand erinnert, bis zu dem Tag, an dem es zu spät ist, damit anzufangen. Eine Stunde heute Abend, und ein Wiederherstellungstest im Kalender. Das ist alles.

Schritt für Schritt

1. 01

   Backup-Ziel deployen und ihm keine andere Aufgabe geben

   Deployen Sie einen zweiten VPS in einer Region, in der nicht die Produktion liegt, und behandeln Sie ihn als Appliance mit genau einem Zweck. Fahren Sie die Standard-Checkliste für die erste Stunde darauf — SSH nur mit Schlüssel, Default-Deny-Firewall für beide IP-Familien, unbeaufsichtigte Sicherheitsupdates —, öffnen Sie danach nichts weiter. Der einzige eingehende Port auf dieser Maschine ist SSH.

   ssh root@198.51.100.7
   apt update && apt full-upgrade -y
   hostnamectl set-hostname vault-01
   apt install -y borgbackup ufw unattended-upgrades
   ufw default deny incoming && ufw default allow outgoing
   ufw limit 22/tcp && ufw enable

2. 02

   Eingeschränktes Borg-Konto mit zwei Schlüsseln anlegen

   Erzeugen Sie zwei Schlüsselpaare auf der Quelle: eines für den nächtlichen Job (ohne Passphrase — er muss unbeaufsichtigt laufen können) und eines für die Wartung, das Sie ausschließlich auf Ihrem Laptop aufbewahren. Legen Sie auf dem Ziel einen unprivilegierten borg-Benutzer an und binden Sie jeden Schlüssel an einen erzwungenen Befehl. Der Job-Schlüssel bekommt --append-only; der Wartungsschlüssel nicht. Diese eine Datei ist es, die einen Eindringling auf der Quelle davon abhält, Ihre Historie auszulöschen.

   # on the source
   ssh-keygen -t ed25519 -N "" -f /root/.ssh/borg_job -C "job@edge-01"
   # on your laptop
   ssh-keygen -t ed25519 -f ~/.ssh/borg_maint -C "maint@laptop"
   
   # on the target
   adduser --disabled-password --gecos "" borg
   install -d -m 700 -o borg -g borg /home/borg/.ssh /srv/borg
   cat > /home/borg/.ssh/authorized_keys <<'EOF'
   command="borg serve --append-only --restrict-to-path /srv/borg",restrict ssh-ed25519 AAAA...job@edge-01
   command="borg serve --restrict-to-path /srv/borg",restrict ssh-ed25519 AAAA...maint@laptop
   EOF
   chown borg:borg /home/borg/.ssh/authorized_keys
   chmod 600 /home/borg/.ssh/authorized_keys

3. 03

   Repository initialisieren, dann den Schlüssel von beiden Maschinen entfernen

   Initialisieren Sie mit dem Wartungsschlüssel, von Ihrem Laptop aus — ein Repository anzulegen ist kein Append. Ein Repository pro Quellmaschine hält die Aufbewahrung simpel und den Schadensradius klein. Exportieren Sie den Schlüssel danach zweimal, in zwei Formaten, und bringen Sie beide Exporte irgendwohin, das weder die Quelle noch das Ziel ist: ein Passwort-Manager, ein verschlüsselter USB-Stick, ein Blatt Papier in einer Schublade. Ein Repository, dessen Schlüssel nur in ihm selbst existiert, ist ein Münzwurf.

   export BORG_REPO='ssh://borg@198.51.100.7/srv/borg/edge-01'
   export BORG_RSH='ssh -i ~/.ssh/borg_maint'
   borg init --encryption=repokey-blake2
   
   borg key export :: /tmp/edge-01.borgkey
   borg key export --paper :: /tmp/edge-01.paper
   # move both off this machine, then shred the copies
   shred -u /tmp/edge-01.borgkey /tmp/edge-01.paper

4. 04

   Anwendungszustand einfrieren, bevor die Platte gelesen wird

   Ein laufendes Datenbankverzeichnis Datei für Datei zu kopieren, erzeugt eine Datei, die aussieht wie eine Datenbank, und deren Wiederherstellung sich anfühlt wie ein Tatort. Erst dumpen, dann den Dump sichern, und das rohe Datenverzeichnis ausschließen. Dieselbe Logik gilt für alles mit einem Speicherformat, das Sie nicht kontrollieren: dumpen Sie es, oder stoppen Sie es für die paar Sekunden, die der Snapshot braucht.

   install -d -m 700 /var/backups/dumps
   mariadb-dump --single-transaction --quick --all-databases \
     > /var/backups/dumps/mariadb.sql
   # PostgreSQL:
   # sudo -u postgres pg_dumpall > /var/backups/dumps/pg.sql
   chmod 600 /var/backups/dumps/*.sql

5. 05

   Backup-Job schreiben und auf einen Timer setzen

   Halten Sie das Skript langweilig und lassen Sie es laut scheitern. Die Passphrase kommt über BORG_PASSCOMMAND aus einer Datei mit Modus 600, sodass sie nie in der Prozessliste auftaucht. Benennen Sie Archive mit dem Hostnamen und einem ISO-Zeitstempel, damit sie sich sortieren lassen. Beachten Sie, was nicht in diesem Skript steht: kein prune, kein delete — der Job-Schlüssel könnte sie ohnehin nicht ausführen. Ein Timer mit Persistent=true holt nach einem Neustart nach, und eine randomisierte Verzögerung verhindert, dass alle Ihre Maschinen in derselben Sekunde hochladen.

   cat > /usr/local/sbin/borg-backup.sh <<'EOF'
   #!/bin/bash
   set -euo pipefail
   export BORG_REPO='ssh://borg@198.51.100.7/srv/borg/edge-01'
   export BORG_RSH='ssh -i /root/.ssh/borg_job -o BatchMode=yes'
   export BORG_PASSCOMMAND='cat /root/.config/borg/passphrase'
   borg create --stats --compression zstd,6 --one-file-system \
     --exclude-caches --exclude '/var/cache/*' \
     --exclude '/var/lib/mysql' --exclude '/home/*/.cache' \
     ::'{hostname}-{now:%Y-%m-%dT%H:%M}' \
     /etc /root /home /srv /var/www /var/backups/dumps
   EOF
   chmod 700 /usr/local/sbin/borg-backup.sh
   
   cat > /etc/systemd/system/borg-backup.service <<'EOF'
   [Unit]
   Description=Off-site Borg backup
   [Service]
   Type=oneshot
   Nice=10
   IOSchedulingClass=idle
   ExecStart=/usr/local/sbin/borg-backup.sh
   EOF
   
   cat > /etc/systemd/system/borg-backup.timer <<'EOF'
   [Unit]
   Description=Nightly off-site Borg backup
   [Timer]
   OnCalendar=*-*-* 03:17:00
   RandomizedDelaySec=900
   Persistent=true
   [Install]
   WantedBy=timers.target
   EOF
   systemctl daemon-reload
   systemctl enable --now borg-backup.timer

6. 06

   Mit dem Wartungsschlüssel bereinigen, auf dem Ziel verdichten

   Die Aufbewahrung kann nicht von der Quelle aus laufen, weil der Schlüssel der Quelle Append-Only ist und ihre Löschungen stillschweigend zurückgerollt würden. Führen Sie sie stattdessen von Ihrem Laptop aus, in welchem Rhythmus auch immer Ihnen passt — monatlich reicht völlig. prune entscheidet, welche Archive bleiben; compact ist das, was tatsächlich Festplattenplatz zurückgewinnt. Machen Sie zuerst einen --dry-run und lesen Sie die Liste, bevor Sie irgendetwas löschen lassen.

   export BORG_REPO='ssh://borg@198.51.100.7/srv/borg/edge-01'
   export BORG_RSH='ssh -i ~/.ssh/borg_maint'
   
   borg prune --dry-run --list \
     --keep-daily 7 --keep-weekly 4 --keep-monthly 6
   borg prune --list --stats \
     --keep-daily 7 --keep-weekly 4 --keep-monthly 6
   borg compact --progress

7. 07

   Restore-Test durchführen, dann das Runbook schreiben

   Stellen Sie wieder her, bevor Sie es müssen. Extrahieren Sie ein echtes Archiv in ein Wegwerf-Verzeichnis, vergleichen Sie ein paar Dateien mit den Originalen, und laden Sie den Datenbank-Dump in ein Wegwerf-Schema. Fügen Sie dann die zwei Prüfungen hinzu, die ohne Ihr Zutun laufen: einen schlüssellosen Aktualitätsalarm auf dem Ziel, und einen regelmäßigen Integritätsdurchlauf. Schreiben Sie zum Schluss die drei Fakten auf, die Sie an Ihrem schlimmsten Tag brauchen werden — wo der exportierte Schlüssel liegt, wo die Passphrase liegt, und die genauen Befehle weiter unten.

   borg list ::
   mkdir -p /var/tmp/drill && cd /var/tmp/drill
   borg extract --list ::edge-01-2026-08-31T03:17 etc/nginx
   diff -r etc/nginx /etc/nginx && echo 'restore OK'
   
   # on the target, no key needed:
   borg check --repository-only /srv/borg/edge-01
   find /srv/borg/edge-01/data -type f -mmin -1500 | head -1   # empty = stale