Eine Backup-Strategie wird nie in der Nacht getestet, in der der Server stirbt. Getestet wird sie Wochen vorher, in drei stillen Entscheidungen, die niemand aufschreibt: wohin die Kopie geht, wer sie löschen darf, und ob überhaupt schon einmal jemand eine zurückgelesen hat.
Hosting, das nie nach Ihrer Identität gefragt hat, gibt im Gegenzug etwas auf, und das sagen wir hier offen. Es gibt keinen Account-Manager anzurufen, kein Ticket, das ein gelöschtes Volume wiederbelebt, und unsere eigene Aufbewahrungsrichtlinie ist unverblümt in ihrer Begründung: Serverdaten werden innerhalb von 24 Stunden nach Kündigung vernichtet, Festplatten werden kryptografisch gelöscht statt formatiert, und es werden keine Backups aufbewahrt. Genau diese Eigenschaft macht die Plattform lohnenswert – von der anderen Seite betrachtet. Alles, was Sie nach einer schlechten Nacht zurückhaben wollen, muss bereits woanders liegen, und Sie sind es, der es dorthin bringt.
Was Server wirklich zerstört
Fast niemand verliert einen Server so, wie er es sich vorstellt. Ein katastrophaler Hardwaredefekt kommt vor, ist aber selten, und genau dagegen hat ein kompetenter Anbieter längst vorgesorgt. Die Verluste, die tatsächlich passieren, sind unspektakulärer, und jeder einzelne besiegt eine andere Art von Kopie – weshalb „ich habe ein Backup" erst dann eine Antwort ist, wenn Sie sagen, welchen dieser Fälle es übersteht.
| Was schiefgeht | Wie es meist passiert | Was Sie rettet |
|---|---|---|
| Die eigene Hand | Ein rm -rf bei leerer Shell-Variable, eine Migration, die auf Produktion zeigte, ein Deploy, das die falsche Tabelle gelöscht hat | Jede Kopie außerhalb des Servers von vor dem Fehler – die Aufbewahrung muss also weiter zurückreichen als die Zeit, bis Sie es bemerken |
| Stille Korruption | Eine sterbende NVMe, ein abgebrochener Schreibvorgang beim Reboot, eine Datenbank, die seit einer Woche beschädigte Zeilen schreibt | Versionierte Kopien, die tief genug zurückreichen, um einen bekannt guten Stand zu erreichen. Eine einzelne gespiegelte Kopie spiegelt den Schaden originalgetreu mit |
| Kompromittierung | Ein gestohlener Schlüssel, eine ungepatchte Anwendung, eine vergiftete Abhängigkeit – und danach, ganz gezielt, Ihre Backups | Eine Kopie, die die kompromittierte Maschine gar nicht löschen konnte. Nur das zählt hier |
| Ein Vorfall beim Anbieter oder im Land | Hardwareverlust, ein rechtlicher Schritt im Rechenzentrum, ein Account oder Token, den Sie nicht mehr erreichen | Eine Kopie, die weder bei diesem Anbieter noch unter dieser Jurisdiktion liegt |
| Den Schlüssel verlieren | Eine vergessene Passphrase, eine Keyfile, die mit dem Server gelöscht wurde, den sie schützte, ein LUKS-Header, den niemand exportiert hat | Nichts. Das ist die einzige Zeile ohne Spalte zur Rettung, und sie kommt häufiger vor als Hardwareversagen |
Lesen Sie diese Tabelle als Checkliste, nicht als Liste von Befürchtungen. Eine nächtliche Kopie auf eine zweite Platte in derselben Maschine beantwortet Zeile eins und sonst nichts. Ein Snapshot im selben Panel beantwortet Zeile eins und zwei. Nur eine Kopie, die irgendwo liegt, wo der Server sie nicht erreichen kann, unter einem Schlüssel, den Sie noch besitzen, beantwortet alle fünf.
Ein Snapshot ist kein Backup – und Ihr Hoster ist auch keins
Snapshots sind hervorragend in dem, was sie tun: Sie machen ein missglücktes Upgrade in Sekunden rückgängig, ohne Datenübertragung. Was sie nicht können, ist das zu überleben, was den Server erwischt hat, denn sie teilen jede Fehlerdomäne mit ihm – denselben Anbieter, denselben Account, dasselbe Zahlungstoken, dasselbe Land, oft denselben Storage-Cluster. Ein Snapshot schützt Sie vor sich selbst. Ein Backup schützt Sie vor allem anderen.
Dieser Unterschied wiegt hier schwerer als bei einem gewöhnlichen Hoster, weil die üblichen Sicherheitsnetze absichtlich entfernt wurden. Niemand loggt sich auf Kundenservern ein, also bemerkt niemand, dass Ihr Backup-Job seit März fehlschlägt. Es hängt keine Identität am Account, also gibt es keinen menschlichen Weg zu „weisen Sie nach, wer Sie sind, und wir stellen es wieder her". Und eine Kündigung ist wirklich endgültig: ein abgelaufenes Guthaben ist ein Datenverlust-Ereignis, kein Abrechnungsereignis.
Die 24-Stunden-Klausel ist das ganze Argument. Auf dieser Plattform werden die Daten eines gekündigten Servers innerhalb eines Tages vernichtet, und die Festplatten werden kryptografisch gelöscht statt formatiert. Es gibt kein Undelete, keine stille Cold-Storage-Stufe, kein Support-Ergebnis, das mit „wir haben eine ältere Kopie gefunden" endet – denn eine solche zu behalten würde bedeuten, Ihre Daten zu speichern, nachdem Sie uns darum baten, es nicht zu tun. Das Sicherheitsnetz und die Privatsphäre sind derselbe Kompromiss, ein für alle Mal geschlossen.
3-2-1, neu geschrieben für Leute, die nie einen Ausweis gezeigt haben
Die klassische Regel besagt: drei Kopien, auf zwei Arten von Medien, eine davon außer Haus. Sie stammt aus einer Ära von Bandlaufwerken und rotierenden Platten, und die Medien-Klausel hat still und leise aufgehört, etwas zu bedeuten: Ihre Produktionsplatte ist NVMe, die Platte des Backup-Ziels ist NVMe, und das „zwei Medien" zu nennen ist eine Geschichte, die Sie sich selbst erzählen. Die Klausel, die es zu behalten lohnt, ist die über Distanz, und bei Offshore-Infrastruktur wird Distanz nicht in Kilometern gemessen.
Schreiben Sie sie um zu drei Kopien, zwei Anbieter, zwei Jurisdiktionen. Die Ausfälle, die beide Kopien gleichzeitig vernichten, sind fast nie physischer Natur – es ist ein Account, zu dem Sie den Zugang verloren haben, ein Anbieter, der eine schlechte Woche hatte, oder ein rechtliches Instrument, das in einem Land greift und in einem anderen keine Reichweite hat. Zwei Server im selben Rack sind eine Kopie mit Umwegen; zwei Server unter demselben Rechtssystem sind kaum besser. Unser Leitfaden zur Jurisdiktionswahl erklärt, wie Sie eine zweite auswählen, die nicht einfach die Risiken der ersten spiegelt.
In der Praxis ist das günstig. Ein Backup-Ziel braucht keine Kerne, und kaum ein Netzwerk – es braucht Speicherplatz und eine Adresse. Die kleinste VPS-Stufe an einem anderen unserer sieben Standorte ist ein kompetenter restic- oder Borg-Endpunkt, und für Archive im Terabyte-Bereich kostet eine dedizierte Maschine mit echten Laufwerken weniger pro Terabyte als jeder Objektspeicher. Wo die Daten wirklich groß sind und selten gelesen werden, spricht die Wirtschaftlichkeit deutlich für Bare Metal.
Eines machen viele bei der Produktion richtig und beim Backup-Ziel falsch: genauso dafür bezahlen. Ein zweiter Server, gekauft mit einer Karte auf den eigenen Namen, verknüpft still die Identität wieder, die Sie sich beim ersten Server mühsam abgetrennt haben – und er enthält nun eine vollständige Kopie von allem darauf. Wenn die Produktionsmaschine in Monero bezahlt wird, verdient die Backup-Maschine dieselbe Behandlung.
Die dritte Kopie ist die, die die meisten überspringen, und die einzige, die gegen jeden Remote-Ausfall gleichzeitig immun ist: eine Platte, die Sie physisch in der Hand halten, gelegentlich aktualisiert, offline aufbewahrt. Einmal im Monat reicht den meisten. Es kostet die Aufmerksamkeit einer Kaffeepause, und es ist die Kopie, die genau die Szenarien übersteht, die den anderen beiden gemeinsam zum Verhängnis werden.
Push, Pull, und der Fehler, durch den eine schlechte Nacht beide Kopien frisst
So sieht die Konstruktion aus, die fast jeder zuerst baut. Ein Job auf dem Produktionsserver läuft jede Nacht, hält einen Schlüssel oder ein Token für das Backup-Ziel, verbindet sich und pusht. Es funktioniert, es ist einfach, und es hat eine Eigenschaft, die erst am schlimmsten Tag im Leben des Servers sichtbar wird: Wer die Produktionsmaschine kontrolliert, kontrolliert auch die Backups.
Das ist keine Theorie. Die Backups des Opfers zu löschen oder zu verschlüsseln, bevor man sich zu erkennen gibt, ist gängige Praxis für jeden, der das kommerziell betreibt – die Zugangsdaten liegen in einem Cron-Job oder einer Environment-Datei, und sie zu finden dauert etwa eine Minute. Eine Kopie, die Ihr Angreifer löschen kann, ist keine zweite Kopie. Sie ist ein Spiegel der ersten mit Verzögerung.
Es gibt zwei saubere Lösungen, und sie fügen sich gut in das grundlegende Hardening ein, das Sie bereits erledigt haben sollten.
- Append-only-Ziele. Beide großen Tools unterstützen einen Modus, in dem ein Client Daten hinzufügen, aber nicht entfernen kann. Borg erreicht das, indem der SSH-Schlüssel auf dem Ziel auf
borg serve --append-onlyfestgelegt wird; restic erreicht es mit einem REST-Server, gestartet mit--append-only. Der Produktionsserver schreibt jede Nacht und ist strukturell unfähig, Historie zu zerstören. Das Bereinigen alter Snapshots geschieht dann auf dem Ziel, in einer Sitzung, die die Produktionsmaschine nicht starten kann. - Pull statt Push. Die Richtung umkehren: Der Backup-Host verbindet sich mit der Produktion, liest und speichert. Die Produktion hält überhaupt keine Zugangsdaten für das Ziel, also gibt es nichts zu stehlen. Beschränken Sie den Schlüssel, den sie auf der Produktionsseite nutzt, mit
restrictund einem erzwungenencommand=, damit ein gestohlener Backup-Schlüssel keine Shell werden kann.
Pull ist das stärkere Modell und etwas aufwendiger im Betrieb; Append-only ist praktisch kostenlos, wenn Sie bereits Borg oder restic nutzen. Beides macht aus „der Angreifer hat meine Backups gelöscht" ein gescheitertes Vorhaben statt ein Ergebnis. Wenn Sie nur eine Sache aus diesem Leitfaden mitnehmen, dann diesen Abschnitt.
Verschlüsseln an der Quelle, dann entscheiden, wer den Schlüssel hält
Beide ernstzunehmenden Tools verschlüsseln auf der Maschine, die gesichert wird, bevor irgendetwas das Netzwerk überquert. Das Ziel speichert Blobs, die es nicht interpretieren kann – genau das macht die anbieterübergreifende Kopie sicher. Ihr zweiter Host muss nicht vertrauenswürdig sein, nicht einmal freundlich; er muss nur erreichbar sein und Speicherplatz haben. Genau diese eine Eigenschaft macht aus „einem Server in einem Land, über das ich nichts weiß" ein Stück Infrastruktur statt ein Risiko.
Das ist ein anderer Mechanismus als die Verschlüsselung der eigenen Serverplatte, und beide beantworten unterschiedliche Fragen – unser Leitfaden zur Vollverschlüsselung auf einem VPS arbeitet durch, was Festplattenverschlüsselung schützt und was nicht, während die Maschine läuft. Backup-Verschlüsselung ist die einfachere und wertvollere der beiden, weil das Bedrohungsmodell ehrlich ist: Die Daten liegen im Ruhezustand auf Hardware, die Sie nicht kontrollieren, und der Schlüssel gelangt niemals dorthin.
Womit das gesamte Risiko auf die Schlüsselverwahrung verlagert wird. Die Passphrase ist jetzt ein einzelner Punkt vollständigen Verlusts, und ein schlimmerer, als man erwarten würde, denn ihr Verlust ist lautlos – nichts bricht, Backups laufen weiter, und Sie erfahren es genau in dem Moment, in dem Sie sie gebraucht hätten. Drei Gewohnheiten beheben das:
- Die Passphrase auf dem Server nur als Datei aufbewahren, die ausschließlich root lesen kann, referenziert mit
--password-file, damit sie nie in einer Prozessliste oder Shell-History auftaucht. - Eine menschenlesbare Kopie fernab jeder beteiligten Maschine aufbewahren. Papier in einer Schublade schlägt tatsächlich einen Passwort-Manager, der mit einem Account synchronisiert, zu dem Sie ebenfalls den Zugang verlieren könnten.
- Einen zweiten Schlüssel zum Repository hinzufügen –
restic key add, oder ein exportierter Borg-Schlüssel –, damit eine vergessene Passphrase ein Ärgernis ist und nicht das Ende des Archivs.
Die Regel hinter allen dreien: wenn die einzige Kopie des Schlüssels auf der Maschine liegt, die das Backup ersetzen soll, haben Sie kein Backup. Sie haben einen verschlüsselten Haufen Blöcke und eine Geschichte darüber.
Ein Werkzeug wählen, in einer Tabelle
Die Wahl des Tools zählt weniger als die Richtung der Verbindung und der Zustand Ihres Schlüssels, weshalb sie hier an sechster statt an erster Stelle steht. Trotzdem sind die Unterschiede real, und die falsche Form für die Aufgabe zu wählen, schafft später Arbeit.
| Tool | Verschlüsselt vor dem Verlassen | Dedupliziert | Append-only-Ziel | Wofür geeignet |
|---|---|---|---|---|
| restic | Ja, gesamtes Repository | Ja | Ja, über den eigenen REST-Server | Die Standardwahl. Spricht SFTP, Objektspeicher und den eigenen Server, sodass das Ziel fast alles sein kann |
| BorgBackup | Ja, gesamtes Repository | Ja, das beste der Gruppe | Ja, nativ über SSH | Ein Linux-Ziel, erreicht über SSH. Unschlagbar, wenn die Daten groß und repetitiv sind |
| rsync mit Rotation | Nein – das Ziel sieht alles | Teilweise, über Hardlinks | Nein | Spiegelung auf eine Maschine, die vollständig Ihnen gehört, wenn sofortige Teil-Restores wichtiger sind als Privatsphäre |
| rclone | Nur mit rclone crypt | Nein | Abhängig vom Storage-Anbieter | Ein bereits bestehendes Archiv in Objektspeicher verschieben, oder zwischen Anbietern |
| ZFS-Replikation | Nur mit verschlüsseltem Dataset | Ja, auf Blockebene | Über Snapshot-Berechtigungen | Replikation zwischen zwei ZFS-Maschinen. Sehr schnell, sehr starr an beiden Enden |
| tar mit age oder GPG | Ja, wenn Sie das Archiv verschlüsseln | Nein | Nicht zutreffend | Kleine, gelegentliche, dauerhaft aufbewahrte Archive, bei denen Einfachheit wichtiger ist als Effizienz |
Für einen einzelnen Server ist restic auf einen zweiten VPS der kürzeste Weg zu etwas Korrektem. Für eine Seedbox, ein Medienarchiv oder alles mit vielen ähnlichen großen Dateien ist die Deduplizierung von Borg der Unterschied zwischen einer vollen und einer komfortablen Platte – der Seedbox-Leitfaden behandelt die Speicherseite dieser Last ausführlicher.
Was läuft, ist keine Datei
Das häufigste kaputte Backup der Welt ist eine simple Dateikopie einer laufenden Datenbank. Sie schließt ohne Fehler ab, hat die richtige Größe, und beim Wiederherstellen entsteht eine Tabelle, die die Engine sich weigert zu öffnen. Die Datenbank war mitten im Schreibvorgang, als die Kopie durchlief; was Sie gesichert haben, ist eine Aufnahme einer Seite im Moment des Umblätterns.
Drei Auswege, in aufsteigender Reihenfolge des Aufwands. Dumpen: mysqldump --single-transaction liefert einen konsistenten InnoDB-Dump, ohne Schreiber zu blockieren, und pg_dump leistet dasselbe für PostgreSQL. Snapshotten: das Dateisystem einfrieren oder einen LVM- oder ZFS-Snapshot ziehen, aus dem Snapshot kopieren, ihn freigeben – so behandelt man Datenmengen, die zu groß sind, um sie nächtlich zu dumpen. Oder stoppen: Bei einem kleinen Dienst sind zwei Minuten Ausfallzeit um 04:00 Uhr eine durchaus respektable Konsistenzstrategie, und die einzige ohne Sonderfälle.
Dieselbe Logik reicht über Datenbanken hinaus. Der beschreibbare Layer eines Containers ist verzichtbar, seine Volumes sind es aber nicht, ebenso wenig wie die docker compose-Datei und die Umgebung daneben – ein Backup, das die Daten wiederherstellt, aber nicht die Definition, lässt Sie den Stack aus dem Gedächtnis rekonstruieren. Message-Queues, Redis mit aktivierter Persistenz und ein von einem MTA beschriebener Mail-Spool verdienen alle dieselbe Behandlung: ruhigstellen, snapshotten oder dumpen, aber niemals einfach kopieren und hoffen.
Was zu sichern ist, und die Teile, die alle vergessen
Die meisten sichern die offensichtliche Nutzlast – die Datenbank und das Anwendungsverzeichnis – und bauen den Rest unter Druck von Hand wieder auf. Genau im Wiederaufbau gehen die Stunden drauf. Ein Backup, das Sie zu einem funktionierenden System zurückbringt und nicht nur zu einem Haufen korrekter Daten, umfasst die unspektakuläre Schicht:
/etcvollständig, dazu die selbst geschriebenen systemd-Units und Timer, sowie jede Crontab, die außerhalb davon liegt.- TLS-Zertifikate und ihre privaten Schlüssel, oder mindestens der ACME-Account-Key, damit Zertifikate erneuert werden, statt bei null neu anzufangen.
- Firewall-Regeln und die Paketliste, die zusammen die Form der Maschine schneller rekonstruieren als jede Erinnerung daran.
- Anwendungs-Secrets und Umgebungsdateien – jene, die bewusst aus dem Code-Repository ausgeschlossen sind und deshalb sonst nirgends existieren.
- DNS-Einträge als Text exportiert, einschließlich Reverse-DNS- und PTR-Einträgen, die beim Anbieter liegen und nicht auf dem Server.
Manche Schlüssel sind keine Daten – sie sind Identität. Der private Schlüssel eines Tor-Onion-Dienstes ist die Adresse: Verlieren Sie ihn, kann die Seite nicht unter demselben .onion-Namen zurückkehren, egal was sonst wiederhergestellt wurde. Ein WireGuard-Serverschlüssel bedeutet, jede jemals ausgegebene Client-Konfiguration neu auszustellen. Der DKIM-Schlüssel eines Mailservers bedeutet einen neuen Selector und einen Neustart bei der Zustellbarkeit. Seed und Channel-Zustand eines Lightning-Nodes können Guthaben bedeuten, nicht nur Dateien – der Leitfaden zum Hosting von Crypto-Nodes ist darin explizit. Kopieren Sie diese separat, bewahren Sie sie offline auf und behandeln Sie sie als wertvoller als die Daten, die sie schützen.
Ein ungetesteter Restore ist ein Gerücht
Backup-Software berichtet über sich selbst, und sie berichtet ehrlich über das Falsche. „Snapshot abgeschlossen" bedeutet, dass Daten in ein Repository geschrieben wurden. Es sagt nichts darüber, ob das Repository auf einer anderen Maschine als dieser gelesen werden kann, von jemandem, der sich nicht mehr erinnert, was er vor elf Monaten konfiguriert hat.
Beginnen Sie mit den günstigen Integritätsprüfungen – restic check --read-data-subset=5% oder borg check --verify-data nach Zeitplan – und verstehen Sie, dass diese das Archiv verifizieren, nicht Ihre Fähigkeit, es zu nutzen. Die eigentliche Übung ist anders und dauert einmalig einen Nachmittag. Bestellen Sie einen frischen Server stundenweise an einem Standort, den Sie sonst nicht nutzen. Stellen Sie darauf wieder her, mit nichts als der Repository-Adresse, der Passphrase und Ihren eigenen Notizen. Bringen Sie den Dienst hoch. Stoppen Sie die Zeit für das Ganze. Zerstören Sie dann die Maschine. Gesamtkosten: ein paar Dollar, und es ist die einzige Übung, die eine Zahl liefert, der Sie trauen können.
Was sie zuverlässig aufdeckt, sind nie die Daten. Es ist das fehlende Paket, das niemand notiert hat, die Konfiguration, die außerhalb der gesicherten Pfade lag, die Passphrase, die nur in der Shell-History des Servers existierte, den Sie ersetzen wollen, und die Tool-Version, die Ihr Repository-Format liest. Jedes davon ist im Voraus trivial zu beheben und während eines Ausfalls unangenehm zu entdecken.
Notieren Sie sich die beiden Zahlen, die die Übung liefert: wie lange ein Restore gedauert hat, und wie viel Arbeit der Zeitplan verlieren kann. Das ist die Backup-Policy. Alles darüber ist Umsetzungsdetail in ihrem Dienst.
Automatisieren, damit es dauerhaft passiert
Lassen Sie den Job über einen systemd-Timer laufen statt über cron. Sie bekommen Logs an einem Ort, einen echten Nachweis des letzten Laufs und einen Zeitplan, der Reboots übersteht – nichts davon liefert cron ohne zusätzlichen Aufwand. Halten Sie die Passphrase aus der Unit-Datei selbst heraus, denn die kann jeder mit Shell-Zugriff direkt aus systemctl cat auslesen.
Lösen Sie dann den Fehlermodus, der tatsächlich zuschlägt – kein Fehler, sondern Stille. Ein Backup, das seit sechs Wochen nicht mehr läuft, sieht genau aus wie eines, das perfekt gelaufen ist, denn beide erzeugen keine Ausgabe. Alarmieren Sie bei Abwesenheit, nicht bei Fehlschlag. Lassen Sie den Job bei Erfolg einen Monitor anpingen, und lassen Sie den Monitor sich melden, wenn der Ping ausbleibt – und platzieren Sie diesen Monitor überall außer auf dem Server, den er überwacht, denn eine Maschine, die down ist, kann nicht melden, dass sie down ist.
Setzen Sie die Aufbewahrung bewusst fest statt nach Standardwerten. Etwas wie --keep-daily 7 --keep-weekly 4 --keep-monthly 6 deckt die Fehler ab, die Sie heute Nacht bemerken, und die Korruption, die Sie im Frühling bemerken, ohne endlos zu wachsen. Führen Sie das Bereinigen auf der Zielseite aus, wenn Sie append-only gegangen sind – genau das ist der Sinn von append-only. Übertragungsvolumen ist in unserem Netzwerk selten die Grenze – die Bandbreite ist bei jedem Plan unbegrenzt – planen Sie also für Konsistenz statt für ein Kontingent, und prüfen Sie das Timing gegen Ihre eigenen ruhigen Stunden. Die weiteren Gewohnheiten rund um all das behandelt der Leitfaden zu Server-OpSec.
Die Kurzfassung
Wenn Sie mit dieser Seite nur eines mitnehmen, dann diese sechs Dinge, ungefähr in dieser Reihenfolge:
- Eine Kopie bei einem zweiten Anbieter platzieren, in einer zweiten Jurisdiktion, genauso privat bezahlt wie die erste.
- Diese Kopie append-only machen, oder vom Ziel aus abholen (pull), damit ein kompromittierter Server sie nicht zerstören kann.
- Das Tool an der Quelle verschlüsseln lassen, und den Schlüssel von beiden beteiligten Maschinen fernhalten.
- Datenbanken dumpen und alles, was läuft, stoppen oder snapshotten; niemals einen laufenden Zustand direkt kopieren.
- Die Identitätsschlüssel separat sichern – Onion, WireGuard, DKIM, Node-Seeds – denn diese lassen sich nicht neu generieren.
- Einmal auf einen Wegwerf-Server wiederherstellen, die Zeit stoppen und notieren, was gefehlt hat.
Nichts davon ist exotisch, und nichts davon braucht ein ganzes Wochenende. Es ist ein Nachmittag Einrichtung und eine Übung, gegen eine Verlustkategorie, die Projekte beendet. Auf einer Plattform, die absichtlich nichts über Sie speichert, ist die Kopie, die Sie selbst angelegt haben, die einzige, die existiert – das ist der Preis der Vereinbarung, und ein fairer. Einen zweiten Server hochfahren in einer Jurisdiktion, die nicht Ihre erste ist, und dem heutigen Backup einen Ort zum Landen geben.