hyggecloud / backups
Ein Backup ohne Restore-Test ist ein Gerücht.
Die meisten Unternehmen haben Backups. Die wenigsten haben je einen Restore geprobt — und merken das im schlimmsten Moment. Wir bauen Backup- und Disaster-Recovery-Konzepte, die nachweislich funktionieren: mit definierten Wiederherstellungszeiten, verschlüsselten Offsite-Kopien bei einem zweiten EU-Anbieter und Restore-Tests im Kalender.
Die Strategie
3-2-1, aber richtig
Drei Kopien Ihrer Daten, auf zwei verschiedenen Systemen, davon eine außer Haus — bei einem anderen Anbieter, in einem anderen Rechtsraum wäre übertrieben, aber in einem anderen Rechenzentrum eines anderen Betreibers ist Pflicht.
Kopie 1 — Produktion
Ihre Live-Daten mit lokalen Snapshots (VM- oder Volume-Ebene) für den schnellen Rollback bei Fehlkonfigurationen — die „Ups, falsche Tabelle gelöscht"-Versicherung.
Kopie 2 — Gleiches RZ, anderes System
Tägliche (oder stündliche) Backups auf getrennten Storage — restic für Dateien, pgBackRest/WAL-Archivierung für Datenbanken mit Point-in-Time-Recovery.
Kopie 3 — Offsite, anderer Anbieter
Verschlüsselte Kopie bei einem zweiten EU-Provider (z. B. Produktion bei Hetzner, Offsite bei OVH oder Exoscale). Wenn ein Anbieter komplett ausfällt, existiert Ihre Firma trotzdem noch.
RPO & RTO
Zwei Zahlen, die Ihre Geschäftsführung kennen sollte
„Wie viel dürfen wir verlieren?"
Der maximale Datenverlust im Katastrophenfall, gemessen in Zeit. Tägliche Backups = bis zu 24 Stunden Verlust. Für Transaktionsdaten oft inakzeptabel — dann arbeiten wir mit kontinuierlicher WAL-Archivierung (Minuten) oder synchroner Replikation (Sekunden). Kostet mehr; deshalb entscheidet das der Business Case, nicht der Techniker.
„Wie lange dürfen wir stehen?"
Die Zeit vom Ausfall bis zum Wiederanlauf. Ohne geprobten Prozess ist jede RTO-Angabe Fiktion. Wir definieren die RTO gemeinsam, bauen die Wiederherstellung als dokumentiertes Runbook — und messen sie im Restore-Test nach. Steht im Protokoll, nicht im Bauchgefühl.
# Offsite-Backup laden (OVH → Staging) ... ✓ 840 GB
# Datenbank wiederherstellen (PITR) ...... ✓ 11:42 Uhr gestern
# App-Stack hochfahren ................... ✓ 6/6 Services
# Integritätsprüfung (Checksums) ......... ✓ 100 %
➜ Gemessene RTO: 2h 14min (Ziel: < 4h)
➜ Protokoll → Compliance-Ordner. Kaffee verdient.
Warum der Test so wichtig ist
Backups scheitern leise: ein voller Storage, ein abgelaufener Key, ein Cronjob, den ein Update deaktiviert hat. Das fällt erst auf, wenn man wiederherstellen muss — also im teuersten Moment.
Deshalb gilt bei uns: Jedes Backup-Konzept enthält geplante Restore-Tests (quartalsweise in Hygge Care), mit Protokoll für Ihren Auditor und Ihre Cyber-Versicherung. Letztere fragt übrigens zunehmend genau danach.
Konkret
Was wir sichern — und womit
| Ebene | Werkzeug | Frequenz (typisch) | Besonderheit |
|---|---|---|---|
| Datenbanken (PostgreSQL/MySQL) | pgBackRest / WAL-G | kontinuierlich (WAL) + täglich voll | Point-in-Time-Recovery auf die Minute |
| Dateien & Volumes | restic | stündlich bis täglich | dedupliziert, verschlüsselt (AES-256), append-only |
| Kubernetes-Workloads | Velero | täglich | Cluster-State + Persistent Volumes als Einheit |
| VMs (Proxmox) | Proxmox Backup Server | täglich | inkrementell, Live-Backup ohne Downtime |
| Object Storage | rclone (Provider-übergreifend) | täglich | Sync zu zweitem EU-Anbieter mit Object-Lock |
| Konfiguration & IaC | Git (ohnehin versioniert) | bei jeder Änderung | Die Umgebung selbst ist reproduzierbar — per Definition |
// Frequenzen sind Startwerte — die echten Intervalle leiten sich aus Ihrem RPO ab, nicht umgekehrt
Klartext
Die drei häufigsten Backup-Lügen
- „Der Provider macht doch Backups." — Provider-Snapshots schützen vor Hardware-Ausfall, nicht vor gelöschten Datenbanken, Ransomware oder einem gekündigten Account. Ihre Daten, Ihre Verantwortung.
- „RAID ist doch ein Backup." — RAID schützt vor Plattenausfall. Ein
DROP TABLEwird auf alle Platten gleichzeitig gespiegelt. Zuverlässig. - „Wir haben noch nie ein Backup gebraucht." — Glückwunsch. Feuerversicherungen kündigt man auch nicht, weil es noch nie gebrannt hat.
„Disaster Recovery ist wie Zahnseide: Alle wissen, dass man es tun sollte, die meisten fangen erst nach dem ersten Schmerz an.
Der Unterschied: Beim Datenverlust gibt es keine Krone als Ersatz."
— Das HyggeCloud-Prinzip
Wann war Ihr letzter Restore-Test?
Wenn Sie zögern müssen, ist das die Antwort. Im Hygge Check prüfen wir auch Ihre bestehende Backup-Lage — unabhängig davon, ob Sie migrieren oder bleiben.
→ Backup-Lage prüfen lassenTeil des Hygge Checks · oder als kompaktes Einzel-Assessment