Zum Inhalt springen 
Ich bestehe im Webhosting auf eine klare 3-2-1 Backup-Strategie mit Webhosting Backup, Offsite Backup, Immutability, RPO, RTO, DSGVO und regelmäßigem Restore Test, damit ich Ausfälle kontrolliert überstehe. Ich fordere messbare Ziele und nachvollziehbare Prozesse, damit die 3-2-1 Backup-Regel nicht nur auf dem Papier existiert, sondern im Ernstfall schnell Ergebnisse liefert.
Zentrale Punkte
- 3-2-1-Regel: Drei Kopien, zwei Medien, eine Kopie offsite – plus unveränderliche Sicherung als Extra.
- Häufigkeit: Tägliche Backups, stündliche Datenbank-Sicherungen, Versionierung und PITR.
- Immutability: WORM/Object Lock verhindert das Löschen oder Überschreiben durch Angreifer.
- RPO/RTO: Klare Ziele und geprüfte Restore-Pfade minimieren Ausfall und Datenverlust.
- Transparenz: Protokolle, SLA, Kostenklarheit und regelmäßige Restore-Tests.
Was bedeutet 3-2-1 konkret im Webhosting?
Ich plane mindestens drei Kopien: das Original im Hosting, eine zweite Sicherung auf anderem Medium sowie eine dritte Kopie an einem Offsite-Standort. Zwei unterschiedliche Speicherarten senken das Risiko von gleichzeitigen Ausfällen durch Hardware, Storage-Treiber oder Ransomware. Eine geografisch getrennte Kopie schützt mich gegen Rechenzentrumsprobleme, Brandzonen-Ausfälle und Admin-Fehler. Zusätzlich setze ich auf die Erweiterung 3-2-1-1-0: eine unveränderliche Kopie (WORM) plus Backups ohne Fehler in der Prüfsumme. So halte ich meine Wiederherstellungschancen hoch, selbst wenn das Produktivsystem komplett kompromittiert wurde.
Checkliste: Darauf bestehe ich beim Hoster
Ich verlange vollständige Sicherungen von Dateien, Datenbanken und E-Mails – konsistent, mit ordentlichen Dumps oder Snapshot-Quiescing, damit Applikationen sauber wiederherstellen. Ohne konsistente Datenbank-Backups verliere ich Transaktionen oder beschädige Tabellen. Ich prüfe, ob stündliche Datenbank-Sicherungen und tägliche Filesystem-Backups verfügbar sind. Versionierung und Point-in-Time-Restore (PITR) für MySQL/MariaDB gehören für mich dazu. Nur so erfülle ich enge RPO-Ziele zuverlässig.
Ich fordere Offsite-Redundanz in einem anderen Rechenzentrum oder bei einem unabhängigen Anbieter, damit keine Organisation zum Single Point of Failure wird. Falls mein Hoster mehrere Regionen hat, verlange ich eine Kopie in einer anderen Brandzone. Ich hinterfrage die physische Trennung, die Netzwerkpfade und die administrativen Grenzen. Eine zweite Organisation für die Offsite-Kopie senkt das Risiko von gemeinsamen Fehlkonfigurationen. Außerdem erfrage ich, ob der Offsite-Speicher echte Immutability anbietet.
Ich bestehe auf unveränderlichen Backups per Immutability/WORM, damit Ransomware und Fehlbedienungen keine Daten löschen. Object Lock mit Retention und optionalem Legal Hold verhindert das Überschreiben bis zum Ablauf der Sperrfrist. Ich dokumentiere die Retention-Logik, damit ich im Notfall weiß, wie weit ich zurückgehen kann. So sichere ich auch gegen Insider-Bedrohungen ab. Für besonders kritische Daten nutze ich längere Sperrzeiten.
Backups dürfen nicht mit denselben Admin-Konten laufen wie das Produktivsystem, deshalb fordere ich Least Privilege und getrennte Konten. MFA/2FA ist Pflicht, Rollen sind strikt getrennt und Schlüssel liegen sicher. Ich prüfe, ob der Provider getrennte Projekte oder Tenants anbietet. Ich verlange Audit-Logs für Backup- und Restore-Aktionen. So erkenne ich Manipulationen und unautorisierte Zugriffe frühzeitig.
Verschlüsselung setze ich überall durch: TLS in Transit und starke Verschlüsselung at Rest, idealerweise mit eigenen Schlüsseln. Die Standorte müssen DSGVO-konform sein, und ich unterschreibe einen AVV, damit die Verarbeitung rechtssicher läuft. Ich dokumentiere Aufbewahrungsfristen nach Compliance-Vorgaben. Auch Metadaten und Indizes müssen verschlüsselt aufbewahrt werden. Das verhindert Informationsabfluss über Dateinamen und Strukturen.
RPO und RTO richtig festlegen
Ich definiere einen maximal zulässigen Datenverlust (RPO) und eine maximale Wiederherstellungszeit (RTO) und halte beides vertraglich fest. Für Shops und Portale ist oft ein RPO von 1 Stunde sinnvoll, bei CMS mit wenig Transaktion reicht auch 4–6 Stunden. Ein RTO von 4 Stunden ist für viele Projekte realistisch, kritische Plattformen brauchen schnellere Ziele. Ohne klare Zeitziele plant niemand Budget und Architektur passend. Restore-Übungen belegen, ob die Ziele erreichbar sind.
| Aspekt | Beschreibung | Typischer Wert | Nachweis/Prüfung |
|---|---|---|---|
| RPO | Maximaler tolerierter Datenverlust | 1 Stunde (DB mit PITR) | Binlogs, Zeitstempel, Restore auf Zeitpunkt |
| RTO | Maximale Wiederherstellungszeit bis produktiv | 4 Stunden | Playbooks, Stoppuhr, Protokoll |
| Aufbewahrung | Versionen und Retention Tage | 7/30/90 | Plan, Lifecycle-Policy, Kostenübersicht |
| Testfrequenz | Regelmäßige Restore-Tests | monatlich/vierteljährlich | Bericht, Hash-Prüfung, Screenshots |
Ich dokumentiere, wie ich die Messwerte erhebe und welche Tools ich nutze. Ohne diese Transparenz bleiben RPO/RTO theoretisch und helfen mir im Notfall nicht. Ich halte zudem fest, welche Komponenten kritisch sind und daher mit Priorität wiederherstellen. Für Datenbanken definiere ich PITR und sichere Binlogs passend. Für Medien-Dateien brauche ich Versionierung und klare Retention.
Offsite und Immutability praktisch umsetzen
Ich setze die dritte Kopie konsequent in eine andere Region oder zu einem unabhängigen Anbieter, damit Firewalls, Admin-Konten und Abrechnungen getrennt sind. Object Storage mit aktivierter Immutability (z. B. Object Lock) verhindert das Löschen binnen der Retention. Ich prüfe die Regionstrennung und verifiziere, dass der Provider unterschiedliche Brandzonen nutzt. Eine gute Einführung liefert die kompakte Übersicht zur 3-2-1-Regel im Hosting. So eliminiere ich das Risiko, dass eine Fehlkonfiguration gleich alle Kopien betrifft.
Ich übertrage Offsite-Backups nur verschlüsselt und mit eigenen Schlüsseln oder Passphrasen. Zusätzlich isoliere ich Zugangsdaten, damit ein Einbruch auf dem Webserver nicht automatisch den Offsite-Speicher öffnet. Ich setze getrennte IAM-Rollen und MFA durch. Ich dokumentiere den Löschschutz nachvollziehbar, damit Audits ihn bewerten können. Retention-Änderungen dürfen nur wenige Personen beantragen.
Sicherheit: Zugriffe, Verschlüsselung, DSGVO
Ich trenne Zugriffe strikt und gebe Backups nur die minimal nötigen Rechte. Kein identischer Root-Account, kein geteiltes Passwort, keine gemeinsam genutzten Schlüssel. Ich erzwinge MFA beim Provider und bei eigenen Cloud-Konten. Die Daten verschlüssele ich clientseitig oder serverseitig mit sicheren Verfahren. So mindere ich das Risiko, dass ein Dieb aus Speichermedien Inhalte ausliest.
Ich achte auf DSGVO-konforme Standorte und schließe einen AVV mit klarer Zweckbindung. Ich prüfe, ob Logs Metadaten enthalten, die als personenbezogen gelten können. Retention und Löschkonzepte halte ich schriftlich fest. Für Auskunfts- und Löschanfragen brauche ich nachvollziehbare Prozesse. So bleibe ich rechtlich sicher und vermeide Bußgelder.
Restore Test: Wiederherstellung regelmäßig üben
Ich teste die Wiederherstellung nicht nur theoretisch, sondern führe regelmäßige Restore-Übungen auf einer isolierten Staging-Umgebung durch. Dabei messe ich Zeiten, dokumentiere Schritte und fixiere Hürden. Ich vergleiche Prüfsummen von Dateien und prüfe Applikationskonsistenz über Funktions-Checks. Datenbanken spiele ich bis zu einem gewünschten Zeitpunkt (PITR) zurück und kontrolliere Transaktionen. Erst dieser Beleg zeigt, ob RPO/RTO realistisch sind.
Ich halte Playbooks bereit: Welche Person startet den Restore, wo liegen Zugangsdaten, wie erreiche ich den Support, welche Priorität haben Systeme. Ich schreibe die Reihenfolge auf: Datenbank zuerst, dann Dateien, dann Konfigurationen. Ich bewahre wichtige Passwörter offline auf. Nach jedem Test aktualisiere ich Dokumentation und Zeiten. So werde ich von einem echten Notfall nicht überrascht.
So baue ich ein eigenes 3-2-1-Setup
Ich halte mich an die Struktur: Produktivdaten auf dem Webserver, zweite Kopie auf ein NAS oder anderen Storage, dritte Kopie Offsite mit Immutability. Für Dateien nutze ich restic oder BorgBackup mit Deduplikation und Verschlüsselung. Für Datenbanken setze ich mysqldump, Logical Backups mit konsistenten Locks oder Percona XtraBackup. Für Transfers eignet sich rclone mit Bandbreitenlimit und Wiederholungen.
Ich plane Retention nach GFS (täglich/wöchentlich/monatlich) und buche genügend Speicher für Versionierung. Cronjobs oder CI orchestrieren Sicherungen und Prüfungen. Monitoring meldet Fehler per E-Mail oder Webhook. Eine kompakte Einordnung liefert dieser Beitrag zu Backup-Strategien im Webhosting. So behalte ich Kontrolle, selbst wenn mein Hoster wenig anbietet.
Automatisierung und Monitoring
Ich automatisiere alle wiederkehrenden Schritte und dokumentiere exakte Kommandos. Skripte prüfen Exit-Codes, Hashes und Zeitstempel. Fehlgeschlagene Backups lösen sofortige Alarme aus. Ich speichere Logs zentral und manipulationssicher. Zusätzlich limitiere ich Bandbreite und führe Health-Checks des Offsite-Ziels durch.
Ich bespreche mit dem Hoster API-Zugänge, SFTP/rsync und S3-kompatible Endpunkte, damit ich unabhängige Restore-Pfade nutzen kann. Ich halte Kosten für Egress und Restore-Services fest, damit am Ende keine Überraschungen entstehen. Ich prüfe, ob Self-Service-Restores für einzelne Dateien und komplette Accounts verfügbar sind. Wenn nicht, plane ich eigene Werkzeuge ein. So spare ich Zeit im Ernstfall.
Häufige Fehler – und wie ich sie vermeide
Ich verlasse mich nie auf eine einzelne Kopie oder dasselbe Storage-System. Snapshots allein reichen mir nicht, wenn sie weder Offsite noch unveränderlich sind. Ich prüfe Datenbankkonsistenz, statt nur Files wegzukopieren. Überwachung und Restore-Tests gehören in meinen Kalender. Unklare Aufbewahrung oder fehlende Versionierung verursachen im Notfall lange Ausfälle.
Ich überprüfe außerdem, ob die Restore-Kosten transparent sind und keine Gebühren das Zurückspielen verzögern. Ich vermeide Geteilte-Admin-Konten und setze überall MFA. Ich halte Verfahren für Schlüsselrotation fest. Ich führe mindestens vierteljährlich einen Test-Restore durch. Fehler aus diesen Übungen fließen in meine Playbooks.
SLA, Transparenz und Kosten
Ich lasse mir die Backup-Architektur mit Diagrammen und Prozessen erklären. Dazu gehören Monitoring-Berichte, Alarmwege und Reaktionszeiten. Ich fordere 24/7-Notfallkontakte und erfrage Zeitfenster, in denen Restores priorisiert laufen. Zudem verlange ich klare Kostentabellen für Speicher, Egress und Dienstleistungen. Fehlt das, plane ich zusätzlichen Puffer im Budget ein.
Für kritische Projekte kombiniere ich Backups mit DR-Szenarien und vermeide Single Points of Failure. Hier lohnt sich ein Blick auf Disaster-Recovery-as-a-Service, wenn ich Failover-Zeiten reduzieren will. Ich dokumentiere Eskalationsketten und Testtermine. Außerdem halte ich Kontaktwege redundant vor. So stelle ich sicher, dass mir im Ernstfall niemand fehlende Zuständigkeiten bestätigt.
Was sichere ich zusätzlich – über Dateien und Datenbanken hinaus?
Ich sichere nicht nur Webroot und Datenbank, sondern alle Komponenten, die meine Plattform ausmachen. Dazu gehören DNS-Zonen, TLS-Zertifikate, Cronjobs, Webserver- und PHP-Konfigurationen, .env-Dateien, API-Schlüssel, SSH-Keys, WAF-/Firewall-Regeln, Weiterleitungen und E-Mail-Filter. Ich exportiere auch Paketlisten, Composer/npm-Lockfiles und Anwendungs-Configs. Bei Mail setze ich auf vollständige Backups der Maildir-Ordner sowie separate Exporte von Aliasen und Transportregeln. Für Multi-Account-Hosting sichere ich zudem Panel-Konfigurationen, damit ich ganze Accounts nachvollziehbar wiederherstellen kann.
Ich entscheide bewusst, was ich nicht sichere: Caches, Sessions, temporäre Uploads und generierbare Artefakte (z. B. optimierte Bilder) lasse ich außen vor, um Kosten zu sparen und Restore-Zeiten zu verkürzen. Für Suchindices oder feingranulare Caches dokumentiere ich, wie sie im Restore-Fall automatisiert neu aufgebaut werden.
Backup-Methoden und -Topologien im Vergleich
Ich wähle pro Workload die passende Methode: Logical Dumps (z. B. mysqldump) sind portabel, brauchen aber mehr Zeit. Physische Hot-Backups (z. B. über Snapshot-Mechanismen) sind schnell und konsistent, erfordern jedoch passende Storage-Funktionen. Ich nutze Quiescing (fsfreeze/LVM/ZFS) dort, wo es möglich ist, und sichere InnoDB-Binlogs für echtes PITR. Für File-Backups setze ich auf inkrementell-forever mit Deduplikation.
Ich entscheide zwischen Push- und Pull-Topologie: Bei Pull initiiert ein Backup-Server die Sicherung und reduziert das Risiko kompromittierter Quellsysteme. Bei Push stoßen die Applikationsserver Backups selbst an – das ist einfacher, benötigt aber strenge IAM-Trennung und Egress-Kontrollen. Agentbasierte Verfahren bieten tiefere Konsistenz, agentlose sind leichter zu betreiben. Ich dokumentiere meine Wahl samt Risiken.
Granularität und Wiederherstellungspfade
Ich plane mehrere Restore-Arten: einzelne Dateien, Ordner, einzelne Tabellen/Datensätze, ganze Datenbanken, Postfächer, komplette Webhosting-Accounts. Für CMS/Shop-Systeme priorisiere ich „DB zuerst, dann Uploads/Medien, dann Konfiguration“. Ich halte einen Blue/Green-Ansatz bereit: Restore in Staging, Validierung, anschließend kontrollierter Switch. So minimiere ich Downtime und reduziere Überraschungen im Produktivbetrieb.
Ich stelle sicher, dass Self-Service-Restores möglich sind: Nutzer können eigenständig eine Version wählen, Zeitpunkte durchsuchen und gezielt wiederherstellen. Für Notfälle halte ich einen „Break-Glass“-Prozess bereit: Notfallzugriff mit Protokollierung, zeitlich befristet und nach dem Vier-Augen-Prinzip.
Integrität, Prüfsummen und stille Datenkorruption
Ich vertraue Backups nur mit Ende-zu-Ende-Integrität. Jedes Artefakt erhält Prüfsummen (z. B. SHA256), die getrennt gespeichert und regelmäßig verifiziert werden. Ich plane „Scrubbing“-Jobs, die Offsite-Objekte stichprobenbasiert oder vollständig lesen und Hashes vergleichen. So entdecke ich Bitrot oder Übertragungsfehler frühzeitig. Zusätzlich speichere ich Manifest-Dateien mit Pfaden, Größen und Hashes, um Lücken detektieren zu können.
Ich automatisiere Test-Restores als Integritätsnachweis: Täglich stichprobenartiges Files-Restore, wöchentlich vollständige DB-Restores mit PITR, monatlich End-to-End-Probe inklusive Applikations-Healthcheck. Die Ergebnisse landen in Berichten mit Zeitstempeln, Logauszügen und Screenshots.
Leistung, Zeitfenster und Ressourcen
Ich definiere Backup-Zeitfenster, die Lastspitzen vermeiden und Transaktionszeiten respektieren. Deduplikation, Kompression und inkrementelle Läufe reduzieren das Transfer- und Speicheraufkommen. Ich limitiere Bandbreite (rclone/restic throttle), setze auf parallele Uploads und Chunking und berücksichtige CPU- und IO-Budgets. Große Mediabestände sichere ich differenziell und teile sie in Segmente, um Timeouts zu vermeiden. Ich dokumentiere, wie lange ein Voll- und ein Inkrementallauf dauert – und ob das mit meinem RPO/RTO harmoniert.
Kapazitäts- und Kostenplanung
Ich rechne Kapazitäten konservativ: Datenbestand, tägliche Änderungsrate, Kompressions-/Dedupe-Faktor, Retentionsstufen (GFS). Daraus erzeuge ich eine monatliche Prognose und Budget-Obergrenzen. Ich plane unterschiedliche Speicherklassen (hot/warm/cold) und setze Lifecycle-Policies für automatische Verschiebungen innerhalb der Retention. Egress-, API- und Restore-Kosten halte ich fest. Ich vergleiche die erwarteten Kosten eines Ausfalls (Umsatzverlust, SLA-Penalties) mit Backup-Ausgaben – so argumentiere ich Budget fundiert.
Organisation, Rollen und Vier-Augen-Prinzip
Ich trenne Rollen strikt: Wer sichert, darf nicht löschen; wer Retention ändert, braucht Genehmigung. Kritische Aktionen (Löschen, Retention verkürzen, Immutability deaktivieren) laufen unter Vier-Augen-Prinzip mit Ticket-Referenz. Ich definiere Eskalationsketten, Vertretungen und Bereitschaften. Break-Glass-Zugänge sind versiegelt, zeitlich begrenzt und werden nach Nutzung rotierend erneuert. Audit-Logs zeichnen alle Aktionen unveränderlich auf.
Spezifika gängiger Plattformen
Für WordPress sichere ich DB, wp-content (Uploads, Themes, Plugins) sowie wp-config.php und salts. Bei Shops kommen Queue-/Job-States, Zahlungs- und Versand-Plugins sowie Medien-CDNs hinzu. Bei Multisite-Setups dokumentiere ich die Zuordnung von Domains zu Sites. Ich sichere außerdem Redirect- und SEO-Settings, um Traffic-Verluste nach Restores zu vermeiden. Suchindices (z. B. Elasticsearch/OpenSearch) sichere ich als Snapshot oder rekonstruiere sie skriptgestützt, damit nach einem Restore Suchfunktionen rasch wieder bereitstehen.
Disaster Recovery und Infrastruktur-Reproduzierbarkeit
Ich minimiere RTO, indem ich Infrastruktur reproduzierbar mache: Konfiguration als Code (z. B. Server- und Panel-Settings), wiederholbare Deployments, feste Versionsstände. Ich bewahre Anwendungsgeheimnisse verschlüsselt und versioniert auf und rotiere sie nach einem Sicherheitsvorfall. Für DR plane ich Alternativstandorte und dokumentiere, wie ich DNS, TLS, Caching und Mail-Routing im Krisenfall umschalte. Ich halte Abhängigkeiten fest (Drittanbieter-APIs, Zahlungsprovider) und bereite Fallbacks vor.
Recht und Compliance im Backup-Kontext
Ich gleiche Aufbewahrungsfristen mit Löschpflichten ab: Für personenbezogene Daten definiere ich Prozesse, wie ich Löschanfragen praktisch umsetze, ohne die Integrität historischer Backups zu gefährden. Ich dokumentiere, welche Datenkategorien in Backups landen, und minimiere Metadaten. TOMs (technische und organisatorische Maßnahmen) beschreibe ich auditierbar: Verschlüsselung, Zugriffskontrolle, Protokollierung, Immutability, geografische Grenzen. Ich halte Risiken bei Drittlandübermittlungen fest und entscheide über Standorte entsprechend meiner Compliance-Anforderungen.
Praxisnahe Prüfungen und Kennzahlen
Ich definiere klare KPIs: Erfolgsquote der Backups, Alter des letzten erfolgreichen Backups, Zeit bis zum ersten Byte im Restore, vollständige Restore-Zeit, Fehlerraten pro Quelle, Anzahl geprüfter Versionen, Zeit bis zur Alarmierung. Diese Metriken vergleiche ich regelmäßig mit meinen RPO/RTO-Zielen. Ich plane Game-Days: gezielte, kontrollierte Ausfälle (z. B. absichtlich gelöschte Ordner), um Reaktionswege, Alarme und Restore-Pfade unter Druck zu testen. Die Ergebnisse fließen in mein Verbesserungsprogramm.
FAQ kurz
Wie oft sichere ich vernünftig? Ich nutze tägliche Backups für Dateien und stündliche Sicherungen für Datenbanken; bei starkem Traffic wähle ich kürzere Intervalle. Wie lange bewahre ich Versionen auf? 30–90 Tage sind gängig, zusätzlich halte ich monatliche Langzeitstände vor. Was ist RPO vs. RTO? RPO ist mein maximaler Datenverlust, RTO die Zeit bis alles wieder online ist. Beides schreibe ich in Verträge und teste die Werte.
Wie sichere ich E-Mails? Ich ziehe Maildir/Postfächer separat und teste Restore einzelner Ordner. Wie gehe ich mit großen Mediendateien um? Deduplikation und inkrementelle Backups sparen Kosten; Versionierung ermöglicht gezielte Wiederherstellung. Was bedeutet Immutability praktisch? Ein Löschschutz mit Retention verhindert Manipulation bis zum Ablauf. Wie integriere ich WordPress oder Shops? Ich sichere Dateien, DB und Konfiguration und dokumentiere die Reihenfolge.
Kurz zusammengefasst
Ich bestehe auf 3-2-1 mit Offsite und Immutability, klaren RPO/RTO-Zielen, regelmäßigen Tests und sauberer Dokumentation. Ich verankere Verantwortlichkeiten, Playbooks und Messwerte. Ich fordere Self-Service-Restores und nachvollziehbare Kosten. Ich halte DSGVO-Anforderungen inklusive AVV ein und sichere Schlüssel sowie Konten strikt ab. So komme ich nach einem Vorfall zügig zurück online – mit planbarem Aufwand und nachvollziehbarer Qualität.
