Ein VPS gibt Ihnen die volle Kontrolle über den Server, was bedeutet, dass Backups ebenfalls Ihre Aufgabe sind. Hier steht, was Sie sichern, wie die 3-2-1-Regel auf einem VPS funktioniert, wie Sie sie automatisieren und warum ein Wiederherstellungstest der einzige echte Beweis ist.
Ein VPS-Backup ist eine Kopie Ihrer Serverdaten, die dort gespeichert ist, wo der Server selbst nicht hinkommt, sodass Sie, wenn der Server ausfällt, versehentlich gelöscht wird oder von Ransomware verschlüsselt wird, dieselben Daten auf einer frischen Maschine zurückholen können. Beim Shared Hosting macht der Anbieter diese Kopien für Sie; bei einem VPS kontrollieren Sie den gesamten Stack, und damit wandert die Verantwortung für Backups und für die Wiederherstellung zu Ihnen. Der praktische Standard ist die 3-2-1-Regel – drei Kopien der Daten, auf zwei verschiedenen Speichertypen, mit einer Kopie außerhalb des Standorts – und der einzige Beweis, dass irgendetwas davon funktioniert, ist eine Wiederherstellung, die Sie wirklich ausgeführt haben.
Beim Shared Hosting erstellt der Anbieter Momentaufnahmen der gesamten Maschine, und Sie öffnen ein Ticket, wenn etwas kaputtgeht. Ein VPS hebt diese Decke auf: Sie wählen das Betriebssystem, die Datenbank, die Firewall und den Update-Zeitplan, und genau das ist der Sinn eines eigenen Servers – aber es bedeutet auch, dass niemand für Sie eine Kopie anfertigt. Der Anbieter schützt weiterhin die Hardware, und ein guter Anbieter übersteht eine defekte Festplatte, ohne dass Sie es merken, doch das deckt nur die physische Schicht. Es deckt nicht den Operator, der ein Update einspielt und damit die Datenbank beschädigt, nicht das Skript, das das falsche Verzeichnis überschreibt, nicht den Angreifer, der alles verschlüsselt und Lösegeld verlangt, und nicht das kompromittierte Anbieter-Konto, über das ein ganzes Projekt verschwindet. Diese vier Szenarien haben eines gemeinsam: Sie sind für das Rechenzentrum unsichtbar, und sie enden alle gleich, es sei denn, irgendwo existiert eine Kopie.
Die Regel lautet: drei Kopien der Daten, auf zwei verschiedenen Medien, eine außerhalb des Standorts, und sie hat überlebt, weil sie einfach ist und jeden einzelnen Ausfallpunkt abdeckt. Auf einem VPS lässt sie sich direkt auf Infrastruktur übertragen, die Sie ohnehin haben. Kopie eins ist der Live-Server selbst. Kopie zwei ist eine weitere Kopie auf einem anderen Speicher im selben Projekt – ein entkoppelter Volume-Snapshot, ein Datenbank-Dump in einen Object-Storage-Bucket oder ein Backup-Dienst beim selben Anbieter, aber auf getrennten Festplatten. Kopie drei ist die Offsite-Kopie, und "Offsite" sollte ein völlig anderes Ausfall-Domain bedeuten: einen anderen Anbieter, ein anderes Rechenzentrum oder ein Object-Storage-Konto in einer separaten Region. Zwei Medien zählen, weil ein ganzes Storage-Array ausfallen kann; ein anderer Standort zählt, weil ein ganzes Konto oder ein Anbieter ausfallen kann. Zwei Zahlen bestimmen die Form der gesamten Einrichtung: Ihr Recovery Point Objective, die Datenmenge, deren Verlust Sie sich leisten können, gemessen in Zeit, und Ihr Recovery Time Objective, die Zeit, die das Unternehmen ohne den Dienst übersteht. Beantworten Sie zuerst diese beiden Fragen, dann ergibt sich jede folgende Backup-Entscheidung von selbst.
Nicht alles auf einem Server braucht eine Kopie, und alles gleich zu behandeln ist der Grund, warum Backup-Budgets explodieren. Datenbanken kommen zuerst, denn sie halten die Arbeit: Erstellen Sie jede Nacht einen logischen Dump mit pg_dump oder mysqldump – eine einzige komprimierte Datei, die sich überall wiederherstellen lässt – und fügen Sie bei größeren Datenbanken eine kontinuierliche Point-in-Time-Recovery hinzu, damit sich ein fehlerhafter Import auf die Stunde statt bis Mitternacht zurückrollen lässt. Anwendungscode braucht kein Backup, denn das Repository ist das Backup; das Ausliefern aus git bedeutet, dass die Anwendung mit einem einzigen Befehl neu aufgebaut ist. Was kopiert werden muss, ist alles, was das Repository nicht neu erzeugen kann: hochgeladene Dateien und Nutzermedien, Umgebungsdateien mit Secrets und Drittanbieter-Schlüsseln, die Konfiguration von nginx und der Dienste, Cron-Jobs und das Backup-Skript selbst. Zertifikate und DNS-Einträge gehören ebenfalls auf die Liste, denn eine Domain, deren Einträge verloren gehen, braucht Tage, um sie wieder aufzubauen. Halten Sie Secrets im Speicher verschlüsselt – ein Backup einer .env-Datei in einem öffentlichen Bucket ist ein Datenleck, das nur darauf wartet, entdeckt zu werden.
Ein Backup, das davon abhängt, dass sich ein Mensch daran erinnert, wird genau an dem Tag vergessen, an dem es zählt. Automatisieren Sie es und machen Sie die Automatisierung ehrlich: Lassen Sie den Job über cron oder systemd nach festem Zeitplan laufen, sodass jeder Schritt in ein Log schreibt, und ganz wichtig: Das Skript muss bei einem Fehlschlag mit einem Exit-Code ungleich Null enden, und dieser Code muss dorthin geschickt werden, wo ein Mensch ihn liest – E-Mail, Chat-Kanal, Monitoring-System. Ein Backup-Job, der sechs Monate lang stillschweigend eine leere Datei erzeugt hat, ist ein klassischer Vorfall-Bericht, und der Exit-Code ist die billige Sicherung dagegen. Fügen Sie Integritätsprüfungen hinzu: Stellen Sie sicher, dass der Dump nicht leer ist, prüfen Sie die Prüfsumme des Archivs, und bestätigen Sie, dass die Offsite-Kopie wirklich angekommen ist, indem Sie den Bucket-Inhalt prüfen, statt dem Upload-Befehl zu vertrauen. Legen Sie dann die Aufbewahrung bewusst fest, statt alles für immer zu behalten – ein Großvater-Zyklus aus täglichen Kopien für eine Woche, wöchentlichen für einen Monat und monatlichen für ein Jahr deckt jeden realistischen Bedarf zu einem Bruchteil der Speicherkosten und zwingt alte Daten auszulaufen, anstatt sich anzusammeln, bis das Budget sich verdoppelt.
Ein Backup ist eine Theorie, bis es wiederhergestellt wurde. Einmal pro Quartal nehmen Sie eine aktuelle Kopie, stellen einen Wegwerf-Server in derselben Größe bereit und stellen den gesamten Stack aus dem Nichts wieder her: Anwendung, Konfiguration, Datenbank, Uploads. Stoppen Sie die Zeit, denn ein Backup, das neun Stunden zur Wiederherstellung braucht, ist etwas anderes als eines, das zwanzig Minuten braucht – und den Unterschied sieht man nur, wenn man ihn misst. Vergleichen Sie dann echte Datensätze mit den wiederhergestellten Daten – eine Summe, eine Zeilenanzahl, eine aktuelle Transaktion –, denn eine Wiederherstellung, die ohne die letzte Woche durchläuft, ist kein Erfolg. Schreiben Sie nach dem Test auf, was passiert ist, in ein Runbook, das außerhalb des Servers lebt: die Befehle in Reihenfolge, die Quelle der Zugangsdaten, die DNS-Einträge, die umgeschaltet werden müssen, und wer jeden Schritt macht. Ein Runbook auf der Maschine, die es retten soll, ist genau dann nutzlos, wenn man es braucht, und ein ruhiger Engineer mit einem getesteten Runbook stellt in einer Stunde wieder her, was ein panischer an einem Tag neu entdeckt.
Automatisierte tägliche Backups sind das Minimum für eine geschäftliche Site, mit häufigeren Datenbank-Dumps, wenn sich die Daten ständig ändern – alle paar Stunden oder eine kontinuierliche Point-in-Time-Recovery, wenn der Verlust eines ganzen Vormittags an Transaktionen wehtun würde. Das richtige Intervall wird durch Ihr Recovery Point Objective bestimmt: die Antwort auf „Wie viel neue Arbeit können wir uns leisten zu verlieren?“ in Stunden, nicht durch eine Faustregel.
Anbieter-Backups sind eine nützliche erste Schicht und auf einer guten Plattform zuverlässig, aber sie sind kein Disaster-Recovery-Plan. Sie liegen meistens im selben Konto und im selben Ausfall-Domain wie der Server, sind oft ein Zuschussposten, der bei budgetärem Druck gestrichen wird, und wenn das Anbieter-Konto kompromittiert wird, sind Server und Backups zusammen weg. Behalten Sie das Anbieter-Backup und fügen Sie eine Kopie hinzu, die Sie außerhalb dieses Kontos kontrollieren – das ist die Offsite-Kopie, die die 3-2-1-Regel erzwingen soll.
Dass Sie sie wiederherstellen. Ein Backup-Job, der Erfolg meldet, beweist nur, dass das Skript lief und eine Datei geschrieben wurde; er sagt nichts darüber, ob die Datei vollständig, intakt oder wiederherstellbar ist. Der einzige zuverlässige Test ist ein Wiederherstellungs-Exercise in einer Wegwerf-Umgebung – stellen Sie einen frischen Server bereit, bauen Sie den Stack aus dem Backup wieder auf und vergleichen Sie echte Daten mit dem Original. Führen Sie es mindestens einmal pro Quartal aus und stoppen Sie die Zeit, denn eine Wiederherstellung, die funktioniert, aber einen ganzen Tag braucht, verändert Ihre Wiederherstellungsplanung.
VPS-Server, die mit einer funktionierenden Wiederherstellung ausgeliefert werden – tägliche Datenbank-Backups, Offsite-Kopien und getestete Wiederherstellungen als Teil des verwalteten Dienstes.
Die Vorbeugung-Hälfte dieses Leitfadens – SSH-Schlüssel, Firewall, automatische Updates und TLS, damit weniger Vorfälle überhaupt das Backup erreichen.
Wo Ihr Server steht, entscheidet über Latenz und Ausfall-Domain – dieselbe Frage, bevor Sie eine Offsite-Kopie platzieren.
EGYmass übernimmt Hosting, Sicherheit und laufende Verwaltung - damit Sie sich auf Ihr Produkt konzentrieren können.
Kostenlose Beratung