Verschlüsseltes VPS-Backup in sechs Schritten: von einem ungeschützten Server zu einem geprüften, verschlüsselten Repository auf einer zweiten Maschine in einer zweiten Jurisdiktion — restic und Borg im Vergleich, Datenbank-Dumps, die sauber zurückspielen, ein systemd-Timer und ein Append-only-Repository, das ein kompromittierter Server nicht löschen kann. Die zweite Maschine kostet $3.90 im Monat. Getestet unter Debian 12.
Inventar
Was sich nicht neu aufbauen lässt
Installieren
restic oder Borg
Ziel
Eine zweite Bastion
Initialisieren
Repository + erster Lauf
Automatisieren
Dumps, Timer, Aufbewahrung
Übung
Wiederherstellen, und die Zeit messen
Fast jede Diskussion über Backups geht in der ersten Minute schief, weil die beiden Gesprächspartner unterschiedliche Ausfälle im Kopf haben. Der eine stellt sich eine tote Festplatte vor. Der andere stellt sich einen Dienstagmorgen vor, an dem das Konto verschwunden ist. Sie brauchen unterschiedliche Antworten, und ein Setup, das nur den ersten Fall übersteht, fühlt sich sicher an — bis zu dem Moment, in dem es vom zweiten auf die Probe gestellt wird.
Es gibt vier Ausfallarten, gegen die es sich zu wappnen lohnt, und sie sind keine Variationen eines Themas — jede schlägt eine andere Verteidigung.
Hardware. Die NVMe fällt aus, der Host-Knoten stirbt, das Array verliert zwei Mitglieder gleichzeitig. Das ist der Ausfall, auf den sich jeder vorbereitet, und er ist der seltenste auf moderner virtualisierter Infrastruktur. Redundanter Speicher fängt ihn ab. Redundanter Speicher fängt sonst nichts ab, weshalb RAID kein Backup ist und es nie war: Er kopiert jeden Schreibvorgang originalgetreu, einschließlich des Schreibvorgangs, der „alles löschen“ sagt.
Menschlich. Ein Migrationsskript, das gegen die Produktion ausgeführt wurde. Ein DROP TABLE im falschen Terminal. Ein rsync mit vertauschten Argumenten. Das ist mit weitem Abstand die häufigste Ursache für echten Datenverlust, und die einzige Verteidigung dagegen ist Geschichte — eine Kopie von vor dem Fehler, aufbewahrt an einem Ort, den der Fehler nicht erreicht hat. Zeit ist die Zutat: Ist die einzige Kopie ein Spiegel, der dreißig Sekunden hinterherhinkt, enthält er den Fehler bereits.
Böswillig. Jemand erlangt Root-Rechte, oder Ransomware dringt über eine ungepatchte Anwendung ein. Das Erste, was moderne Ransomware tut, ist die Suche nach Backup-Konfigurationen — Zugangsdaten, gemountete Freigaben, Cloud-Schlüssel — und deren Zerstörung, genau weil eine funktionierende Wiederherstellung aus einer Katastrophe einen Nachmittag macht. Ein Backup-Credential, das löschen kann, ist ein Backup-Credential, das der Angreifer erbt. Für genau dieses Versagen gibt es das Append-only-Kapitel dieses Leitfadens.
Fremdverwahrt. Nichts ist kaputtgegangen, und nichts wurde angegriffen; Sie haben einfach den Zugriff verloren. Ein wegen eines automatisierten Betrugssignals gesperrtes Konto, eine Karte, die während einer Reise nicht funktionierte, ein Streitfall, eine Compliance-Prüfung, eine dem Anbieter zugestellte Anordnung. Die Maschine ist intakt und unerreichbar, und jeder Snapshot in diesem Konto ist mit ihr unerreichbar. Das ist der Ausfall, den keine noch so große Redundanz innerhalb eines einzigen Anbieters beantworten kann, und der Grund, warum ein ernstzunehmendes Backup unter einem anderen Dach lebt.
| Abwehr | Hardware | Menschlicher Fehler | Ransomware | Verlorenes Konto |
|---|---|---|---|---|
| RAID / redundanter Speicher | Ja | Nein | Nein | Nein |
| Provider-Snapshot, gleiches Konto | Ja | Teilweise | Nein | Nein |
| Offsite-Repository, schreibfähiger Schlüssel | Ja | Ja | Nein | Ja |
| Offsite-Repository, Append-only, andere Rechtsordnung | Ja | Ja | Ja | Ja |
Die letzte Zeile ist das, worauf der Rest dieses Leitfadens aufbaut. Sie ist nicht teurer als die Zeile darüber — die Append-only-Einstellung kostet nichts, und die zweite Jurisdiktion kostet dieselben $3.90 wie die erste.
Die 3-2-1-Regel, neu formuliert für einen einzelnen VPS. Drei Kopien der Daten, auf zwei verschiedenen Speicherarten, eine davon offsite. Die klassische Formulierung stammt aus einer Ära von Bandlaufwerken und Büroservern, und der Geist übersteht die Übertragung besser als der Wortlaut. Für eine einzelne selbst gehostete Maschine liest sie sich so: die Live-Daten auf dem VPS, ein Repository auf einer zweiten Maschine woanders, und — für alles, was wirklich unersetzlich ist — eine dritte Kopie, die Sie in der Hand halten können, auf einer Festplatte zu Hause oder in einer Schublade. Die Zahl, die wirklich zählt, ist nicht drei. Es ist die Anzahl unabhängiger Dinge, die schiefgehen müssen, bevor die Daten weg sind. Zwei ist das Minimum, das sich lohnt.
Die Kategorie, die Sie suchen, nennt sich deduplizierendes, verschlüsselndes Snapshot-Tool. Es zerlegt jede Datei in inhaltsdefinierte Chunks, verschlüsselt jeden Chunk auf der Maschine, der die Daten gehören, und speichert ihn nur einmal, egal wie viele Snapshots darauf verweisen. Das verschafft Ihnen drei Eigenschaften gleichzeitig: viele Wiederherstellungspunkte für kaum mehr Platz als einen einzigen, Klartext, der die Quelle nie verlässt, und eine Übertragung, die nur das überträgt, was sich geändert hat.
Zwei Programme dominieren dieses Feld, und beide sind hervorragend. restic ist ein einzelnes statisches Go-Binary mit einer breiten Palette an Storage-Backends. BorgBackup ist ein Python-Programm, das per SSH mit einer Kopie seiner selbst auf der Gegenseite spricht. Alles Folgende ist der ehrliche Unterschied zwischen den beiden.
| Eigenschaft | restic | BorgBackup | rsync / rclone |
|---|---|---|---|
| Clientseitige Verschlüsselung | Immer aktiv, nicht optional | Immer aktiv, nicht optional | Nur über ein rclone-Crypt-Remote |
| Deduplizierung | Inhaltsdefinierte Chunks | Inhaltsdefinierte Chunks | Keine, oder Hardlink-Bäume |
| Snapshot-Verlauf | Ja, mit Aufbewahrungsrichtlinien | Ja, mit Aufbewahrungsrichtlinien | Ein Spiegel von genau jetzt |
| Anforderungen an das Ziel | Nichts — SFTP, S3, REST, rclone | Borg auf beiden Seiten installiert | Ein SSH-Konto oder eine API |
| Append-only-Durchsetzung | Über rest-server oder Object Lock | Eingebaut, über reines SSH | Keine |
| Geeignet für | Fast jeder, die meisten Backends | Eine eigene SSH-Maschine, Append-only | Spiegelung, kein Backup |
rsync steht in der Tabelle, weil es das ist, wonach die meisten Leute zuerst greifen, und weil es tatsächlich das falsche Werkzeug ist: Ein Spiegel gibt eine Löschung originalgetreu wieder, und der Spiegel einer at-rest verschlüsselten Festplatte ist selbst nirgends verschlüsselt. Seinen Platz innerhalb eines Backups verdient es sich als das, was ein fertiges Archiv transportiert, nicht als das Archiv selbst.
Dieser Leitfaden zeigt für jeden Befehl, der sich unterscheidet, sowohl restic als auch Borg, sodass Sie ihm mit beiden folgen können. Wo eine einzige Entscheidung getroffen werden muss — das durchgerechnete Beispiel, der Timer, das Skript — verwendet er restic, weil das Ziel dann nichts weiter als einen SSH-Account braucht und das die zweite Maschine langweilig hält.
Das gesamte Dateisystem zu sichern ist eine vertretbare Wahl und eine verschwenderische. Der größte Teil eines Servers ist nur einen Paketmanager davon entfernt, neu erstellt zu werden, und jedes Gigabyte davon, das Sie mitschleppen, macht das Repository langsamer beim Bereinigen, teurer im Halten und langsamer beim Durchsuchen, wenn es eilig ist. Die nützliche Übung ist die umgekehrte: Listen Sie auf, was eine frische Installation Ihnen nicht zurückgeben würde.
Bei einem typischen selbstgehosteten VPS ist diese Liste kurz, und sie enthält immer diese fünf Dinge:
Machen Sie aus der Liste zwei Dateien auf dem Quellserver. Eine Include-Liste hält die Absicht sichtbar; eine Exclude-Liste hält den Störfaktor draußen. Beide werden vom Backup-Befehl gelesen, und beide gehören selbst mit ins Backup.
/etc/backup/include.txt
/etc
/opt
/root
/var/backups
/var/lib/docker/volumes
/home
/etc/backup/exclude.txt
# Caches and rebuildable artefacts
**/node_modules
**/.cache
**/*.tmp
/var/lib/docker/volumes/*/_data/cache
# Log noise — keep the config, drop the volume
/var/log/journal
# Never back up the mount point you restore into
/mnt/restore
Zwei Anmerkungen zu dieser Docker-Zeile, weil sie Leute reinlegt. Named Volumes liegen unter /var/lib/docker/volumes und sind das, was Sie wollen; Bind Mounts liegen dort, wo Sie sie hinlegen, meist neben der Compose-Datei, und sind durch /opt abgedeckt. Container-Images sind keine Daten — sie kommen mit einem Pull zurück, und ein Backup, das sie mitschleppt, schleppt Gigabyte mit, die es nicht braucht.
Messen Sie zum Schluss das Ergebnis, bevor Sie etwas darauf aufbauen. Die Zahl sagt Ihnen, welche Repository-Stufe Sie bestellen sollten und ob der erste Lauf vier Minuten dauert oder vierzig:
du -sh --exclude=/var/lib/docker/overlay2 /etc /opt /root /home /var/lib/docker/volumes
Installieren Sie das Werkzeug auf der Maschine, der die Daten gehören. Unter Debian und Ubuntu sind beide paketiert, und bei restic hinkt das Distributionspaket oft ein oder zwei Releases hinterher — was wichtig ist, denn Repository-Funktionen und Performance-Arbeit landen in den Point-Releases. Installieren Sie das Paket, und lassen Sie restic sich anschließend selbst an Ort und Stelle aktualisieren:
apt update && apt install -y restic
restic self-update
restic version
Bei Borg ist das Distributionspaket die richtige Wahl, denn die Version auf der Quelle und die Version auf dem Ziel müssen sich verstehen, und ein zusammenpassendes Paar aus demselben Distributions-Release ist der schmerzloseste Weg, das zu erreichen:
apt install -y borgbackup
borg --version
Ein Wort zu Hauptversionen, bevor Sie Jahre an Historie einem Repository anvertrauen: Das Repository-Format von Borg hat sich zwischen den Hauptlinien geändert, und ein Repository über diese Grenze hinweg zu verschieben ist eine Konvertierung, kein Upgrade. Lesen Sie die Release Notes der Version, die Sie installieren, und halten Sie das Ziel auf derselben Hauptlinie wie die Quelle. restic ist über seine Releases hinweg abwärtskompatibel geblieben und führt neue Funktionen hinter einer expliziten Repository-Version ein, sodass die entsprechende Sorge dort kleiner ausfällt.
Keines der beiden Werkzeuge braucht einen Daemon, einen Agenten oder einen offenen Port auf der Quelle. Das ist es wert, laut ausgesprochen zu werden: Das Backup-System, das Sie installieren, fügt der Maschine, die es schützt, keinen lauschenden Dienst und keine neue Angriffsfläche hinzu. Alles, was es tut, ist ausgehend, nach Zeitplan, über SSH.
Der Repository-Host hat genau eine Aufgabe und fast keine Anforderungen. Er braucht keine Kerne, weil er Ihre Daten nie liest — er hält verschlüsselte Blobs, die er nicht öffnen kann. Er braucht keinen Arbeitsspeicher, weil die Deduplizierungsarbeit auf der Quelle stattfindet. Er braucht Speicherplatz, eine stabile Adresse, und einen Standort, an dem ihn die Probleme der Quellmaschine nicht einholen.
Im Panel: Order → VPS → Sentinel, Image Debian 12, und — das ist der ganze Punkt — eine andere Bastion als die, in der die Quelle läuft. Helsinki arbeitet, Reykjavík hält. Für die Eröffnung des Kontos ist keine E-Mail-Adresse nötig, und die Rechnung wird in Monero, Bitcoin, Lightning oder einem der anderen unterstützten Assets beglichen — die zweite Maschine führt die Identität, auf die die erste so bedacht war, also nicht wieder ein.
| Repository-Ziel | Monatlich | Speicher | Enthaltener Arbeitsbestand | Kosten der Wiederherstellung |
|---|---|---|---|---|
| Sentinel | $3.90 | 120 GB NVMe | ~30 GB | Nichts — pauschal |
| Garrison | $7.90 | 240 GB NVMe | ~70 GB | Nichts — pauschal |
| Ravelin | $16.90 | 480 GB NVMe | ~150 GB | Nichts — pauschal |
| Bulwark | $32.90 | 960 GB NVMe | ~300 GB | Nichts — pauschal |
| S3-Objektspeicher | ~$0.023/GB | Elastisch | Beliebig | Abgerechneter Traffic |
Die Spalte für den Arbeitsbestand geht von täglichen Snapshots über ein Jahr bei normaler Änderungsrate aus; ein Repository, das überwiegend langsam veränderliche Dateien enthält, reicht deutlich weiter, eines voller großer, immer wieder neu geschriebener Binärdateien reicht weniger weit. Die letzte Zeile steht dort für die Größenordnung, und für das Detail, das man bis zum schlechten Tag vergisst: Objektspeicher berechnet auch den Download, und der Download ist das, was man im Notfall tut.
Auf dem Ziel — ein unprivilegierter Benutzer und ein Verzeichnis.
adduser --disabled-password --gecos "" backup
install -d -m 0700 -o backup -g backup /srv/restic/web01
Der Backup-Benutzer hat kein Passwort, kein sudo und nichts, worin er sich einloggen könnte. Er existiert nur, um Eigentümer eines Verzeichnisses zu sein. Geben Sie ihm ein eigenes Verzeichnis pro Quellmaschine, wenn Sie mehrere sichern — ein Repository pro Quelle verhindert, dass eine Kompromittierung auf einer Maschine den Verlauf einer anderen berührt.
Auf der Quelle — ein Schlüssel, der für nichts anderes verwendet wird.
ssh-keygen -t ed25519 -f /root/.ssh/id_backup -N "" -C "backup:web01"
cat /root/.ssh/id_backup.pub
Verwenden Sie nicht Ihren Login-Schlüssel erneut. Dieser hier liegt unverschlüsselt auf der Platte, weil ein unbeaufsichtigter Timer ihn um drei Uhr morgens benutzen muss — genau die Art von Schlüssel, die auf ein einziges Ziel und einen einzigen Zweck beschränkt sein sollte.
Zurück auf dem Ziel — schränken Sie ein, was dieser Schlüssel darf. Fügen Sie den öffentlichen Schlüssel mit einem Präfix davor in /home/backup/.ssh/authorized_keys ein. Für restic über SFTP:
restrict,from="198.51.100.7" ssh-ed25519 AAAAC3NzaC1lZDI1... backup:web01
Die restrict-Option schaltet Portweiterleitung, Agent-Forwarding, X11 und PTY-Zuweisung mit einem Wort aus und lässt nur die Dateiübertragung übrig. Die from=-Klausel bindet den Schlüssel an die Quelladresse, sodass eine vom Server gestohlene Kopie davon überall sonst nutzlos ist. Gehen Sie bei Borg noch einen Schritt weiter und erzwingen Sie den Befehl — genau dort lebt sein Append-only-Modus:
command="borg serve --append-only --restrict-to-path /srv/borg/web01",restrict ssh-ed25519 AAAAC3NzaC1lZDI1... borg:web01
Diese Zeile ist die gesamte Ransomware-Abwehr an einer Stelle: Was auch immer die Quelle sendet, das Ziel führt ausschließlich borg serve aus, nur innerhalb dieses Pfads, und nur in einem Modus, der ausschließlich anhängt. Eine Root-Shell auf der Quelle kann mit diesem Schlüssel nicht den letzten Monat löschen.
Benennen Sie das Ziel einmal, auf der Quelle. Legen Sie es in /root/.ssh/config ab, damit jeder spätere Befehl kurz bleibt und die Adresse in genau einer Datei steht:
Host rkv-repo
HostName 198.51.100.42
User backup
IdentityFile /root/.ssh/id_backup
IdentitiesOnly yes
Verbinden Sie sich dann einmal von Hand — ssh rkv-repo — um den Host-Key zu akzeptieren. Ein unbeaufsichtigter Timer beantwortet keine Fingerprint-Abfrage, und ein erstes Backup, das eine Woche lang stillschweigend hängen bleibt, ist ein Klassiker. Solange Sie auf dem Ziel sind, behandeln Sie es wie jede andere Maschine, die Ihnen gehört: Führen Sie auch dort die Checkliste zur Härtung in der ersten Stunde aus. Es hält eine Kopie von allem, und es verdient die volle Stunde.
Erzeugen Sie eine Passphrase, die Sie nie eintippen werden. Sie wird von einem Skript aus einer Datei gelesen, also kostet Länge nichts, und es gibt keinen Grund, sie sich merkbar zu machen:
openssl rand -base64 32 > /root/.restic-pass
chmod 600 /root/.restic-pass
cat /root/.restic-pass
Halten Sie jetzt inne und kopieren Sie diese Zeichenkette irgendwohin, das nicht dieser Server ist. Ein Passwort-Manager, eine Papiernotiz in einer Schublade, eine zweite Maschine — irgendwo, das den Verlust der Quelle übersteht. Das ist derselbe Fehler, der selbstgehostete Tresore und Automatisierungs-Engines zerstört: Der Schlüssel, der alles entschlüsselt, wird direkt neben allem gespeichert, und beides geht zusammen verloren. Ein Repository, dessen Passphrase nur auf der Maschine existierte, die es schützte, ist kein Backup; es ist ein sehr ordentlicher Haufen Rauschen.
Schreiben Sie die Environment-Datei, die jeder spätere Befehl liest:
/etc/backup/restic.env
RESTIC_REPOSITORY=sftp:rkv-repo:/srv/restic/web01
RESTIC_PASSWORD_FILE=/root/.restic-pass
chmod 600 /etc/backup/restic.env
set -a; . /etc/backup/restic.env; set +a
restic init
Das entsprechende Befehlspaar für Borg — der repokey-Modus speichert den Verschlüsselungsschlüssel innerhalb des Repositorys, geschützt durch die Passphrase, was praktisch ist und genau deshalb exportieren Sie zusätzlich eine Kopie davon:
export BORG_REPO=ssh://borg@rkv-repo/srv/borg/web01
export BORG_PASSCOMMAND="cat /root/.restic-pass"
borg init --encryption=repokey-blake2
borg key export :: /root/borg-key.txt # copy this off the server too
Der erste Snapshot. Führen Sie ihn von Hand aus, beobachten Sie ihn, und lassen Sie ihn abschließen, bevor Sie irgendetwas automatisieren. Das ist der langsame Lauf — jeder Chunk ist neu — und er zeigt Ihnen, ob die Include-Liste richtig war:
restic backup \
--files-from /etc/backup/include.txt \
--exclude-file /etc/backup/exclude.txt \
--tag nightly --one-file-system --verbose
Bedient die Quelle Datenverkehr und der Upload sättigt die Leitung, drosseln Sie ihn. Das Flag nimmt Kibibyte pro Sekunde, also entspricht 20000 in etwa 20 MB/s:
restic backup --limit-upload 20000 --files-from /etc/backup/include.txt
Wenn er fertig ist, schauen Sie sich an, was Sie tatsächlich bekommen haben. Diese drei Befehle sind die, die Sie jetzt ausführen — und noch einmal in sechs Monaten, wenn Sie längst nicht mehr daran denken:
restic snapshots # the list, with dates and tags
restic stats latest # what the newest snapshot contains
restic ls latest /etc/backup # confirm a path you expected is in there
Dieser dritte Befehl ist einen Moment wert. Die Hälfte aller kaputten Backups ist gar nicht kaputt — es sind vollständige, gesunde Repositorys des falschen Verzeichnisses. Einen erwarteten Pfad schon beim allerersten Snapshot aufzulisten, deckt das auf, solange die Include-Datei noch frisch im Gedächtnis ist.
Die Datenbank-Regel, einmal festgehalten. Eine laufende Datenbank-Engine hält Zustand im Speicher und schreibt ihn zu ihrem eigenen Zeitpunkt heraus. Lesen Sie ihre Dateien währenddessen, erhalten Sie eine Ansammlung von Seiten aus mehreren unterschiedlichen Momenten — eine Datei, die sich vielleicht wiederherstellen lässt, vielleicht beschädigt wiederhergestellt wird oder sich zu etwas wiederherstellen lässt, das sauber öffnet und stillschweigend die letzte Stunde vermisst. Von außen lässt sich nicht unterscheiden, welcher Fall vorliegt. Deshalb rührt das Backup die Live-Dateien nie an: Ein Dump wird zuerst auf die Platte geschrieben, und das Backup holt sich den Dump.
Alles kommt in ein Skript. Legen Sie es unter /usr/local/sbin/nb-backup.sh ab, machen Sie es ausführbar, und nehmen Sie es ins Backup selbst mit auf:
#!/bin/sh
set -eu
# ---- 1. Consistent dumps, written where the include list will find them.
install -d -m 0700 /var/backups/db
# PostgreSQL in a container:
docker exec -t app-db pg_dumpall -U postgres | gzip -9 > /var/backups/db/postgres.sql.gz
# MariaDB / MySQL, InnoDB tables:
# docker exec -t mail-db mariadb-dump --single-transaction --all-databases \
# | gzip -9 > /var/backups/db/mariadb.sql.gz
# SQLite — never a plain file copy:
# sqlite3 /opt/app/data/app.db ".backup '/var/backups/db/app.db'"
# ---- 2. The snapshot.
restic backup \
--files-from /etc/backup/include.txt \
--exclude-file /etc/backup/exclude.txt \
--tag nightly --one-file-system
# ---- 3. Retention, then reclaim the space it freed.
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune
# ---- 4. Structural check every night; read 5% of the data on Sundays.
restic check
[ "$(date +%u)" = "7" ] && restic check --read-data-subset=5%
echo "backup ok: $(date -u +%FT%TZ)"
Drei Details in diesem Skript leisten mehr, als es aussieht. Das set -eu am Anfang sorgt dafür, dass ein fehlgeschlagener Dump den Lauf abbricht, statt sechs Monate lang stillschweigend den Dump von gestern zu snapshotten. forget und prune sind ein einziger Befehl, weil eine Aufbewahrungsrichtlinie, die nie Platz freigibt, eine Festplatte ist, die volläuft. Und die Sonntagsprüfung liest einen Ausschnitt der tatsächlichen Daten statt nur den Index — Repository-Korruption ist selten und lautlos, und das Einzige, was sie findet, ist Lesen.
Der Timer. Zwei kleine Unit-Dateien. systemd ist hier der richtige Scheduler statt cron, weil ein Timer Ihnen Persistent gibt — ein Lauf, der verpasst wurde, während die Maschine ausgeschaltet war, findet beim nächsten Boot statt, statt stillschweigend übersprungen zu werden — und weil journalctl dann die Historie jedes Laufs vorhält.
/etc/systemd/system/nb-backup.service
[Unit]
Description=Nightly encrypted offsite backup
Wants=network-online.target
After=network-online.target docker.service
[Service]
Type=oneshot
EnvironmentFile=/etc/backup/restic.env
ExecStart=/usr/local/sbin/nb-backup.sh
Nice=10
IOSchedulingClass=idle
/etc/systemd/system/nb-backup.timer
[Unit]
Description=Nightly encrypted offsite backup
[Timer]
OnCalendar=*-*-* 03:00:00
RandomizedDelaySec=45m
Persistent=true
[Install]
WantedBy=timers.target
systemctl daemon-reload
systemctl enable --now nb-backup.timer
systemctl list-timers nb-backup.timer
systemctl start nb-backup.service && journalctl -u nb-backup.service -n 40 --no-pager
Die zufällige Verzögerung ist keine Kosmetik. Jeder selbst gehostete Server im Internet führt seine Wartung exakt um 03:00 Uhr aus, und ein Backup, das zur selben Sekunde wie die Log-Rotation, die Zertifikatserneuerung und das Container-Update startet, verbringt die Nacht damit, mit ihnen um I/O zu konkurrieren. Den Start über fünfundvierzig Minuten zu streuen kostet nichts und beseitigt eine ganze Klasse rätselhaft langsamer Nächte.
Dann Ausfälle laut machen. Das ist der Schritt, den jeder überspringt, und er entscheidet darüber, ob sich das alles überhaupt gelohnt hat. Ein Backup, das nicht mehr funktioniert, kündigt sich nirgends an: Der Timer feuert weiter, der Dienst schlägt weiter fehl, und der letzte gute Snapshot rückt immer weiter in die Vergangenheit, während das Dashboard grün bleibt. Fügen Sie dem Dienst eine OnFailure=-Unit hinzu, die Ihnen etwas schickt, das Sie tatsächlich sehen, und werfen Sie einmal im Monat einen Blick auf den Anfang der Snapshot-Liste. Eine Zeile, eine Gewohnheit.
restic snapshots --latest 3 # is the newest one from last night?
systemctl list-timers nb-backup.timer # is the timer still armed?
Es gibt zwei Übungen, und sie beantworten unterschiedliche Fragen. Die kleine fragt: „Sind die Daten wirklich drin und lesbar?“ und dauert neunzig Sekunden. Die große fragt: „Wie lange würde es tatsächlich dauern, den Dienst wieder zum Laufen zu bringen?“ und dauert einen Nachmittag, einmal im Jahr. Machen Sie die kleine monatlich. Machen Sie die große mindestens einmal, denn die Antwort ist nie das, was man vermutet.
Die kleine Übung. Ziehen Sie ein Verzeichnis und ein Dump in einen Testpfad und vergleichen Sie sie dann mit dem Live-Stand:
install -d -m 0700 /mnt/restore
restic restore latest --target /mnt/restore --include /etc/backup
restic restore latest --target /mnt/restore --include /var/backups/db
diff -r /etc/backup /mnt/restore/etc/backup && echo "config identical"
gzip -t /mnt/restore/var/backups/db/postgres.sql.gz && echo "dump readable"
Noch besser, sofern das Werkzeug es anbietet: Mounten Sie das Repository schreibgeschützt und durchsuchen Sie es wie ein Dateisystem. Jeder Snapshot erscheint als datiertes Verzeichnis, und Sie können die Historie mit ls und cat durchstöbern, statt überhaupt irgendetwas wiederherzustellen. Dafür wird FUSE auf der mountenden Maschine benötigt:
restic mount /mnt/snapshots # then: ls /mnt/snapshots/snapshots/latest/
borg mount :: /mnt/snapshots # the Borg equivalent
Die große Übung. Bestellen Sie einen Wegwerf-VPS auf Stundenbasis und bauen Sie den Dienst darauf allein aus dem Repository wieder auf — keine Notizen aus dem Gedächtnis, keine Dateien, die von der laufenden Maschine kopiert wurden. Arbeiten Sie nach einem schriftlichen Runbook und korrigieren Sie es dabei, denn die Lücken, die Sie finden, sind der eigentliche Sinn der Übung. Die üblichen Entdeckungen, nach Häufigkeit geordnet: Die Passphrase war nur auf der toten Maschine gespeichert; die DNS-Einträge waren nirgends notiert; ein bind-gemountetes Verzeichnis lag außerhalb jedes Include-Pfads; die Wiederherstellung benötigte eine Paketversion, die nicht mehr der Standard ist; niemand wusste, welcher Container zuerst starten musste.
Stoppen Sie die Zeit. Schreiben Sie die Zahl mit Datum oben ins Runbook. Diese Zahl — nicht die Größe des Repositorys, nicht die Anzahl der Snapshots — ist das einzig ehrliche Maß dafür, wie geschützt der Dienst tatsächlich ist.
Und die Daten gelegentlich lesen. Die nächtliche Prüfung verifiziert nur die Struktur: dass der Index in sich konsistent ist und kein Blob fehlt. Sie liest die Blobs nicht. Einmal im Monat, oder beim Sonntagslauf, lesen Sie einen Ausschnitt davon — ein rotierender Anteil von fünf Prozent deckt das gesamte Repository über ein paar Monate ab, ohne je eine lange Nacht zu kosten:
restic check --read-data-subset=5%
borg check --verify-data # the Borg equivalent, slower and thorough
Alles bis hierhin schützt vor Unfällen. Dieses Kapitel schützt vor einem Angreifer, und das Designproblem ist unangenehm, sobald man es sieht: Die Quellmaschine muss das Repository jede Nacht erreichen, was bedeutet, dass die Quellmaschine eine funktionierende Anmeldeinformation für das Repository besitzt. Wer die Quelle besitzt, besitzt diese Anmeldeinformation. Kann die Anmeldeinformation löschen, löscht der Angreifer — und moderne Ransomware tut genau das, absichtlich, bevor sie überhaupt irgendetwas verschlüsselt, denn ein Opfer, das wiederherstellen kann, zahlt nicht.
Die Lösung ist kein besseres Passwort. Es ist eine asymmetrische Berechtigung: Die Quelle darf Daten hinzufügen und keine entfernen. Drei Wege, das umzusetzen, absteigend danach geordnet, wie leicht man sie richtig hinbekommt.
Eins — erzwungenes Append-only über SSH. Das ist Borgs ureigenes Terrain und die sauberste verfügbare Lösung auf einer Maschine, die Ihnen gehört. Der authorized_keys-Eintrag aus Schritt 03 erzwingt borg serve --append-only, sodass die Gegenseite Löschungen verweigert, egal was die nahe Seite verlangt. Pruning muss trotzdem stattfinden, aber es geschieht von der Zielseite aus, nach einem Zeitplan, den die Quelle nicht beeinflussen kann, ausgeführt von einem Account, den die Quelle nicht erreicht. Ein Angreifer mit Root-Rechten auf der Quelle kann das Repository mit Müll füllen; er kann nicht das Archiv von der Nacht vor seiner Ankunft entfernen.
Zwei — ein Append-only-REST-Endpunkt. restics Begleitprogramm rest-server verfügt über einen --append-only-Modus mit derselben Eigenschaft: Neue Blobs werden akzeptiert, bestehende können nicht entfernt werden. Betreiben Sie ihn auf dem Ziel hinter TLS, richten Sie RESTIC_REPOSITORY auf die https://-URL statt der sftp:-URL aus, und die Form der Verteidigung ist identisch. Es kostet einen weiteren Dienst auf dem Ziel und erkauft dieselbe Garantie.
Drei — Object Lock. Bei S3-kompatiblem Speicher macht Versionierung plus eine Object-Lock-Aufbewahrungsfrist Löschen unmöglich, bis die Frist abläuft — durchgesetzt von der Speicherschicht, nicht von einem Programm. Das ist die stärkste der drei Optionen und die teuerste, und sie führt ein Provider-Konto ein — was das Fremdverwahrungsrisiko zurückbringt, das diese ganze Anleitung zu verteilen versucht. Sinnvoll als dritte Kopie, unpraktisch als einzige.
Passt nichts davon — reines SFTP, ein Schlüssel, der schreiben und daher löschen kann —, tun Sie nicht so, als wäre das kein Problem; fügen Sie eine zweite, unabhängige Kopie hinzu, die die Quelle überhaupt nicht anfassen kann. Pull statt Push: Lassen Sie das Ziel sich bei der Quelle anmelden, lesen, was es braucht, und speichern. Die Anmeldeinformationen liegen dann auf der Maschine, die nicht exponiert ist, und ein Angreifer auf der Quelle findet nichts, was auf das Backup hindeutet. Es ist etwas mehr Aufwand in der Einrichtung, und es dreht das Risiko genau in die richtige Richtung um.
Für welche Variante Sie sich auch entscheiden, prüfen Sie sie so, wie Sie jede andere Sicherheitskontrolle prüfen würden — indem Sie versuchen, sie zu brechen. Versuchen Sie von der Quelle aus, mit dem Backup-Schlüssel, ein Löschen. Das korrekte Ergebnis ist eine Verweigerung.
borg delete ::name-of-an-old-archive
# → Remote: Repository is in append-only mode. Refusing to delete.
Jeder Dienst hat ein kleines Stück Zustand, das weder Daten noch Konfiguration ist, und es zu verlieren beschädigt den Dienst nicht — es ersetzt ihn durch einen anderen Dienst, der zufällig denselben Namen trägt. Alte Links brechen, föderierte Gegenstellen verweigern die neue Identität, Clients erzeugen neue Schlüssel. Das sind die betreffenden Stücke, je Stack, für die Dinge, zu denen diese Seite Anleitungen hat.
Das Datenverzeichnis, config/config.php und ein Datenbank-Dump. Schalten Sie für den Dump den Wartungsmodus ein, danach wieder aus — sonst schreibt Nextcloud gleichzeitig in beide.
Das gesamte Datenverzeichnis: db.sqlite3, per .backup gesichert statt kopiert, plus rsa_key-Dateien, attachments und sends.
Der Signierschlüssel, homeserver.yaml, der Medienspeicher und ein PostgreSQL-Dump. Geht der Signierschlüssel verloren, ist die Föderationsidentität für immer weg.
Der Mail-Store selbst, die virtuellen Benutzertabellen und die privaten DKIM-Schlüssel — ein neuer DKIM-Schlüssel bedeutet, dass jede Nachricht unsigniert bleibt, bis DNS nachzieht.
Zuerst N8N_ENCRYPTION_KEY, dann der PostgreSQL-Dump. Die Datenbank ohne diesen Schlüssel ist eine Liste von Workflows, deren sämtliche Anmeldeinformationen unlesbar sind.
Das Hidden-Service-Verzeichnis. Diese wenigen Dateien sind die .onion-Adresse — ohne sie kommt der Dienst unter einem anderen Namen zurück, und jeder Link dorthin ist tot.
/etc/wireguard vollständig. Klein, unspektakulär, und der Unterschied zwischen einem Fünf-Minuten-Wiederaufbau und dem Neu-Verschlüsseln jedes einzelnen Ihrer Geräte.
Der Seed und der Channel-State, nach den eigenen Vorgaben des Nodes. Das Wiederherstellen veralteter Channel-Daten kann Sie Geld kosten — folgen Sie dem Backup-Verfahren der jeweiligen Implementierung, nicht einer generischen Dateikopie.
Fragen Sie die meisten Leute, warum das Backup woanders liegen sollte, und die Antwort lautet: Feuer, Überschwemmung oder ein Stromausfall im Rechenzentrum. Alles wahr, alles zunehmend selten, und alles durch hundert Kilometer Entfernung beantwortet. Die Ausfälle, die 2026 tatsächlich Unternehmen lahmlegen, sind administrativer Natur, und Entfernung allein richtet dagegen nichts aus.
Ein Konto ist ein einzelner Ausfallpunkt. Eine Sperrung wegen eines automatisierten Betrugssignals, eine Rückbuchung, während Sie im Flugzeug saßen, eine Compliance-Prüfung, eine Abmahnung, die an das Unternehmen adressiert ist statt an eine Maschine — jedes davon erreicht im selben Moment jeden Server unter diesem Konto, einschließlich desjenigen, der die Snapshots hält. Die technische Redundanz war perfekt und irrelevant. Zwei Anbieter, oder mindestens zwei Konten unter zwei unterschiedlichen rechtlichen Dächern, ist die einzige Struktur, die darauf eine Antwort gibt.
Eine Rechtsordnung ist ein rechtlicher Rahmen. Die vier nordischen Bastionen sind nicht austauschbar — Schweden, Finnland, Norwegen und Island schützen jeweils etwas leicht anderes, und Norwegen und Island stehen vollständig außerhalb der Europäischen Union. Eine Arbeitsmaschine und ihr Repository auf zwei von ihnen zu verteilen bedeutet, dass die Kopie nicht nur woanders liegt; sie unterliegt einem zweiten, unabhängigen Regelwerk. Die Referenz zu den nordischen Jurisdiktionen geht die Gesetze einzeln durch.
Und das Ziel erfährt nichts. Das ist es, was die Aufteilung günstig macht statt zu einem Kompromiss. Sowohl restic als auch Borg verschlüsseln, bevor irgendetwas die Quelle verlässt, sodass der Repository-Host Blobs speichert, für die er keinen Schlüssel hat. Er weiß nicht, welche Dateien er hält, wie viele es sind oder wie sie heißen. Sie erweitern kein Vertrauen auf eine zweite Partei; Sie mieten eine Festplatte, die sich selbst nicht lesen kann. Das ist auch die ehrliche Antwort auf die Frage: „Sollte ich einen Anbieter, dem ich nicht voll vertraue, als Backup-Ziel nutzen?“ — bei einem verschlüsselten Repository spielt Vertrauen kaum eine Rolle.
Die Latenz spielt keine Rolle. Helsinki nach Reykjavík sind 30 ms auf dem Backbone, Helsinki nach Stockholm 8 ms, Stockholm nach Oslo 11 ms. Ein nächtliches Backup kümmert sich um keine dieser Zahlen, und eine Wiederherstellung, die durch den Festplattendurchsatz begrenzt ist, ebenso wenig. Wählen Sie das Paar nach rechtlicher Entfernung, nicht nach Netzwerkentfernung — die Netzwerkentfernung innerhalb der Nordics ist ein Rundungsfehler.
Noch etwas, das offen ausgesprochen werden sollte, denn es ist der Grund, warum diese Anleitung auf dieser Seite steht und nicht in einem x-beliebigen Sysadmin-Blog: Die zweite Maschine öffnet jede Frage erneut, die die erste bereits beantwortet hatte. Wurde der Arbeits-VPS ohne Ausweisdokument bestellt und in Monero bezahlt, die dazugehörige Backup-Maschine dann aber mit Firmenkarte und Passscan bestellt, ist das Paar exakt so identifizierbar wie die schwächere Hälfte. Die Säulenanleitung zu anonymem VPS-Hosting geht die drei Ebenen durch — Anmeldung, Zahlung, Netzwerk — und sie gelten für ein Backup-Ziel genauso buchstäblich wie für einen Webserver.
Das Repository ist intakt, verschlüsselt und dauerhaft unlesbar. Bewahren Sie die Passphrase — und bei Borg den exportierten Schlüssel — vor dem ersten Snapshot in einem Passwortmanager und auf Papier auf.
Live-Datendateien wurden kopiert statt gedumpt. Schreiben Sie einen Dump in einem Pre-Backup-Schritt, und sichern Sie den Dump; richten Sie die Include-Liste niemals auf das Datenverzeichnis einer laufenden Engine.
Eine schreibfähige Anmeldeinformation auf einer kompromittierten Maschine ist eine schreibfähige Anmeldeinformation für den Angreifer. Erzwingen Sie Append-only auf dem Ziel, oder holen Sie die zweite Kopie per Pull statt per Push.
forget ohne prune markiert nur Snapshots und gibt keinen Platz frei. Führen Sie beide zusammen aus, halten Sie auf dem Ziel freien Speicherplatz vor, und sichern Sie niemals Container-Images oder node_modules.
Der Timer scheiterte nach einem Upgrade, und nichts hat das gemeldet. Fügen Sie eine OnFailure=-Unit hinzu, und prüfen Sie einmal im Monat den Anfang der Snapshot-Liste — das dauert zehn Sekunden.
Ein Bind-Mount außerhalb von /opt, ein während einer Migration verschobenes Volume, ein Exclude-Muster, das mehr erfasst hat als beabsichtigt. Listen Sie bei jedem neuen Snapshot einen bekannten Pfad auf, und lesen Sie die Include-Datei nach jeder Änderung am Stack erneut.
Zehn Fragen, die beim Einrichten aufkommen — und zwei, die erst danach auftauchen, einmalig.
Nein — es ist ein Rollback, und ein nützlicher, aber er versagt genau in den Momenten, für die ein Backup existiert. Ein Snapshot liegt im selben Provider-Konto wie der Server, den er kopiert. Wird das Konto gesperrt, wird eine Zahlung angefochten, vertippt sich ein Support-Mitarbeiter bei einer Löschung, oder erbeutet ein Angreifer Ihre Panel-Zugangsdaten, geht der Snapshot mit der Maschine verloren. Er bietet auch nichts Granulares: Sie können keine einzelne gelöschte Datei von gestern herausziehen, sondern nur die gesamte Platte zurückrollen und alles seither verlieren. Behalten Sie Snapshots — sie sind der schnellste Weg, ein schlechtes Upgrade rückgängig zu machen —, aber verwechseln Sie sie nicht mit einer Kopie, die irgendwo existiert, wo das ursprüngliche Problem nicht hinreicht. Die Faustregel: Kann eine kompromittierte Anmeldeinformation beide Kopien zerstören, haben Sie nur eine Kopie.
Beide verschlüsseln clientseitig, beide deduplizieren auf Chunk-Ebene, beide sind ausgereift, und beide erledigen die Aufgabe. Wählen Sie restic, wenn Sie eine einzelne statische Binärdatei wollen, ein Repository, das auf SFTP, S3-kompatiblem Objektspeicher, einem REST-Server oder allem, was rclone erreicht, liegen kann, und auf dem Ziel überhaupt nichts installiert sein muss. Wählen Sie Borg, wenn das Ziel eine SSH-Maschine ist, die Sie kontrollieren, Sie die stärkste verfügbare Append-only-Durchsetzung ohne Object-Lock-Speicher wollen, und Ihnen die etwas straffere Kompression zusagt. Die praktischen Unterschiede, die den Ausschlag geben: Borg braucht borg installiert auf beiden Seiten und spricht nur SSH oder einen lokalen Pfad; restic braucht einen Prune-Durchlauf, der kurzzeitig eine exklusive Sperre auf das Repository legt. Können Sie sich nicht entscheiden, nehmen Sie restic — weniger bewegliche Teile auf dem Ziel sind mehr wert als jeder Benchmark.
Gehen Sie von der Größe dessen aus, was Sie tatsächlich sichern — nicht von der Größe der Festplatte, auf der es liegt. Ein typischer Self-Hosting-Stack besteht aus ein paar Gigabyte Datenbank und Konfiguration plus dem, was die Nutzer hochgeladen haben. Deduplizierung und Komprimierung zahlen sich dann aus: Ein täglicher Snapshot eines 20-GB-Arbeitsbestands mit zwölfmonatiger Aufbewahrungsrichtlinie landet meist zwischen 40 und 80 GB Repository-Größe, weil nur geänderte Chunks je zweimal gespeichert werden. Ein Sentinel ($3.90/Monat, 120 GB NVMe) deckt das bequem ab. Wechseln Sie zu einem Garrison (240 GB, $7.90), wenn mehrere Server in denselben Repository-Host sichern, und zu einem Bulwark (960 GB, $32.90), wenn der Arbeitsbestand selbst mehrere Hundert Gigabyte umfasst. Bemessen Sie das Repository und verdoppeln Sie den Wert dann — ein Repository ohne freien Platz kann kein Pruning durchführen, und ein Repository, das kein Pruning durchführen kann, wächst nur noch.
Sie können sie kopieren. Wiederherstellen können Sie sie damit vielleicht nicht. Eine Datenbank, die schreibt, während Sie lesen, liefert Ihnen einen Dateisatz aus mehreren verschiedenen Momenten — das ist die Definition eines zerrissenen Backups. Es stellt sich als beschädigte Datenbank wieder her, oder schlimmer, als Datenbank, die klaglos öffnet und dabei still und leise Zeilen vermisst. Die Lösung ist ein Dump: pg_dump oder pg_dumpall für PostgreSQL, mariadb-dump --single-transaction für MariaDB und MySQL auf InnoDB-Tabellen, sowie sqlite3 db .backup out.db oder VACUUM INTO für SQLite. Schreiben Sie den Dump in eine Datei und sichern Sie dann die Datei. Ist die Datenbank zu groß für einen nächtlichen Dump, sind die Alternativen ein Dateisystem-Snapshot bei kurz pausierter Engine oder das physische Backup-Werkzeug der Engine selbst — aber für alles, was ein einzelner VPS betreibt, ist ein Dump richtig und einfach.
Die Backups sind weg. Sowohl restic als auch Borg verschlüsseln clientseitig, und keines von beiden bietet einen Wiederherstellungsweg, einen Hauptschlüssel oder ein Support-Ticket, das ein Repository für Sie entsperrt. Das ist der Sinn der Sache: Der Ziel-Host — auch einer, der nicht Ihnen gehört — bekommt Ihren Klartext nie zu sehen. Das bedeutet auch, dass die Passphrase jetzt ein Datenelement ist, das genau so viel wert ist wie alles, was sie schützt, und sie darf nicht nur auf der gesicherten Maschine liegen. Bewahren Sie sie in Ihrem Passwortmanager auf, und legen Sie eine Kopie physisch irgendwo ab. Exportieren Sie bei Borg zusätzlich den Repository-Schlüssel mit borg key export und bewahren Sie ihn separat auf; im Modus repokey lebt der Schlüssel innerhalb des Repositorys, sodass ein Repository, das Sie nicht mehr erreichen, den Schlüssel mit sich nimmt.
Sie geben ihr ein Credential, das hinzufügen, aber nicht entfernen kann. Das ist die mit Abstand wichtigste Designentscheidung der ganzen Übung, denn moderne Ransomware sucht zuerst nach der Backup-Konfiguration und folgt ihr nach Hause. Drei Wege, das zu erreichen. Append-only über SSH: Erzwingen Sie in den authorized_keys des Ziels den Befehl borg serve --append-only --restrict-to-path /srv/borg — die Quelle kann neue Archive schreiben und keine alten löschen. Append-only über REST: Betreiben Sie restics rest-server mit --append-only und richten Sie das Repository per HTTPS darauf aus. Object Lock: ein S3-kompatibler Bucket mit Versionierung und einer Aufbewahrungssperre. Reines SFTP bietet nichts davon — ein Schlüssel, der ein Repository schreiben kann, kann es auch löschen —, wenn SFTP also Ihr Transport ist, kombinieren Sie es mit einer Pull-basierten zweiten Kopie von der Zielseite aus, wohin die auf der Quelle erbeuteten Zugangsdaten eines Angreifers nicht reichen.
Stellen Sie die Frage andersherum: Wie viel Arbeit sind Sie bereit, noch einmal zu machen? Diese Zahl ist Ihr Recovery Point Objective, und sie bestimmt das Intervall. Nächtlich ist für fast jeden selbstgehosteten Dienst richtig — einen Mailserver, ein Nextcloud, einen Matrix-Homeserver, eine Workflow-Engine. Stündlich lohnt sich, wenn die Daten transaktional sind und eine erneute Eingabe unmöglich ist. Für die Aufbewahrung ist das Muster, das den Kontakt mit der Realität übersteht, --keep-daily 7 --keep-weekly 4 --keep-monthly 12: eine Woche granulares Rückgängigmachen, ein Monat wöchentlicher Prüfpunkte, ein Jahr monatlicher, macht rund 23 Snapshots. Der lange Ausläufer zählt mehr, als man erwartet, denn der Fehler, den er auffängt, ist keine tote Platte — es ist eine Beschädigung oder Löschung, die sechs Wochen lang niemandem aufgefallen ist.
Ein anderes Gebäude ist das technische Minimum; eine andere Rechtsordnung ist der Teil, den die meisten überspringen und später bereuen. Ein Feuer, eine Überschwemmung oder ein Ausfall auf Rack-Ebene wird allein durch Entfernung beantwortet. Was Entfernung nicht beantwortet, ist Rechtliches oder Geschäftliches: ein von einem Anbieter gesperrtes Konto, ein Zahlungsstreit, eine Abmahnung, die jede Maschine unter demselben Firmendach erreicht, eine Anordnung, die einem Unternehmen zugestellt wird. Liegen beide Kopien beim selben Anbieter, erreicht ein Brief beide. Das Paar über zwei nordische Bastionen aufzuteilen — die Arbeitsmaschine in Helsinki, das Repository in Reykjavík, 30 ms voneinander entfernt auf dem Backbone — kostet nichts an Latenz und kauft einen zweiten rechtlichen Rahmen. Die Daten werden so oder so verschlüsselt, bevor sie die Quelle verlassen, sodass das Ziel nichts erfährt, indem es sie hält.
Verschlüsselung ist nicht der Flaschenhals — moderne CPUs erledigen AES schneller, als eine Gigabit-Leitung das Ergebnis transportieren kann, und beide Werkzeuge nutzen Hardwarebeschleunigung, wo sie vorhanden ist. Der Flaschenhals ist der erste Upload, weil alles neu ist: Auf einer 1-Gbps-Anbindung braucht ein 20-GB-Arbeitsdatensatz bei voller Leitungsrate ein paar Minuten, und deutlich länger, wenn das Ziel gedrosselt ist oder die Dateien zahlreich und klein sind. Jeder folgende Lauf überträgt nur die Chunks, die sich geändert haben, was bei einem typischen Stack einigen Dutzend Megabyte entspricht und in unter einer Minute fertig ist. Konkurriert der erste Lauf mit einer Produktionslast, drosseln Sie ihn — restic nimmt --limit-upload in KiB/s, Borg nimmt --upload-ratelimit — und lassen Sie ihn unter nice und ionice laufen.
Ja, und der Grund ist keine Paranoia — es liegt daran, dass die häufigsten Ausfälle lautlos sind. Der Timer, der nach einem Paket-Upgrade aufgehört hat zu feuern. Das Exclude-Muster, das stillschweigend das Uploads-Verzeichnis verschluckt hat. Der Datenbank-Dump, der in einen Pfad geschrieben wurde, den das Backup nie erfasst hat. Das Repository, dessen Integritätsprüfung seit Wochen fehlschlägt, in ein Log, das niemand liest. Keines davon kündigt sich an; alle werden in neunzig Sekunden gefunden, indem man eine Datei wiederherstellt und sie sich ansieht. Machen Sie monatlich eine kleine Wiederherstellung — ziehen Sie einen Datenbank-Dump und ein Datenverzeichnis in einen Testpfad und vergleichen Sie sie per diff — und einmal im Jahr einen vollständigen, zeitgemessenen Wiederaufbau auf einem frischen VPS. Die Zahl, die bei diesem Wiederaufbau herauskommt, ist Ihre echte Recovery-Zeit, und es ist selten die Zahl, die man geraten hätte.
Sentinel — 120 GB NVMe für $3.90 im Monat, in Helsinki, Stockholm, Oslo oder Reykjavík. Unbegrenzte Bandbreite, sodass die Wiederherstellung nichts kostet. Keine E-Mail bei der Anmeldung, kein Ausweisdokument, und ein Ziel, das kein einziges Byte dessen lesen kann, was es speichert.
Zuletzt überprüft · 2026-08-24 · Quellen · restic- und BorgBackup-Dokumentation, PostgreSQL- und MariaDB-Backup-Handbücher, sshd authorized_keys(5), systemd.timer(5) · Rhythmus · jährlich
This guide is one spoke of a larger series. The pillar walks the three privacy layers end to end — the sibling spokes below dive into the specifics.
Three independent layers — signup, payment, network — explained, legal context included, common mistakes flagged.
SSH keys, ufw, fail2ban, kernel knobs, unattended-upgrades.
Deploy your own MCP server on a no-KYC VPS — TLS, streamable HTTP, OAuth.
Host an MCP server with no ID — the privacy stack, crypto-paid.
Verlagern Sie den Agenten vom Laptop — Dimensionierung, systemd, Secrets, Ausgabenobergrenzen.