[Startseite](https://servhidden.com/de) / [Datenschutz-Hosting-Leitfäden](https://servhidden.com/de/guides) / VPS-Backup: verschlüsselt, extern und wirklich wiederherstellbar Betrieb # VPS-Backups, die wirklich wiederherstellbar sind No-KYC-Hosting nimmt mit der Bürokratie auch das Sicherheitsnetz weg: keine Backups werden aufbewahrt, Daten werden innerhalb von 24 Stunden nach Kündigung vernichtet, und es gibt keinen Support-Weg, der in einer wiederhergestellten Kopie endet. Das ist der Arbeitsplan: was Sie kopieren, wohin, wie Sie einen Angreifer daran hindern, es zu löschen, und wie Sie beweisen, dass es sich wiederherstellen lässt. [Anleitung lesen](#guide-body) [FAQ](#guide-faq) ## Auf dieser Seite - [Anleitung](#guide-body) - [FAQ](#guide-faq) - [Verwandte Anleitungen](#guide-related) - [Empfohlene Seiten](#guide-cta) Kein KYC Nur Krypto Keine Logs DMCA ignoriert Voller Root-Zugriff NVMe SSD 20 Min. Lesezeit Aktualisiert Aug 2026 Auf dieser Seite [01Was Server wirklich zerstört](#was-server-wirklich-zerstört) [02Ein Snapshot ist kein Backup – und Ihr Hoster ist auch keins](#ein-snapshot-ist-kein-backup-und-ihr-hoster-ist-auch-keins) [033-2-1, neu geschrieben für Leute, die nie einen Ausweis gezeigt haben](#3-2-1-neu-geschrieben-für-leute-die-nie-einen-ausweis-gezeig) [04Push, Pull, und der Fehler, durch den eine schlechte Nacht beide Kopien frisst](#push-pull-und-der-fehler-durch-den-eine-schlechte-nacht-beid) [05Verschlüsseln an der Quelle, dann entscheiden, wer den Schlüssel hält](#verschlüsseln-an-der-quelle-dann-entscheiden-wer-den-schlüss) [06Ein Werkzeug wählen, in einer Tabelle](#ein-werkzeug-wählen-in-einer-tabelle) [07Was läuft, ist keine Datei](#was-läuft-ist-keine-datei) [08Was zu sichern ist, und die Teile, die alle vergessen](#was-zu-sichern-ist-und-die-teile-die-alle-vergessen) [09Ein ungetesteter Restore ist ein Gerücht](#ein-ungetesteter-restore-ist-ein-gerücht) [10Automatisieren, damit es dauerhaft passiert](#automatisieren-damit-es-dauerhaft-passiert) [11Die Kurzfassung](#die-kurzfassung) [FAQHäufige Fragen](#guide-faq) [→Empfohlene Seiten](#guide-cta) 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](https://servhidden.com/de/privacy) 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 Backup-Ziel braucht Speicherplatz und eine Adresse, keine Kerne. Die günstigste zweite Maschine in einer anderen Jurisdiktion ist ein kompetenter Endpunkt – und die einzige Kopie, die einen Vorfall beim ersten Anbieter übersteht. ## 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](https://servhidden.com/de/guides/choosing-an-offshore-jurisdiction) 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](https://servhidden.com/de/vps) an einem anderen unserer [sieben Standorte](https://servhidden.com/de/locations) ist ein kompetenter restic- oder Borg-Endpunkt, und für Archive im Terabyte-Bereich kostet eine [dedizierte Maschine](https://servhidden.com/de/dedicated) 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](https://servhidden.com/de/guides/how-to-pay-for-hosting-with-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](https://servhidden.com/de/guides/first-hour-vps-hardening-checklist) 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-only festgelegt 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 restrict und einem erzwungenen command=, 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](https://servhidden.com/de/guides/full-disk-encryption-on-a-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](https://servhidden.com/de/guides/seedbox-setup-guide) 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: - /etc vollstä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](https://servhidden.com/de/guides/how-to-host-a-tor-hidden-service) 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](https://servhidden.com/de/guides/offshore-mail-server-setup). Seed und Channel-Zustand eines Lightning-Nodes können Guthaben bedeuten, nicht nur Dateien – der [Leitfaden zum Hosting von Crypto-Nodes](https://servhidden.com/de/guides/crypto-node-hosting-guide) 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](https://servhidden.com/de/guides/server-opsec-staying-anonymous). ## 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](https://servhidden.com/de/vps) in einer Jurisdiktion, die nicht Ihre erste ist, und dem heutigen Backup einen Ort zum Landen geben. FAQ ## VPS-Backup – häufige Fragen ### 01 Macht ServHidden Backups von meinem VPS? Nein, und das ist Absicht, kein Versehen. Unsere Aufbewahrungsrichtlinie legt fest, dass keine Backups aufbewahrt werden, dass Serverdaten innerhalb von 24 Stunden nach Kündigung vernichtet werden und dass Festplatten kryptografisch gelöscht statt formatiert werden. Eine Kopie Ihrer Daten zu behalten, nachdem Sie uns baten, sie zu entfernen, würde dem Grund widersprechen, aus dem die Plattform existiert. Alles, was den Server überleben soll, müssen Sie selbst davon herunterkopieren, idealerweise zu einem zweiten Anbieter in einer zweiten Jurisdiktion. ### 02 Ist ein Snapshot dasselbe wie ein Backup? Nein. Ein Snapshot teilt jede Fehlerdomäne mit dem Server, von dem er stammt – denselben Anbieter, denselben Account, dasselbe Land, oft denselben Speicher. Er ist hervorragend, um ein fehlgeschlagenes Upgrade rückgängig zu machen, und nutzlos gegen den Verlust des Accounts, des Anbieters oder der Maschine. Behandeln Sie Snapshots als Rückgängig-Taste und Backups als Versicherung; sie lösen unterschiedliche Probleme, und Sie brauchen beides. ### 03 restic oder BorgBackup – was soll ich nehmen? restic, wenn das Ziel Objektspeicher, SFTP oder noch nicht festgelegt sein könnte, denn es spricht die meisten Backends. BorgBackup, wenn das Ziel eine einzelne Linux-Maschine ist, erreicht über SSH, und die Daten groß und repetitiv sind, denn seine Deduplizierung ist die stärkste der Gruppe. Beide verschlüsseln an der Quelle, bevor irgendetwas die Maschine verlässt, und beide unterstützen ein Append-only-Ziel, was weit mehr zählt als die Wahl zwischen beiden. ### 04 Wie verhindere ich, dass ein Angreifer meine Backups löscht? Nehmen Sie die Möglichkeit, nicht das Motiv. Entweder machen Sie das Ziel append-only, sodass die Zugangsdaten auf dem Produktionsserver Daten hinzufügen, aber nie entfernen können, oder Sie kehren die Verbindung um, sodass der Backup-Host von der Produktion abholt und der Produktionsserver gar keine Zugangsdaten besitzt. Backups zu löschen, bevor man sich zu erkennen gibt, ist gängige Praxis für jeden, der das kommerziell betreibt, und eine Kopie, die Ihr Angreifer löschen kann, ist keine zweite Kopie. ### 05 Wo sollte die zweite Kopie liegen? Bei einem anderen Anbieter, in einer anderen Jurisdiktion, und genauso privat bezahlt wie Ihr Produktionsserver. Die Vorfälle, die beide Kopien gleichzeitig vernichten, sind selten physischer Natur – es ist ein verlorener Account, ein Anbieter mit einer schlechten Woche, oder ein rechtliches Instrument, das ein Land erreicht und ein anderes nicht. Zwei Server im selben Rack sind eine Kopie mit Umwegen. Weil die Tools an der Quelle verschlüsseln, muss der zweite Host kein vertrauenswürdiger sein. ### 06 Wie oft sollte ich ein Backup machen? Rechnen Sie rückwärts von der Arbeit, die Sie bereit sind, noch einmal zu erledigen. Ein Blog kann einen Tag verlieren, ohne dass es jemand merkt; ein Shop darf keine Stunde an Bestellungen verlieren. Nächtlich ist der richtige Standard für die meisten Single-Server-Setups, mit häufigeren Datenbank-Dumps, wenn Schreibvorgänge wertvoll sind. Wichtiger als die Häufigkeit ist die Tiefe der Aufbewahrung: Korruption fällt oft erst Wochen später auf, also bewahren Sie genug Historie auf, um einen Punkt vor ihrem Beginn zu erreichen. ### 07 Ist ein verschlüsseltes Backup auf einem fremden Server sicher? Was den Inhalt betrifft, ja – restic und Borg verschlüsseln, bevor Daten die Quelle verlassen, sodass das Ziel Blobs speichert, die es nicht lesen kann, und der Schlüssel nie dorthin reist. Was das Ziel durchaus erfährt, sind Metadaten: ungefähr wie viel Daten Sie halten, wie sie sich ändern, und wann Ihre Jobs laufen. Das ist meist akzeptabel. Wenn nicht, variieren Sie den Zeitplan und halten Sie das Repository auf einer Maschine, deren Eigentümer nicht mit dem der Produktionsmaschine verknüpft ist. ### 08 Was passiert, wenn ich die Backup-Passphrase verliere? Das Archiv ist unwiederbringlich verloren, ohne jede Möglichkeit der Rettung durch irgendjemanden. Das ist der häufigste Totalverlust im gesamten Thema und der einzige Fehler ohne Rettungsweg. Bewahren Sie die Passphrase fernab jeder beteiligten Maschine auf, bevorzugen Sie Papier gegenüber einem Account, den Sie ebenfalls verlieren könnten, und fügen Sie dem Repository einen zweiten Schlüssel hinzu, damit ein vergessenes Passwort ein Ärgernis ist und nicht das Ende des Archivs. Verwandte Anleitungen ## Weiterlesen [### Wie Sie im Jahr 2026 die richtige Offshore-Hosting-Jurisdiktion wählen Kauf Ein praktischer Entscheidungsrahmen für die Wahl einer Offshore-Jurisdiktion: Datenspeicherungspflicht, MLAT-Exposition, DMCA-Haltung, Reaktionsgeschwindigkeit der Gerichte und reale Durchsetzung — Land für Land. 6-Fragen-FAQ](https://servhidden.com/de/guides/choosing-an-offshore-jurisdiction) [### VPS vs. Dedizierter Server für datenschutzkritische Workloads Kauf Wann ein VPS ausreicht, wann geteilte Mieterschaft zum Risiko wird und wann Bare Metal die einzig ehrliche Antwort ist. Hardware-Isolation, Hypervisor-Risiko und Kosten vs. Bedrohungsmodell. 6-Fragen-FAQ](https://servhidden.com/de/guides/vps-vs-dedicated-for-privacy) [### Selbst gehostetes VPN auf einem No-KYC-VPS: WireGuard vs. OpenVPN Betrieb Warum ein selbst gehostetes VPN kommerziellen Anbietern überlegen ist und wie WireGuard und OpenVPN im Jahr 2026 wirklich bei Datenschutz, Performance und Betriebsrisiko abschneiden. 6-Fragen-FAQ](https://servhidden.com/de/guides/self-hosted-vpn-wireguard-vs-openvpn) [### RTX 4090 vs H100 SXM5 für KI-Inferenz (und wo RTX 5090 passt) Kauf Kaufentscheidungs-Leitfaden: welche NVIDIA-GPU für selbst gehostete LLM-, Bild-, Video-, Sprach- und Fine-Tuning-Workloads im Jahr 2026. RTX 4090 vs RTX 5090 vs H100 SXM5 vs Dual H100 — VRAM, Durchsatz, $/Token, wann jede gewinnt. 6-Fragen-FAQ](https://servhidden.com/de/guides/rtx-4090-vs-h100-for-ai-inference) [### Offshore Windows RDP für MT4 / MT5 / cTrader Forex-Trading Betrieb Vollständiger Leitfaden: Warum ein Windows-RDP für Forex-Trading, wie man eine latenzarme Offshore-Jurisdiktion wählt, MT4 / MT5 / cTrader / Expert-Advisor-Setup, Latenz zu Broker-Servern und der No-KYC-Checkout-Pfad. 6-Fragen-FAQ](https://servhidden.com/de/guides/offshore-windows-rdp-for-forex-trading) [### DMCA-Ignored Hosting erklärt: Was es 2026 wirklich bedeutet Kauf Was „DMCA ignored“ Hosting wirklich bringt, welche Jurisdiktionen das tatsächlich unterstützen, welche Workloads es brauchen — und welche Copyright-Fallen der Begriff nicht abdeckt. 6-Fragen-FAQ](https://servhidden.com/de/guides/dmca-ignored-hosting-explained) [### Anonyme Domain-Registrierung mit Krypto: WHOIS-Datenschutz 2026 Datenschutz Ein praktischer Guide 2026 zur Domain-Registrierung ohne Identitätsoffenbarung: WHOIS-Regime nach TLD, Registrar-Wahl, Coin-Wahl und operative Hygiene. 6-Fragen-FAQ](https://servhidden.com/de/guides/anonymous-domain-registration-with-crypto) [### Krypto-Zahlungen für Hosting: Monero vs. Bitcoin vs. USDT Datenschutz Wie die Wahl der Zahlungswährung beeinflusst, was Ihr Hoster über Sie erfährt. Datenschutz, Gebühren, Abwicklung und Chain-Analyse-Exposition für XMR, BTC und USDT — mit einer klaren Empfehlung. 6-Fragen-FAQ](https://servhidden.com/de/guides/crypto-payments-monero-vs-bitcoin-vs-usdt) [### Ist Offshore-Hosting wirklich anonym? Eine ehrliche Antwort Datenschutz Offshore-Hosting ohne KYC entfernt die Identität, die ein normaler Hoster erfasst – aber „anonym" hängt von der Zahlung, der Protokollierung des Anbieters und Ihrer eigenen Opsec ab. Hier erfahren Sie, was wirklich nachverfolgbar ist. 6-Fragen-FAQ](https://servhidden.com/de/guides/is-offshore-hosting-truly-anonymous) [### Die erste Stunde VPS-Härtung: Eine Checkliste Betrieb Eine konkrete, geordnete Checkliste, um einen neuen VPS in unter einer Stunde abzusichern: SSH-Schlüssel, eine Firewall, fail2ban, automatische Updates und die Reduzierung der Angriffsfläche, die die meisten opportunistischen Angriffe stoppt. 6-Fragen-FAQ](https://servhidden.com/de/guides/first-hour-vps-hardening-checklist) [### Was ist No-KYC-Hosting? Definition, Rechtslage und Funktionsweise Datenschutz Mit No-KYC-Hosting können Sie einen Server mieten, ohne jegliche Identitätsprüfung — kein Name, keine E-Mail, kein Ausweis. Hier erfahren Sie genau, was das bedeutet, wie es technisch funktioniert, ob es legal ist und wie Sie einen seriösen Anbieter erkennen. 6-Fragen-FAQ](https://servhidden.com/de/guides/what-is-no-kyc-hosting) [### Ist Offshore-Hosting legal? Die ehrliche Antwort für 2026 Kauf Offshore-Hosting ist legal – für Sie und für den Anbieter. Hier erfahren Sie, was der Begriff wirklich bedeutet, wo die rechtliche Grenze tatsächlich liegt, welche Mythen Sie getrost vergessen können und wie Sie es verantwortungsvoll nutzen. 6-Fragen-FAQ](https://servhidden.com/de/guides/is-offshore-hosting-legal) [### Hosting mit Monero (XMR) bezahlen – Schritt für Schritt Datenschutz Eine Schritt-für-Schritt-Anleitung zur Bezahlung eines VPS oder dedizierten Servers mit Monero (XMR): warum XMR die privateste Zahlungsmethode ist, wie man es erwirbt und wie der Bezahlvorgang abläuft – vom Rechnungsstellung bis zum laufenden Server in wenigen Minuten. 6-Fragen-FAQ](https://servhidden.com/de/guides/how-to-pay-for-hosting-with-monero) [### Wie man eine Website anonym hostet — Ein praktischer Leitfaden 2026 Datenschutz Ein praktischer, mehrschichtiger Leitfaden zum Hosten einer Website ohne zugeordnete Identität: Konto, Zahlung, Domain, Jurisdiction, Verbindung und Inhalt — jede Schicht ausführlich erklärt. 6-Fragen-FAQ](https://servhidden.com/de/guides/how-to-host-a-website-anonymously) [### WireGuard VPN auf einem VPS einrichten — Schritt-für-Schritt-Anleitung Betrieb Bauen Sie Ihr eigenes privates VPN auf einem VPS mit WireGuard: warum ein selbst gehostetes VPN kommerziellen Angeboten überlegen ist, die vollständige Einrichtung von der Installation bis zum verbundenen Client und wie Sie es absichern. 6-Fragen-FAQ](https://servhidden.com/de/guides/how-to-set-up-wireguard-vpn-on-a-vps) [### LLM auf einem GPU-Server selbst hosten — Leitfaden 2026 Betrieb Betreiben Sie Ihr eigenes Large Language Model auf einem gemieteten GPU-Server: Warum Self-Hosting einer API überlegen ist, welche GPU und welches Modell sich eignen, die Einrichtung mit Ollama oder vLLM und was es kostet. 6-Fragen-FAQ](https://servhidden.com/de/guides/self-host-an-llm-on-a-gpu-server) [### Bulletproof Hosting vs. Offshore Hosting — Was ist der Unterschied? Kauf Bulletproof Hosting und Offshore Hosting werden ständig verwechselt — dabei sind es nicht dasselbe. Hier ist der echte Unterschied, warum er wichtig ist und welches der beiden Sie tatsächlich brauchen. 6-Fragen-FAQ](https://servhidden.com/de/guides/bulletproof-vs-offshore-hosting) [### VPS mit Bitcoin kaufen — Schritt für Schritt (2026) Kauf Eine verständliche Anleitung zum Kauf eines VPS mit Bitcoin: BTC beschaffen, einen Tarif wählen, die Rechnung bezahlen und was Sie erhalten — einen laufenden Server ohne Kreditkarte und ohne hinterlegten Namen. 6-Fragen-FAQ](https://servhidden.com/de/guides/how-to-buy-a-vps-with-bitcoin) [### Die besten Länder für DMCA-ignorierten Hosting im Jahr 2026 Kauf Wo Sie hosten, wenn Ihre Server außerhalb der Reichweite US-amerikanischer Takedown-Mechanismen liegen sollen: die Rechtsordnungen, die funktionieren, was DMCA-ignoriert wirklich bedeutet und wie Sie die richtige Wahl treffen. 6-Fragen-FAQ](https://servhidden.com/de/guides/best-countries-for-dmca-ignored-hosting) [### Tor Hidden Service hosten (.onion-Website) — Anleitung 2026 Betrieb Einen Tor-Onion-Dienst auf einem VPS einrichten: was ein Hidden Service ist, warum er die stärkste Form des anonymen Hostings darstellt, die vollständige Einrichtung und wie man ihn wirklich anonym hält. 6-Fragen-FAQ](https://servhidden.com/de/guides/how-to-host-a-tor-hidden-service) [### Offshore-Mailserver einrichten — Private E-Mails selbst hosten in 2026 Betrieb Betreiben Sie Ihren eigenen privaten Mailserver auf einem Offshore-VPS: Warum E-Mails selbst hosten, was Sie dafür brauchen, die realistische Einrichtung mit einem All-in-One-Mailstack und wie Sie die Zustellbarkeit sicherstellen. 6-Fragen-FAQ](https://servhidden.com/de/guides/offshore-mail-server-setup) [### Krypto-Node-Hosting-Leitfaden — Blockchain-Node auf einem VPS betreiben Betrieb Wie man einen Blockchain-Node auf einem Server hostet: warum man einen eigenen Node betreiben sollte, wie man den Server für Bitcoin, Ethereum, Monero und weitere Ketten dimensioniert, die Einrichtung und wie man ihn privat hält. 6-Fragen-FAQ](https://servhidden.com/de/guides/crypto-node-hosting-guide) [### GPU-Hosting für Stable Diffusion — Eigenen Bildgenerierungsserver betreiben Betrieb Stable Diffusion auf einem eigenen GPU-Server betreiben: Warum selbst hosten, welche GPU die richtige ist, Einrichtung mit einer Web-Oberfläche und Kostenvergleich mit gehosteten Diensten. 6-Fragen-FAQ](https://servhidden.com/de/guides/gpu-hosting-for-stable-diffusion) [### Server-OpSec — Anonym bleiben, wenn man einen Server betreibt Datenschutz Operative Sicherheit für alle, die einen anonymen Server betreiben: die Fehler, die zur Deanonymisierung führen, die Gewohnheiten, die sie verhindern, und wie man Identitäten konsequent trennt. 6-Fragen-FAQ](https://servhidden.com/de/guides/server-opsec-staying-anonymous) [### Seedbox-Einrichtungsanleitung — Bauen Sie 2026 Ihre eigene private Seedbox Betrieb So bauen Sie Ihre eigene Seedbox auf einem Server: Was eine Seedbox ist, wie Sie sie dimensionieren, einen Torrent-Client mit Web-UI installieren und sie privat und sicher betreiben. 6-Fragen-FAQ](https://servhidden.com/de/guides/seedbox-setup-guide) [### DPI-Zensur mit dem eigenen VPS umgehen (Leitfaden 2026) Datenschutz Ihr VPN funktioniert plötzlich nicht mehr? So umgehen Sie DPI-Zensur mit dem eigenen VPS: was Deep Packet Inspection wirklich erkennt, welches der fünf 2026 relevanten Protokolle welche Sperre aushebelt, und eine vollständige VLESS+REALITY-Anleitung. 6-Fragen-FAQ](https://servhidden.com/de/guides/bypass-dpi-censorship-with-your-own-vps) [### Full-Disk-Verschlüsselung auf dem VPS: LUKS-Einrichtung und was sie schützt Betrieb Festplattenverschlüsselung mit LUKS auf dem VPS: verschlüsselte Datenvolumes, Root-Verschlüsselung mit SSH-Fernentsperrung und die Einstellungen für kleine Server. 8-Fragen-FAQ](https://servhidden.com/de/guides/full-disk-encryption-on-a-vps) [### Ursprungsserver-IP verbergen: CDN, Reverse Proxy und was trotzdem leckt Datenschutz Ob ein CDN vor den Offshore-Server gehört: was es verbirgt, welche Abuse-Stelle Sie erben, die sechs Wege, wie eine Ursprungs-IP trotzdem leckt, und wie Sie Ihre eigene prüfen. 8-Fragen-FAQ](https://servhidden.com/de/guides/hiding-your-origin-server-ip) [### Matrix-Server selbst hosten: Federation, Metadaten & E2EE-Lücken Betrieb Was ein eigener Matrix-Homeserver wirklich bringt: Synapse vs. Conduit, der unveränderliche server_name, volle Platten und was Federation dennoch preisgibt. 8-Fragen-FAQ](https://servhidden.com/de/guides/self-host-a-matrix-server) [### Website zu Offshore-Hosting migrieren – ohne Ausfallzeit Betrieb Die Reihenfolge, die eine Host-Migration langweilig macht: die DNS-TTL Tage vorher senken, beide Server parallel betreiben, Schreibvorgänge für Minuten statt Stunden einfrieren – und die Spur aus Passive DNS, Certificate Transparency und WHOIS aufräumen, die der Umzug hinterlässt. 8-Fragen-FAQ](https://servhidden.com/de/guides/migrate-website-to-offshore-hosting) [### How to Self-Host a Crypto Payment Gateway with BTCPay Server Betrieb Run your own non-custodial checkout on an offshore VPS: BTCPay Server, a pruned Bitcoin node, Lightning and Monero — how to size the disk, why the private keys must never touch the machine, and where KYC quietly reappears at the cash-out. 8-Fragen-FAQ](https://servhidden.com/de/guides/self-host-a-crypto-payment-gateway) ## Geben Sie dem heutigen Backup einen Ort zum Landen Sieben Jurisdiktionen, unbegrenzte Bandbreite bei jedem Plan, und Server ab 7,50 $/Monat, die kompetente restic- oder Borg-Endpunkte abgeben. Kein KYC, keine E-Mail, nur Krypto – für das Backup-Ziel genauso wie für die Produktion. [VPS-Tarife ansehen](https://servhidden.com/de/vps) [Dedizierte Server](https://servhidden.com/de/dedicated) [Alle Standorte](https://servhidden.com/de/locations) ## Structured data (JSON-LD) ```json { "@context": "https://schema.org", "@type": "Organization", "@id": "https://servhidden.com/#organization", "name": "ServHidden", "url": "https://servhidden.com", "description": "Offshore-VPS & Dedicated Server in 7 datenschutzfreundlichen Jurisdiktionen. Kein KYC, keine Logs, nur Krypto. Datenschutz durch Architektur.", "logo": { "@type": "ImageObject", "url": "https://servhidden.com/ServHidden.webp", "width": 512, "height": 512 }, "foundingDate": "2025", "areaServed": [ { "@type": "Country", "name": "Iceland" }, { "@type": "Country", "name": "Panama" }, { "@type": "Country", "name": "Moldova" }, { "@type": "Country", "name": "Romania" }, { "@type": "Country", "name": "Switzerland" }, { "@type": "Country", "name": "Netherlands" }, { "@type": "Country", "name": "Russia" } ], "knowsAbout": [ "Offshore hosting", "Offshore VPS", "Bare-metal dedicated servers", "DMCA-ignored hosting", "No KYC hosting", "Cryptocurrency payments", "Privacy engineering", "Token-based authentication", "Anonymous domain name registration", "No-KYC domain registrar", "WHOIS privacy", "Cheap .com domains", "Crypto-paid domain names", "NVIDIA GPU compute", "Windows RDP hosting", "Agentic commerce" ], "contactPoint": { "@type": "ContactPoint", "contactType": "customer support", "url": "https://servhidden.com/contact", "availableLanguage": [ "en", "ru", "zh", "es", "fr", "de", "pt", "ar", "ja", "ko", "hi", "id", "it", "tr", "fa", "vi" ] }, "sameAs": [ "https://servhidden.com/canary", "https://servhidden.com/press" ] } ``` ```json { "@context": "https://schema.org", "@type": "WebSite", "@id": "https://servhidden.com/#website", "url": "https://servhidden.com", "name": "ServHidden", "publisher": { "@id": "https://servhidden.com/#organization" }, "inLanguage": [ "en", "ru", "zh", "es", "fr", "de", "pt", "ar", "ja", "ko", "hi", "id", "it", "tr", "fa", "vi" ] } ``` ```json { "@context": "https://schema.org", "@type": "Article", "headline": "VPS-Backup: verschlüsselt, extern und wirklich wiederherstellbar", "description": "Ihr Hoster speichert keine Backups. Was Server wirklich zerstört, restic vs. BorgBackup, die vergessenen Schlüssel – und wie Sie einen Restore testen, bevor es zu spät ist.", "image": "https://servhidden.com/assets/img/guides/vps-backup-strategy.webp?v=1787218773", "author": { "@type": "Organization", "@id": "https://servhidden.com/#editorial", "name": "ServHidden Editorial", "url": "https://servhidden.com/about", "description": "Operator-side editorial team writing about offshore hosting jurisdictions, offshore server architecture, self-hosted privacy stacks and crypto payments.", "knowsAbout": [ "Offshore hosting jurisdictions", "Data retention law", "MLAT and judicial cooperation", "WireGuard and OpenVPN deployment", "Tor relay operation", "Monero and Bitcoin payment privacy", "KVM virtualization and bare-metal hosting", "DMCA-ignored hosting" ], "parentOrganization": { "@id": "https://servhidden.com/#organization" } }, "publisher": { "@id": "https://servhidden.com/#organization" }, "datePublished": "2026-08-20T00:00:00+00:00", "dateModified": "2026-08-20T00:00:00+00:00", "mainEntityOfPage": "https://servhidden.com/guides/vps-backup-strategy", "inLanguage": "de", "keywords": "VPS Backup, VPS Backup verschlüsselt, restic vs BorgBackup, Offsite-Backup VPS, 3-2-1-Regel Backup, Append-only Backup, Server ohne KYC sichern, Restore testen", "articleSection": "Betrieb", "wordCount": 3947 } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "Macht ServHidden Backups von meinem VPS?", "acceptedAnswer": { "@type": "Answer", "text": "Nein, und das ist Absicht, kein Versehen. Unsere Aufbewahrungsrichtlinie legt fest, dass keine Backups aufbewahrt werden, dass Serverdaten innerhalb von 24 Stunden nach Kündigung vernichtet werden und dass Festplatten kryptografisch gelöscht statt formatiert werden. Eine Kopie Ihrer Daten zu behalten, nachdem Sie uns baten, sie zu entfernen, würde dem Grund widersprechen, aus dem die Plattform existiert. Alles, was den Server überleben soll, müssen Sie selbst davon herunterkopieren, idealerweise zu einem zweiten Anbieter in einer zweiten Jurisdiktion." } }, { "@type": "Question", "name": "Ist ein Snapshot dasselbe wie ein Backup?", "acceptedAnswer": { "@type": "Answer", "text": "Nein. Ein Snapshot teilt jede Fehlerdomäne mit dem Server, von dem er stammt – denselben Anbieter, denselben Account, dasselbe Land, oft denselben Speicher. Er ist hervorragend, um ein fehlgeschlagenes Upgrade rückgängig zu machen, und nutzlos gegen den Verlust des Accounts, des Anbieters oder der Maschine. Behandeln Sie Snapshots als Rückgängig-Taste und Backups als Versicherung; sie lösen unterschiedliche Probleme, und Sie brauchen beides." } }, { "@type": "Question", "name": "restic oder BorgBackup – was soll ich nehmen?", "acceptedAnswer": { "@type": "Answer", "text": "restic, wenn das Ziel Objektspeicher, SFTP oder noch nicht festgelegt sein könnte, denn es spricht die meisten Backends. BorgBackup, wenn das Ziel eine einzelne Linux-Maschine ist, erreicht über SSH, und die Daten groß und repetitiv sind, denn seine Deduplizierung ist die stärkste der Gruppe. Beide verschlüsseln an der Quelle, bevor irgendetwas die Maschine verlässt, und beide unterstützen ein Append-only-Ziel, was weit mehr zählt als die Wahl zwischen beiden." } }, { "@type": "Question", "name": "Wie verhindere ich, dass ein Angreifer meine Backups löscht?", "acceptedAnswer": { "@type": "Answer", "text": "Nehmen Sie die Möglichkeit, nicht das Motiv. Entweder machen Sie das Ziel append-only, sodass die Zugangsdaten auf dem Produktionsserver Daten hinzufügen, aber nie entfernen können, oder Sie kehren die Verbindung um, sodass der Backup-Host von der Produktion abholt und der Produktionsserver gar keine Zugangsdaten besitzt. Backups zu löschen, bevor man sich zu erkennen gibt, ist gängige Praxis für jeden, der das kommerziell betreibt, und eine Kopie, die Ihr Angreifer löschen kann, ist keine zweite Kopie." } }, { "@type": "Question", "name": "Wo sollte die zweite Kopie liegen?", "acceptedAnswer": { "@type": "Answer", "text": "Bei einem anderen Anbieter, in einer anderen Jurisdiktion, und genauso privat bezahlt wie Ihr Produktionsserver. Die Vorfälle, die beide Kopien gleichzeitig vernichten, sind selten physischer Natur – es ist ein verlorener Account, ein Anbieter mit einer schlechten Woche, oder ein rechtliches Instrument, das ein Land erreicht und ein anderes nicht. Zwei Server im selben Rack sind eine Kopie mit Umwegen. Weil die Tools an der Quelle verschlüsseln, muss der zweite Host kein vertrauenswürdiger sein." } }, { "@type": "Question", "name": "Wie oft sollte ich ein Backup machen?", "acceptedAnswer": { "@type": "Answer", "text": "Rechnen Sie rückwärts von der Arbeit, die Sie bereit sind, noch einmal zu erledigen. Ein Blog kann einen Tag verlieren, ohne dass es jemand merkt; ein Shop darf keine Stunde an Bestellungen verlieren. Nächtlich ist der richtige Standard für die meisten Single-Server-Setups, mit häufigeren Datenbank-Dumps, wenn Schreibvorgänge wertvoll sind. Wichtiger als die Häufigkeit ist die Tiefe der Aufbewahrung: Korruption fällt oft erst Wochen später auf, also bewahren Sie genug Historie auf, um einen Punkt vor ihrem Beginn zu erreichen." } }, { "@type": "Question", "name": "Ist ein verschlüsseltes Backup auf einem fremden Server sicher?", "acceptedAnswer": { "@type": "Answer", "text": "Was den Inhalt betrifft, ja – restic und Borg verschlüsseln, bevor Daten die Quelle verlassen, sodass das Ziel Blobs speichert, die es nicht lesen kann, und der Schlüssel nie dorthin reist. Was das Ziel durchaus erfährt, sind Metadaten: ungefähr wie viel Daten Sie halten, wie sie sich ändern, und wann Ihre Jobs laufen. Das ist meist akzeptabel. Wenn nicht, variieren Sie den Zeitplan und halten Sie das Repository auf einer Maschine, deren Eigentümer nicht mit dem der Produktionsmaschine verknüpft ist." } }, { "@type": "Question", "name": "Was passiert, wenn ich die Backup-Passphrase verliere?", "acceptedAnswer": { "@type": "Answer", "text": "Das Archiv ist unwiederbringlich verloren, ohne jede Möglichkeit der Rettung durch irgendjemanden. Das ist der häufigste Totalverlust im gesamten Thema und der einzige Fehler ohne Rettungsweg. Bewahren Sie die Passphrase fernab jeder beteiligten Maschine auf, bevorzugen Sie Papier gegenüber einem Account, den Sie ebenfalls verlieren könnten, und fügen Sie dem Repository einen zweiten Schlüssel hinzu, damit ein vergessenes Passwort ein Ärgernis ist und nicht das Ende des Archivs." } } ] } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "Startseite", "item": "https://servhidden.com/de/" }, { "@type": "ListItem", "position": 2, "name": "Datenschutz-Hosting-Leitfäden", "item": "https://servhidden.com/de/guides" }, { "@type": "ListItem", "position": 3, "name": "VPS-Backup: verschlüsselt, extern und wirklich wiederherstellbar", "item": "https://servhidden.com/de/guides/vps-backup-strategy" } ] } ```