Das Problem
Fast jedes Unternehmen hat ein Backup. Die Meldung lautet „erfolgreich“, und damit gilt das Thema als erledigt. In der Praxis finden wir immer wieder:
- nur eine einzige Sicherungsgeneration,
- keine Kopie außer Haus,
- das Sicherungsziel steht neben dem gesicherten System,
- niemand überwacht die Datenträger,
- und niemand weiß, wie lange eine Wiederherstellung dauern würde.
Spätestens wenn ein Kunde, eine Versicherung oder ein Lieferantenfragebogen Nachweise verlangt, wird daraus ein Problem – ebenso wie im Ernstfall.
Unsere Lösung
Wir prüfen den Ist-Zustand, legen mit Ihnen fest, wie viel Datenverlust und Ausfallzeit vertretbar sind, und richten die Sicherung danach ein. Jede Sicherung wird überwacht. Für Ihre wichtigsten Systeme schreiben wir ein Runbook mit Wiederanlauf-Reihenfolge, und wir stellen zur Probe wieder her. Das Ergebnis halten wir in einem Protokoll fest.
Die Begriffe, auf die es ankommt
| Begriff | Was es bedeutet | Was wir tun |
|---|---|---|
| 3-2-1 | 3 Kopien, 2 verschiedene Speicher, 1 außer Haus | lokale Sicherung, getrenntes System, verschlüsselte Kopie außer Haus |
| Offsite | Kopie an einem anderen Standort | verschlüsselt in Rechenzentren in der EU |
| Verschlüsselung | Daten außer Haus sind für Dritte unlesbar | Verschlüsselung vor dem Versand; die Schlüssel verwahren wir getrennt |
| Monitoring | Fehlgeschlagene Sicherungen fallen auf | Überwachung jeder Sicherung mit Alarm |
| Restore-Test | Probe, ob sich Daten und Systeme zurückholen lassen | Wiederherstellung auf einem Testziel, nie über das produktive System |
| RPO | Wie viele Daten dürfen höchstens verloren gehen? | legen wir mit Ihnen fest, daraus ergibt sich das Sicherungsintervall |
| RTO | Wie lange darf ein Ausfall höchstens dauern? | legen wir mit Ihnen fest, der Wiederanlauf wird darauf ausgelegt |
| Wiederanlauf-Reihenfolge | Was muss zuerst laufen (z. B. Verzeichnisdienst, DNS, Datenbank)? | im Runbook festgelegt |
| Runbook | Schritt-für-Schritt-Anleitung für den Ernstfall | für Ihre kritischen Systeme geschrieben |
| Testprotokoll | Nachweis, was wann erfolgreich wiederhergestellt wurde | erhalten Sie nach jedem Test |
Wie man realistische Werte festlegt, beschreiben wir im Beitrag RPO und RTO realistisch festlegen.
Was 3-2-1 nicht abdeckt
Drei Kopien schützen vor einem Hardwaredefekt oder einem Brand. Vor einem Angreifer mit Administratorrechten schützen sie nur, wenn er die Sicherungen weder erreichen noch löschen kann. Deshalb prüfen wir ausdrücklich:
- Hat das Sicherungsziel eigene Zugangsdaten, getrennt vom Produktivnetz?
- Lassen sich Sicherungen von einem kompromittierten Server aus löschen?
- Gibt es eine Kopie, die sich nachträglich nicht verändern lässt?
Und NIS2?
NIS2 und Lieferantenfragebögen fragen nach Backup, Wiederherstellung und Notfallplanung. Wir unterstützen Sie bei den technischen und organisatorischen Nachweisen zu diesen Punkten. Eine vollständige NIS2-Umsetzung umfasst mehr – etwa Risikomanagement, Meldewege und Schulungen – und ist keine Rechtsberatung.
Ergebnis
- Mehrere Sicherungsgenerationen, eine davon verschlüsselt außer Haus
- Überwachte Sicherungen statt stiller Fehler
- Festgelegte Werte für Datenverlust (RPO) und Ausfallzeit (RTO)
- Ein Runbook mit Wiederanlauf-Reihenfolge
- Testprotokolle als Nachweis
So gehen wir vor
- Befund – Welche Systeme werden wie gesichert? Wo sind Lücken?
- RPO/RTO festlegen – für jedes kritische System.
- Einrichten – Sicherung lokal und auf getrenntem System.
- Offsite – verschlüsselte Kopie außer Haus.
- Überwachen – jede Sicherung mit Alarm.
- Runbook – Wiederanlauf-Reihenfolge festlegen.
- Testen – Probe-Wiederherstellung mit Protokoll.
Leistungsumfang
- Befund
- RPO/RTO-Workshop
- Einrichtung der Sicherung
- Offsite-Kopie
- Verschlüsselung
- Überwachung
- Wiederanlauf-Runbook
- Probe-Wiederherstellung mit Protokoll. Den Testturnus legen wir gemeinsam fest
Technischer Einblick
Bei uns selbst so umgesetzt: Ein separater Ceph-Cluster dient als Sicherungsziel für unsere Produktivcluster, mit Proxmox Backup Server und clientseitiger Verschlüsselung. Eine Kopie wird per rclone auf Storage Boxen an zwei Standorten gespiegelt. Konfigurationen und GitLab sichern wir zusätzlich mit Borg in Repositories, aus denen sich nichts löschen lässt (append-only). Backup-Metriken laufen in InfluxDB und Grafana.
Restore-Tests: Unsere eigenen Sicherungen testen wir nach festem Turnus – Proxmox-Sicherungen quartalsweise rotierend je Cluster, Borg-Archive halbjährlich, einmal jährlich eine vollständige Wiederherstellung aus der Offsite-Kopie. Ergebnisse werden datiert im Runbook protokolliert, zum Beispiel die Wiederherstellung und Entschlüsselung einer verschlüsselten VM-Sicherung inklusive Prüfung der gesamten Schlüsselkette.
Bestandsumgebungen: Vorhandene Sicherungen – etwa Image-Backups auf ein NAS – binden wir ein, ergänzen Snapshots, Aufbewahrung und eine verschlüsselte Offsite-Kopie mit restic.
Warum cloudbase.run
- Eigene Praxis. Wir betreiben einen eigenen Backup-Cluster mit Offsite-Spiegel und testen unsere Wiederherstellungen nach Plan.
- Wiederanlauf statt nur Kopie. Runbooks mit Reihenfolge schreiben wir auch für Kundenumgebungen.
- Kombinierbar mit Infrastructure as Code. Daten zurückspielen ist ein Teil, Systeme wieder aufbauen der andere.
Für wen geeignet
- KMU, Praxen und Kanzleien mit eigenen Servern
- Zulieferer, die Backup-Nachweise in Fragebögen oder für die TISAX-Vorbereitung erbringen müssen
- Unternehmen, die wissen wollen, wie lange ein Wiederanlauf wirklich dauert
Für wen nicht geeignet
- Wer nur günstigen Speicherplatz pro Terabyte sucht – dafür gibt es spezialisierte Speicheranbieter
- Wer keine Zeit für einen Restore-Test einplanen will