Sicherheitsnetz, das getestet ist.
Zwei Schichten parallel: Plattform-Backup auf Block-Ebene plus Plesk-Self-Service — repliziert zwischen Nürnberg und Düsseldorf.
Backup-Strategie ist bei uns kein Add-on und kein Nachgedanke. Sie ist Teil der Plattform — automatisch, in jedem Tarif, mit nachvollziehbarer Frequenz und ehrlich kommunizierter Wiederherstellungs-Zeit. Was wir versprechen, kannst du im Ernstfall einlösen. Welche Frequenz konkret zu deinem Setup passt, entscheidet sich über die SLA-Stufe deines Tarifs.
Sechs Prinzipien, an denen wir uns messen lassen.
Backup ist kein Hexenwerk — wenn man es richtig macht. Wir machen es automatisch, transparent und in zwei voneinander unabhängigen Schichten, damit ein Fehler in der einen die andere nicht trifft.
Zwei Schichten parallel
Plattform-Backup auf Hypervisor-Ebene plus Plesk-Self-Service. Beide laufen unabhängig voneinander — Eingriffsfehler in der einen Schicht treffen die andere nicht.
Standard 24 h, eskalierbar
Plattform-Backup standardmäßig alle 24 Stunden. Engere Frequenzen — 12 h und 6 h — über die passende SLA-Stufe buchbar.
Mindestens 7–14 Tage
Plattform-Retention 7 Tage Standard, Plesk-Retention 14 Tage. Auf Wunsch deutlich länger — Compliance-bedingte Halte-Anforderungen setzen wir individuell um.
1,2 Petabyte Kapazität
Aktuelle Backup-Plattform mit 1,2 PB Brutto-Speicher. Wächst mit unseren Tarifen, ohne dass wir Kompromisse bei der Frequenz machen müssten.
Verschlüsselt übertragen
Replikation zwischen den Standorten läuft über verschlüsselte Tunnel. Keine Daten verlassen unsere Infrastruktur unverschlüsselt.
DSGVO-konform
Backup-Daten bleiben in Deutschland — Nürnberg und Düsseldorf. Verarbeitung dokumentiert, Auftragsverarbeitungs-Vertrag (AVV) Standard.
Plattform-Backup und Plesk parallel.
Zwei unabhängige Backup-Schichten laufen parallel. Die eine ist unser Disaster-Recovery-Anker auf Hypervisor-Ebene, die andere liegt in der Plesk-GUI für Self-Service-Restores. Wer auf das falsche Backup zugreift, bricht das andere nicht.
Plattform-Backup
Bit-genau auf Block- bzw. VM-Ebene über unseren Hypervisor-Backup-Stack. Repliziert zwischen Nürnberg und Düsseldorf, verschlüsselt übertragen. Kunden greifen nicht direkt darauf zu — das ist unser Disaster-Recovery-Anker für den Ernstfall.
- Frequenz: 24 h Standard · 12 h und 6 h via SLA-Stufe
- Retention: 7 Tage Standard, länger nach Vereinbarung
- Restore: über uns, im Ticket oder über die Notfall-Hotline
Plesk-Backup
Pro Domain oder Account in der Plesk-GUI sicher- und wiederherstellbar. Schedule und Retention konfigurieren wir für dich vor — Restore machst du selbst, ohne Ticket. Für klassische „Ich habe gerade aus Versehen den falschen Ordner überschrieben"-Fälle die schnellere Lösung.
- Frequenz: täglich, vorkonfiguriert
- Retention: 14 Tage Standard auf Server & Cluster, 7 Tage auf Managed Hosting
- Restore: Self-Service in der Plesk-GUI, kein Support-Ticket nötig
// Beide Schichten laufen unabhängig. Im Zweifel ziehen wir das Plattform-Backup — es ist konsistent auf Block-Ebene und für Disaster-Recovery die robustere Quelle.
Hardware-Defekte — etwa ein ausgefallenes NVMe-Drive — heilt unsere Storage-Schicht selbst: unser NVMe-Ceph-Storage hält jeden Block dreifach redundant über mehrere Knoten. Da läuft kein Backup-Restore an, das passiert im Hintergrund automatisch. Das Backup ist für logische Schäden da: versehentlich gelöschte Daten, fehlgeschlagene Migrationen, kompromittierte Datenbanken, kaputte Plugin-Updates. Zwei Probleme, zwei Mechanismen.
Vier Schritte. Kein Eingriff von dir.
Das Plattform-Backup läuft ohne dein Zutun — auf Block-Ebene, ohne dein Live-System zu beeinträchtigen. Hier die Mechanik dahinter:
- 01
Live-System läuft
Dein Server arbeitet normal. Kein Performance-Impact durch Backup-Vorbereitung — Block-Level-Snapshots werden ohne Lock auf Datenbanken gezogen.
- 02
Snapshot nach SLA-Frequenz
Vollautomatisch alle 24 h, 12 h oder 6 h — abhängig von der gebuchten SLA-Stufe. Erstellung dauert wenige Minuten und ist transparent für deine Anwendung.
- 03
Replikation ins zweite RZ
Snapshot wird verschlüsselt zwischen Nürnberg und Düsseldorf übertragen — fertig, sobald die Replikation am Zweit-Standort bestätigt ist.
- 04
Aufbewahrung & Rotation
Mindestens 7 Tage werden vorgehalten. Je nach Vereinbarung gestaffelt — täglich, wöchentlich, monatlich. Rotation ist getestet, kein Backup-Black-Box.
// Welche Frequenz konkret greift, hängt von deiner SLA-Stufe ab — Details auf Managed Server und Managed Cluster.
Restore in zwei Klicks — ohne Ticket-Schleife.
Für die häufigsten Restore-Fälle — versehentlich gelöschte Datei, kaputtes Plugin-Update, falsch deployter Branch — brauchst du keinen Support. Plesk hat eigene Backups, die wir für dich vorkonfiguriert haben. Du gehst in die GUI und ziehst, was du brauchst.
Vorkonfiguriert
Schedule und Retention legen wir beim Setup fest — täglich, 14 Tage auf Server & Cluster, 7 Tage auf Hosting. Du musst nichts einrichten, nur nutzen.
Granular wiederherstellen
Komplette Domain, einzelne Datenbank, einzelne Datei oder Mailkonto — selektiv aus dem Backup zurückspielen, ohne den ganzen Account anzufassen.
Sofort verfügbar
Restore startest du selbst, wann es passt. Kein Wartelauf auf ein Support-Ticket, keine Geschäftszeiten-Limitierung.
Geprüft, nicht behauptet.
Backup ist eine Behauptung, bis es im Ernstfall funktioniert. Drei Verfahren stellen sicher, dass aus unserem Backup-Versprechen ein tatsächlich wiederherstellbares System wird — nicht erst, wenn es drauf ankommt.
Restore-Drills regelmäßig
Wir testen quartalsweise stichprobenartig, ob aus dem Plattform-Backup ein lauffähiges System wird — auf einer isolierten Test-Umgebung, mit vollem Hochfahren und Erreichbarkeitsprüfung. Backup ohne Test ist Hoffnung, kein Verfahren.
Immutable gegen Ransomware
Plattform-Backups sind append-only — auch mit Root-Zugriff auf einer kompromittierten VM lassen sie sich nicht aus dem Backup-System löschen oder verschlüsseln. Der Hypervisor-Stack hält die Snapshots in einem getrennten Trust-Layer.
DB-konsistent statt nur block-konsistent
Vor jedem Snapshot laufen Pre-Hooks: MariaDB- und PostgreSQL-Instanzen werden in einen konsistenten Zustand versetzt (FLUSH TABLES WITH READ LOCK bzw. pg_start_backup). So sind die Backups beim Restore sofort startfähig — ohne Repair, ohne InnoDB-Recovery.
Was du im Ernstfall verlieren kannst.
Zwei Kennzahlen entscheiden über die Qualität einer Backup-Strategie — RPO (wie viel Daten verlierst du maximal?) und RTO (wie lange dauert die Wiederherstellung?). Wir nennen beide ehrlich.
≤ 24 / 12 / 6 h
Maximaler Datenverlust im Ernstfall. Hängt direkt an der Plattform-Backup-Frequenz: Standard 24 h, mit der passenden SLA-Stufe 12 h oder 6 h. Im Schnitt liegt der tatsächliche Verlust deutlich darunter.
Minuten bis Stunden
Wie lange die Wiederherstellung dauert, hängt vom Schaden ab. Einzeldatei-Restore in Minuten, kompletter Server in 30 min – 4 h je nach Datenvolumen. Aktive Cluster mit DC-Failover schalten in Sekunden um.
| Datenvolumen | Erwartete Dauer | Typischer Anwendungsfall |
|---|---|---|
| 10 GB | ~ 5 min | z. B. einzelne Domain, kleine WordPress-Installation |
| 100 GB | ~ 30 min | typischer Magento- oder Shopware-Mid-Size-Shop |
| 500 GB | ~ 90 min | größere E-Commerce-Plattform mit Asset-Bibliothek |
| 1 TB | ~ 3 h | Cluster-Knoten, große Pimcore-Instanz |
| 5 TB+ | individuell | großvolumige Workloads — wir planen den Restore-Pfad gemeinsam |
// Werte sind Erwartungswerte aus realen Restore-Vorgängen, abhängig von Backup-Storage-Auslastung und Datenstruktur. Für aktive Cluster-Tarife mit DC-Failover entfällt der Restore — die Übernahme dauert Sekunden.
Wenn es passiert — was dann?
Backup-Strategie ist nur so gut wie ihre tatsächliche Wiederherstellung. Hier ist, wie wir im Ernstfall vorgehen — und warum wir es regelmäßig üben, nicht nur dokumentieren.
Vorfall melden
Über die 24/7-Notfall-Hotline 0800-RACKSPEED. Bei Datenverlust greifen wir sofort, ohne Ticket-Schleife.
Rückspielung beauftragen
Je nach Schaden: einzelne Datei, kompletter Server, oder Failover ins zweite RZ. Wir entscheiden gemeinsam, was die schnellste Lösung ist.
Wiederherstellung
Klassische Rücksicherung: typisch 30 Minuten bis wenige Stunden, abhängig von Datenvolumen. Cluster-Failover binnen Sekunden bei aktiven HA-Pfaden.
Im Notfall: ein Anruf, ein Techniker am Telefon, kein Ticket-System dazwischen. Du erreichst uns rund um die Uhr.
Was Entscheider zu Backup & Recovery fragen.
Werden Datenbanken konsistent gesichert?
FLUSH TABLES WITH READ LOCK, bei PostgreSQL über pg_start_backup bzw. den Replication-Slot. Der Snapshot wird erst nach Bestätigung gezogen, danach läuft die DB normal weiter. Beim Restore startet die Datenbank ohne Repair-Lauf.Wie lange dauert ein Restore eines 500-GB-Servers?
Was passiert bei Komplett-Ausfall eines Standorts?
Kann ich zusätzlich extern sichern — auf eigenen S3 oder zu mir?
rsync/borg/restic auf ein Ziel deiner Wahl. Frequenz und Retention legst du fest, wir betreiben die Pipeline.Sind die Backups vor Ransomware oder Root-Übernahme geschützt?
Wie oft testet rack::SPEED Restores tatsächlich?
Werden Mailkonten und Plesk-Konfiguration mitgesichert?
Wie lange können Backups maximal aufbewahrt werden?
Frage nicht dabei? Sag Bescheid — wir nehmen sie auf, wenn sie für andere Kunden relevant ist.
