Ist ein Storage-VPS ein echtes Backup?

Ein Storage-VPS ist nur eine Kopie Ihrer Daten

Ein Storage-VPS ist ein gemieteter Linux-Server mit einer großen, kostengünstigen Festplatte, der pro Terabyte statt pro CPU-Kern verkauft wird. Er bietet Ihnen eine zweite Kopie Ihrer Daten in einem anderen Gebäude, was ein Bestandteil einer Backup-Strategie ist. Die Kopie wird erst dann zu einem Backup, wenn sie sich außerhalb der Fehlerdomäne des Originals befindet, alte Versionen vorhält, vor dem Verlassen Ihres Rechners verschlüsselt wurde und von Ihnen mindestens einmal erfolgreich wiederhergestellt wurde.

Deutsche Leser kennen bereits den passenden Satz dafür: RAID ist kein Backup. RAID (redundant array of independent disks) ist kein Backup. Diese Warnung lässt sich aus demselben Grund auf den günstigen Terabyte-Speicher übertragen. Redundanz schützt vor Hardware-Ausfällen, doch fast nichts, was Daten zerstört, ist ein Hardware-Ausfall.

Was einen Storage-VPS von einem regulären VPS unterscheidet ist hauptsächlich der Speicher: mehr Platz, langsameres Medium, weniger CPU. Dieser Vergleich zeigt Ihnen, was Sie mieten. Er sagt jedoch nichts darüber aus, ob das, was Sie darauf aufbauen, Ihre Dateien auch nach einem kritischen Vorfall noch enthält.

Warum das günstige Terabyte günstig ist

Speicherpläne sind günstig aufgrund ihrer technischen Basis, und jeder Grund hat Konsequenzen, die Sie bei einer Wiederherstellung bemerken werden.

• Das Medium besteht aus rotierenden Festplatten. Ein Speicherplan basiert auf HDDs, manchmal ergänzt durch einen kleinen Solid-State-Cache. Die IOPS (Input/Output Operations per Second) sind niedrig, weshalb die Wiederherstellung von einer Million kleiner Dateien wesentlich länger dauert als die einer einzelnen großen Datei mit derselben Gesamtgröße.
• Die Kapazität ist überbucht. Anbieter verkaufen mehr Terabytes, als Kunden an einem durchschnittlichen Tag beschreiben, da die meisten Pläne nie vollständig belegt werden. Dies ist normal und in der Preisgestaltung berücksichtigt. Es bedeutet auch, dass sich alle Nutzer auf dem Host die Durchsatzrate teilen.
• Der Netzwerkanschluss ist meist der erste Punkt, an dem gespart wird. Der Upload reicht für einen nächtlichen inkrementellen Lauf aus. Eine vollständige Wiederherstellung von mehreren hundert Gigabyte dauert jedoch Stunden.
• Die Redundanz liegt beim Anbieter. RAID und jegliche Replikation innerhalb des Plans halten den Dienst des Anbieters am Laufen, wenn eine Festplatte ausfällt. Sie bewahren jedoch nicht die Version Ihrer Datei von gestern auf.

[
  {
    "label": "Managed storage box",
    "eur_per_tb_month": 4
  },
  {
    "label": "Storage VPS, spinning disk",
    "eur_per_tb_month": 5
  },
  {
    "label": "Object storage",
    "eur_per_tb_month": 6
  },
  {
    "label": "Block volume on a server",
    "eur_per_tb_month": 45
  },
  {
    "label": "NVMe inside a compute plan",
    "eur_per_tb_month": 60
  }
]

Dies sind gerundete Zahlen aus veröffentlichten Preislisten vom September 2026, gruppiert nach Produkttyp und nicht nach Anbieter. Betrachten Sie diese daher als Marktübersicht und nicht als verbindliches Angebot. Ein Terabyte in einem Speicherplan wird für etwa €5 pro Monat beworben. Dasselbe Terabyte als Block-Volume, das an einen Compute-Server angebunden ist, liegt bei etwa €45, und als NVMe innerhalb eines Compute-Plans bei etwa €60. Die Differenz beträgt mehr als das Zehnfache. Das langsame Medium und die Überbuchung finanzieren diesen Preis. Der Vergleich günstiger Terabytes zwischen Storage-VPS, Block- und Objektspeicher erläutert, wo die jeweiligen Vorteile liegen.

RAID ist kein Backup: Was das Array tatsächlich schützt

Ein RAID-Array schreibt Ihre Daten auf mehr als eine Festplatte, damit der Dienst einen Festplattenausfall übersteht. Das ist das gesamte Versprechen. Jedes der folgenden Ereignisse erreicht jede Festplatte im Array im selben Moment, da das Array genau das tut, was ihm befohlen wurde.

• rm -rf auf dem falschen Pfad. Das Löschen erfolgt auf beiden Hälften des Mirrors im selben Augenblick.
• Eine Synchronisierung, die den Fehler kopiert. rsync -a --delete /srv/ backup:/srv/ entfernt auf dem Ziel alles, was Sie an der Quelle entfernt haben, sodass die zweite Kopie am Ende genauso leer ist wie die erste.
• Ransomware. Sie verschlüsselt Ihre Dateien, und das Array speichert die verschlüsselten Dateien zuverlässig auf jeder Festplatte.
• Eine Migration oder ein Upgrade, das eine Datenbank direkt überschreibt und dabei einen Fehler verursacht.
• Beschädigung auf Anwendungsebene. Die fehlerhaften Bytes werden korrekt auf alle Festplatten geschrieben.
• Der Wegfall des Kontos. Eine unbezahlte Rechnung, eine Sperrung oder eine geschlossene Region nimmt das Array mit sich, da Redundanz innerhalb eines Kontos diesen Kontoverlust nicht überlebt.

Diese Liste ist das Argument. RAID 10 auf einem VPS erklärt, was Ihnen das Array tatsächlich bringt, nämlich Betriebszeit bei einem Festplattenausfall, und was eine Wiederherstellung nach einem versehentlichen rm -rf wirklich bedeutet zeigt, wie wenig das Array hilft, sobald der Löschbefehl ausgeführt wurde.

Wo ein Snapshot endet und ein Backup beginnt

Ein Snapshot ist ein Abbild eines Volumes zu einem bestimmten Zeitpunkt, das von der Speicherebene des Anbieters erstellt und aufbewahrt wird. Er lässt sich in Minuten wiederherstellen und verursacht kaum Kosten; erstellen Sie daher vor jeder riskanten Änderung einen Snapshot. Er ist dennoch kein Backup, da er innerhalb des Systems existiert, das er schützen soll. Er ist auf die Steuerungsebene des Anbieters angewiesen, um zu existieren und wiederhergestellt zu werden, wird über dasselbe Konto wie der Server abgerechnet und ist in dem Moment nicht mehr erreichbar, in dem dieses Konto gesperrt wird. Der vollständige Vergleich von Snapshots und Backups erläutert für jeden Anwendungsfall, was jeweils gesichert wird.

Voraussetzungen für ein valides Backup

• Eine separate Fehlerdomäne. Ein anderer Anbieter, ein anderes Konto oder zumindest ein anderes Gebäude mit einer anderen Strom- und Netzanbindung. Ein Backup, das einen Single Point of Failure mit dem Original teilt, fällt gleichzeitig mit diesem aus.
• Historie statt Spiegelung. Versionen, die weit genug zurückreichen, um Probleme abzudecken, die erst spät bemerkt werden. Wird Ransomware an Tag 9 entdeckt und sind nur 7 Tage Historie vorhanden, wird der Schaden mit wiederhergestellt.
• Verschlüsselung vor dem Upload. Wer Root-Zugriff auf den Speicher-Server hat, kann unverschlüsselte Daten lesen; das gilt auch für jeden Angreifer, der sich Zugriff verschafft.
• Eine selbst durchgeführte Wiederherstellung. Solange Sie diese nicht erfolgreich getestet haben, ist Ihr Datenbestand lediglich eine Hypothese und kein Backup.

Einordnung eines Storage-VPS in die 3-2-1-Regel

Die 3-2-1-Regel ist bewährt und weiterhin gültig: Drei Kopien der Daten, auf zwei verschiedenen Speichermedien, mit einer Kopie an einem externen Standort. Für einen kleinen Produktivserver sieht das wie folgt aus:

1. Die Live-Daten auf dem Produktivserver. Dies ist die erste Kopie und stellt kein Backup dar.
2. Ein restic-Repository auf dem Storage-VPS, übertragen via SFTP (SSH File Transfer Protocol). Andere Maschine, anderes Gebäude, vor dem Versand verschlüsselt. Dies ist der Bereich, in dem ein Storage-VPS seine Stärken voll ausspielt.
3. Ein zweites Repository an einem anderen Ort: eine Festplatte im Büro, ein Object-Storage-Bucket oder ein zweiter Anbieter. Zwei restic-Repositories vorhalten zeigt, wie Daten zwischen ihnen kopiert werden, damit für das dritte Standbein kein zweiter vollständiger Upload vom Produktivserver erforderlich ist.

Hier ist der Teil, den viele überspringen: Wenn der Produktiv-VPS und der Storage-VPS über dasselbe Konto beim gleichen Anbieter in derselben Stadt laufen, teilen sich Kopie eins und zwei eine Fehlerdomäne. Das Setup ist dennoch sinnvoll. Es ist jedoch nicht „extern“ im Sinne der Regel, und ein verlorener Account führt zum Verlust beider Kopien. Einen VPS als externes Backup-Ziel nutzen und Einen Storage-VPS mit dem Haupt-VPS koppeln behandeln beide Aspekte dieser Entscheidung.

sudo apt update && sudo apt install -y restic
sudo install -d -m 700 /etc/restic
sudo sh -c 'umask 077; head -c 32 /dev/urandom | base64 > /etc/restic/repo.key'

Kopieren Sie diesen Schlüssel jetzt in Ihren Passwort-Manager, bevor das erste Backup läuft. Ein restic-Repository, dessen Passwort verloren geht, ist konstruktionsbedingt nicht wiederherstellbar, und restic weist explizit darauf hin: Fatal: wrong password or no key found. Es gibt kein Support-Ticket, das dies rückgängig machen kann.

export RESTIC_REPOSITORY="sftp:backup@storage.example.net:/srv/restic"
export RESTIC_PASSWORD_FILE=/etc/restic/repo.key
sudo -E restic init
sudo -E restic backup /srv /etc --exclude-caches
sudo -E restic snapshots

restic snapshots sollte nun eine Zeile mit dem heutigen Datum, dem Hostnamen und den gesicherten Pfaden ausgeben. Das SFTP-Backend führt den systemeigenen ssh-Client als der Benutzer aus, der ihn aufgerufen hat; unter sudo liest er also die ~/.ssh von root und nicht Ihre eigenen. Ein SSH-Schlüssel, der für Ihren Login-Benutzer funktioniert, aber nie für root installiert wurde, ist der häufigste Grund, warum ein erstes init hängen bleibt oder abgelehnt wird. Ein vollständiges restic-Setup auf einem VPS behandelt die Include- und Exclude-Regeln, die den Speicherbedarf bestimmen.

sudo -E restic forget --keep-daily 7 --keep-weekly 5 --keep-monthly 12 --prune

Bewahren Sie genügend Historie auf, um Probleme abzudecken, die erst spät bemerkt werden. Sieben tägliche Snapshots klingen großzügig, bis sich herausstellt, dass eine beschädigte Tabelle bereits seit drei Wochen korrupt ist. Monatliche Snapshots sind bei Tarifen, die nach Terabyte abgerechnet werden, kostengünstig; dies ist also der falsche Ort zum Sparen.

[Unit]
Description=Nightly restic backup

[Service]
Type=oneshot
Environment=RESTIC_REPOSITORY=sftp:backup@storage.example.net:/srv/restic
Environment=RESTIC_PASSWORD_FILE=/etc/restic/repo.key
ExecStart=/usr/bin/restic backup /srv /etc --exclude-caches
ExecStart=/usr/bin/restic forget --keep-daily 7 --keep-weekly 5 --keep-monthly 12 --prune

[Unit]
Description=Run the restic backup nightly

[Timer]
OnCalendar=daily
RandomizedDelaySec=30m
Persistent=true

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now restic-backup.timer
systemctl list-timers 'restic-backup*'

Verschlüsselung vor dem Verlassen des lokalen Rechners

restic verschlüsselt jeden Blob mit einem Schlüssel, der aus dem Repository-Passwort abgeleitet wird. Der Storage-VPS speichert daher ausschließlich Chiffretext. Der Host kann weiterhin die Größe des Repositorys, die Anzahl der Objekte und die Zeitpunkte der Schreibzugriffe sehen. Den Inhalt kann der Host jedoch nicht lesen. Genau diese Eigenschaft macht ein gemietetes Terabyte überhaupt erst für persönliche Daten akzeptabel, da die Frage der Vertraulichkeit von der Infrastruktur des Anbieters auf die eigene Schlüsselverwaltung verlagert wird.

Erfolgt ein Backup stattdessen mit einfachem rsync auf eine eingebundene Freigabe, liegen die Dateien dort für jeden lesbar, der auf dieser Maschine root-Rechte besitzt – dies schließt einen Angreifer ein, der sich Zugriff verschafft hat. Verschlüsselung Ihrer Daten auf einem Storage-VPS behandelt den alternativen Weg über einen verschlüsselten Container oder eine Dateisystemschicht unterhalb der Dateien. restic und borgbackup führen beide die Verschlüsselung clientseitig durch. Die Wahl zwischen beiden Tools ist daher eher eine Frage des Repository-Formats und des Workflows als eine Entscheidung darüber, ob der Host Ihre Dateien lesen kann.

Ein weiterer Aspekt ist hierbei entscheidend. Ein Backup, das Ihr Produktionsserver löschen kann, ist ein Backup, das auch Ransomware löschen kann, da die Schadsoftware mit den Anmeldedaten Ihres Backup-Jobs ausgeführt wird. Geben Sie dem Produktions-Host daher nur einen append-only Zugriff auf das Repository. rest-server verfügt hierfür über einen integrierten --append-only-Modus. Ein kompromittierter Client kann somit neue Snapshots hinzufügen, aber keine alten entfernen. Bereinigungsoperationen (Pruning) werden von einer anderen Maschine mit anderen Anmeldedaten durchgeführt. Vorgehensweise bei einem kompromittierten VPS geht von der Annahme aus, dass der Angreifer bereits Zugriff auf alle Daten des Servers hatte.

Der Wiederherstellungstest für diese Woche

sudo -E restic check --read-data-subset=5%
sudo -E restic restore latest --target /var/tmp/restore-test --include /etc/nginx
sudo diff -r /etc/nginx /var/tmp/restore-test/etc/nginx

check überprüft für sich genommen die Struktur und den Index des Repositorys. --read-data-subset=5% lädt eine Stichprobe der tatsächlichen Daten-Blobs herunter und verifiziert diese; dies erkennt Speicherfehler, die schleichend aufgetreten sind. Wenn diff -r keine Ausgabe erzeugt, ist der Test erfolgreich. Jede Ausgabe bedeutet, dass die wiederhergestellte Kopie nicht Byte-identisch ist. Es ist deutlich besser, dies heute zu erfahren, als an dem Tag, an dem Sie die Daten tatsächlich benötigen.

Dieser Test beweist, dass das Repository von der Maschine aus lesbar ist, die es geschrieben hat. Der schwierigere und entscheidendere Test ist die Wiederherstellung auf einer anderen als der ursprünglichen Maschine. Nutzen Sie einen neuen VPS, verwenden Sie nur die Repository-URL und das Passwort aus Ihrem Passwort-Manager und lassen Sie den Produktionsserver ausgeschaltet. Messen Sie die gesamte Laufzeit. Dieser Wert ist Ihr RTO (Recovery Time Objective). Er ist meist deutlich höher als erwartet, da Pläne auf Basis rotierender Festplatten kleine Dateien nur langsam wieder zusammensetzen. Was bei der Festplattengeschwindigkeit von Storage-VPS zu erwarten ist zeigt die Größenordnung dieser Werte, bevor Sie jemandem ein Wiederherstellungsfenster zusagen.

Für eine einzelne gelöschte Datei stellt sudo -E restic mount /mnt/restic (dafür wird das Paket fuse3 benötigt) jeden Snapshot als normalen Verzeichnisbaum dar, aus dem Sie die Daten kopieren können. Dies ist der schnellste Weg bei kleinen Notfällen, die den Großteil aller Notfälle ausmachen.

DSGVO Art. 32: Das RAID des Anbieters entbindet Sie nicht von Ihrer Pflicht

Wenn Sie personenbezogene Daten von Personen in der EU verarbeiten, unterliegen Sie der DSGVO (Datenschutz-Grundverordnung). Artikel 32 Abs. 1 benennt die technischen Maßnahmen direkt. Punkt (a) ist die Verschlüsselung personenbezogener Daten. Punkt (b) ist die Gewährleistung der Vertraulichkeit, Integrität, Verfügbarkeit und Belastbarkeit der Systeme. Punkt (c) ist die Fähigkeit, die Verfügbarkeit der Daten und den Zugang zu ihnen bei einem physischen oder technischen Zwischenfall rasch wiederherzustellen. Punkt (d) ist ein Verfahren zur regelmäßigen Überprüfung und Bewertung der Wirksamkeit dieser Maßnahmen.

Betrachtet man (c) und (d) zusammen, stellt sich heraus, dass die rechtliche Anforderung und die technische Anforderung identisch sind: eine Wiederherstellung, die Sie durchführen können, und ein Zeitplan, nach dem Sie dies nachweisen. Das RAID Ihres Anbieters ist eine Maßnahme innerhalb dessen eigener Infrastruktur. Es sagt nichts darüber aus, ob Sie Ihre Daten wiederherstellen können; daher ist es kein Nachweis für die von Ihnen geforderten Punkte. Wenn der Anbieter personenbezogene Daten in Ihrem Auftrag verarbeitet, benötigen Sie zudem einen AVV (Auftragsverarbeitungsvertrag gemäß Art. 28), wobei die Verantwortung als Verantwortlicher unabhängig davon bei Ihnen verbleibt. Dies stellt keine Rechtsberatung dar, und Ihr Datenschutzbeauftragter wird einen schriftlichen Nachweis des Wiederherstellungstests mit entsprechendem Datum verlangen.

Wo die Terabytes physisch gespeichert sind, gehört in dasselbe Dokument. EU-Datenresidenz und deren Kosten behandelt diesen Abwägungsprozess, und Storage-VPS-Anbieter in Deutschland deckt den Markt ab, aus dem Sie wählen können. Die bekannten Namen sind hier Hetzner, Contabo, netcup und IONOS; jeder von ihnen bietet Produkte in Form von Storage-Boxen oder Storage-VPS an. Was der jeweilige Anbieter bezüglich der Datensicherheit verspricht, ist in dessen aktuellen Geschäftsbedingungen festgelegt. Lesen Sie daher die Bedingungen des Tarifs, den Sie tatsächlich erwerben, anstatt sich auf eine Zusammenfassung zu verlassen, die vor Monaten verfasst wurde.

Fehlermodi und die zugehörigen Meldungen

Das Repository befindet sich nicht am erwarteten Ort. restic gibt Fatal: unable to open config file: Stat: file does not exist aus, gefolgt von Is there a repository at the following location? mit der URL. Entweder wurde init nie ausgeführt, der Pfad ist falsch oder der SSH-Benutzer landet in einem anderen Home-Verzeichnis als dem, das Sie bei der Pfadangabe angenommen haben.

Manuell funktioniert es, per Timer schlägt es fehl. Das Log zeigt Host key verification failed.. Der interaktive Lauf nutzte die known_hosts Ihres Benutzers, während der Timer als root ausgeführt wird, dem dieser Host noch unbekannt ist. Führen Sie einmal sudo ssh backup@storage.example.net aus und akzeptieren Sie den Key, oder tragen Sie den Key selbst in /root/.ssh/known_hosts ein.

Ein abgebrochener Lauf blockiert den nächsten. unable to create lock in backend: repository is already locked exclusively by PID 1234 bedeutet, dass ein vorheriger restic-Prozess beendet wurde, ohne aufzuräumen. Stellen Sie sicher, dass kein Prozess läuft, und führen Sie dann sudo -E restic unlock aus.

Der Speicherplatz ist erschöpft und jedes Backup schlägt fehl. Die Speicherseite meldet no space left on device. Dies liegt fast immer an einer forget-Richtlinie, die ohne --prune ausgeführt wird, wodurch alte Snapshots zwar als vergessen markiert werden, ihre Daten aber auf der Festplatte verbleiben. Dimensionierung eines Storage-VPS erläutert, wie viel Puffer der Prune-Schritt benötigt, um zu funktionieren.

Die Wiederherstellung ist korrekt, aber viel zu langsam. Millionen kleiner Dateien auf einem Plan mit rotierenden Festplatten werden mit einer Geschwindigkeit wiederhergestellt, die oft überrascht. Sichern Sie Datenbank-Dumps als einzelne Dateien, anstatt einen aktiven Datenverzeichnisbaum wiederherzustellen, und messen Sie die tatsächliche Wiederherstellungsdauer, bevor ein Vorfall Sie unter Zeitdruck setzt.

Aufgaben für diese Woche

1. Wählen Sie ein Verzeichnis aus, dessen Verlust tatsächlich schmerzhaft wäre, und suchen Sie es in restic snapshots.
2. Stellen Sie es vom Storage-VPS in /var/tmp auf einem Rechner wieder her, der nicht der Produktivserver ist.
3. Führen Sie diff -r für das Original aus und lesen Sie die Ausgabe, anstatt davon auszugehen, dass sie leer ist.
4. Notieren Sie das Datum und die benötigte Zeit in demselben Dokument, in dem Sie Ihre Maßnahmen gemäß Art. 32 auflisten. Die Checkliste für den Storage-VPS ist ein geeigneter Ort, um dies neben den Details des Plans zu führen.

FAQ

Ist ein Storage-VPS ein Backup?

Für sich genommen nicht. Ein Storage-VPS ist eine zweite Kopie Ihrer Daten auf gemieteter Hardware und damit ein Teil einer Backup-Strategie. Er wird erst dann zu einem Backup, wenn er sich außerhalb der Fehlerdomäne des Originals befindet, genügend Versionshistorie für die Wiederherstellung nach verspäteter Fehlererkennung vorhält, vor dem Upload verschlüsselt wurde, damit der Hoster die Daten nicht lesen kann, und von Ihnen mindestens einmal erfolgreich wiederhergestellt wurde. Ohne einen Wiederherstellungstest besitzen Sie lediglich eine ungetestete Kopie.

Ist RAID ein Backup?

Nein, und die deutsche Kurzform „RAID ist kein Backup“ trifft es exakt. RAID sorgt dafür, dass der Dienst bei einem Festplattenausfall weiterläuft. Es schreibt jede Änderung sofort auf alle Datenträger, einschließlich rm -rf, einschließlich eines Ransomware-Angriffs und einschließlich eines rsync --delete, das Ihren Fehler auf die Kopie spiegelt. Zudem verschwindet ein RAID zusammen mit dem Konto, über das es abgerechnet wird. RAID ist eine Maßnahme zur Verfügbarkeit, keine Maßnahme zur Wiederherstellung.

Zählen Provider-Snapshots als eine meiner 3-2-1-Kopien?

Nicht als die externe Kopie (Off-Site). Ein Snapshot liegt in der Storage-Ebene des Providers direkt neben dem Volume, von dem er ein Abbild erstellt. Er ist für die Wiederherstellung von der Control-Plane des Providers abhängig und wird über dasselbe Konto wie der Server abgerechnet. Snapshots sind hervorragend geeignet, um ein fehlerhaftes Upgrade innerhalb von Minuten rückgängig zu machen. Betrachten Sie sie als Komfortschicht über einem echten Backup und bewahren Sie mindestens eine Kopie in einem anderen Konto oder bei einem anderen Provider auf.

Wie oft sollte ich eine Wiederherstellung testen?

Vierteljährlich bei kleinen Setups sowie nach jeder Änderung an den zu sichernden Daten oder dem Speicherziel. Art. 32 Abs. 1 lit. d DSGVO fordert ein Verfahren zur regelmäßigen Überprüfung und Bewertung der Maßnahmen. Daher benötigt der Test ein Datum und ein schriftliches Ergebnis, nicht nur die vage Erinnerung, dass es funktioniert hat. Führen Sie mindestens restic check --read-data-subset=5% nach einem Zeitplan aus und führen Sie einmal manuell eine vollständige Wiederherstellung auf einem anderen Rechner durch.

Wo sollte ich das Passwort für das restic-Repository speichern?

An jedem Ort, außer ausschließlich auf dem Server, der gesichert wird. Ein restic-Repository, dessen Passwort verloren gegangen ist, kann von niemandem mehr geöffnet werden, auch nicht vom Provider; restic antwortet in diesem Fall mit Fatal: wrong password or no key found. Speichern Sie den Schlüssel in einem Passwort-Manager und an einem Offline-Ort, beispielsweise als Ausdruck in einem Tresor. Wenn der Rechner, der die einzige Kopie des Schlüssels enthält, genau der Rechner ist, den Sie wiederherstellen müssen, besitzen Sie kein Backup.