Kopie zapasowe hostingu. Dwie warstwy, każdej nocy.

1. Ein Backup, das funktioniert, bevor du es brauchst

Ein Backup ist nur dann hilfreich, wenn es zum Zeitpunkt eines Ausfalls bereits vorhanden ist, nicht erst, wenn jemand versprochen hat, dass es erstellt wird. Bei Saplo ist das Box-Backup ein Snapshot des gesamten LXC-Containers. Dieser wird automatisch um 4:00 Uhr nachts erstellt, ohne dass der Kunde eingreifen muss. So musst du vor riskanten Updates nicht mehr an den manuellen Export der Datenbank denken.

Die Aufbewahrungsfrist, also die Anzahl der Tage, die eine Kopie gespeichert bleibt, steigt mit dem Tarif: Box L bietet 7 Tage und Box XL 14 Tage, Box XXL 30 Tage sowie eine zusätzliche Offsite-Kopie. Diese wird über einen eigenen Mechanismus (borg) unabhängig vom lokalen Snapshot auf demselben Server jede Nacht um 1:00 Uhr an einen entfernten Standort in Helsinki erstellt.

Box S und Box M enthalten kein Backup im Preis, da es sich um Einsteiger-Tarife für Projekte handelt, bei denen die Backup-Kosten den Preis des gesamten Tarifs für alle Kunden erhöhen müssten, auch für diejenigen, die es nicht benötigen, zum Beispiel bei einer Testseite oder einem Portfolio ohne sich ändernde Daten.

2. Zwei Backup-Ebenen, nicht nur eine

Der lokale LXC-Snapshot (backup_limit in Tagen) schützt vor dem häufigsten Szenario: einem Fehler beim Update, einem defekten Plugin oder dem versehentlichen Löschen von Daten durch den Kunden selbst. Die Wiederherstellung ist schnell, weil sie auf demselben physischen Server erfolgt, ohne dass Daten über das Netzwerk übertragen werden müssen.

Die Offsite-Kopie, im Tarif Box XXL verfügbar, schützt vor einem deutlich selteneren, aber gravierenderen Szenario: dem Ausfall des gesamten physischen Servers oder des Rechenzentrums. Die Kopie in Helsinki ist physisch vom Produktionsserver in Falkenstein getrennt. Selbst ein vollständiger Ausfall des Servers bedeutet daher nicht den Verlust der Kundendaten.

Die Unterscheidung dieser beiden Ebenen ist bei der Wahl des Tarifs wichtig: Ist ein Projekt geschäftskritisch, etwa ein Shop mit echten Transaktionen oder eine SaaS-Anwendung mit zahlenden Kunden, solltest du einen Tarif mit Offsite-Backup in Betracht ziehen und nicht nur einen lokalen Snapshot.

3. Backup bei Konkurrenten: Was im Preis enthalten ist und was du dazukaufen musst

Bei Root-VPS-Tarifen werden Backups von Konkurrent A 28 Tage lang aufbewahrt. Die Wiederherstellung aus einer Kopie ist jedoch nur auf Anfrage und gegen Aufpreis möglich, weil die Kunden den Server selbst verwalten und der Anbieter das Backup als zusätzliche Leistung statt eines vollständig automatisierten Prozesses behandelt (öffentliche Preislisten, Tarifbeschreibung von Konkurrent A, Stand 2026-10-10).

Bei Windows-VPS-Tarifen desselben Anbieters wird täglich ein Backup des gesamten Servers auf einem externen Server abgelegt. Je nach gewähltem Tarif und zusätzlichen Funktionen beträgt die Aufbewahrung 7 bis 28 Tage (öffentliche Preislisten, Stand 2026-10-10). Das ähnelt dem Modell von Saplo, erfordert jedoch einen geeigneten, teureren VPS-Tarif.

Bei vielen Shared-Hosting-Anbietern ist ein Backup verfügbar, doch die Wiederherstellung ist oft zusätzlich kostenpflichtig oder auf eine bestimmte Anzahl von Wiederherstellungen pro Monat begrenzt. In der Praxis bedeutet das: Das Backup schützt zwar vor Datenverlust, ist aber nicht immer kostenlos, wenn du es wirklich brauchst.

Bei Saplo ist in den Tarifen mit enthaltenem Backup (Box L, Box XL, Box XXL) keine zusätzliche Gebühr für die Wiederherstellung aus einem Snapshot erforderlich. Denn sie ist Teil desselben automatisierten Mechanismus und keine kostenpflichtige, separate Intervention durch den Support.

4. Für wen es sich eignet

Für ein Testprojekt oder ein Portfolio ohne dynamische Daten ist Backup nicht kritisch. Im Problemfall reicht es, die Website aus dem Code oder dem Git-Repository wiederherzustellen.

Bei einem Shop, einem CRM oder einer Anwendung mit echten Kundendaten ist Backup keine Option mehr, sondern Voraussetzung. Der Verlust der Bestelldatenbank oder von Kontaktdaten verursacht direkte geschäftliche Kosten und ist nicht nur eine Unannehmlichkeit.

Für geschäftskritische Projekte, etwa SaaS mit zahlenden Kunden oder Finanzsysteme, solltest du Box XXL mit einer Offsite-Kopie in Betracht ziehen. Ein lokaler Snapshot auf demselben Server schützt nicht vor dem Ausfall des physischen Servers selbst.

5. Wie die Wiederherstellung aus einem Backup in der Praxis abläuft

Die Wiederherstellung aus einem lokalen Snapshot erfolgt über das Saplo-Panel: Wähle das Datum der Kopie aus und bestätige die Wiederherstellung. Im typischen Szenario musst du den Support nicht kontaktieren, da die Wiederherstellung Teil des automatisierten Backup-Mechanismus ist.

Da der Snapshot den gesamten Container umfasst, werden bei der Wiederherstellung alle Bestandteile gleichzeitig wiederhergestellt: Dateien, Datenbank und Anwendungskonfiguration. Das ist einfacher als die manuelle Wiederherstellung der Datenbank und der Dateien aus zwei verschiedenen Quellen.

Bei einer Offsite-Kopie (Box XXL) dauert die Wiederherstellung vom Standort in Helsinki länger als aus einem lokalen Snapshot, weil die Daten über das Netzwerk übertragen werden müssen. Sie ist jedoch die einzige Möglichkeit, wenn der Produktionsserver vollständig ausfällt.

Teste die Wiederherstellung, bevor du sie wirklich brauchst, beispielsweise mit einer Testkopie der Anwendung. So weißt du, wie lange sie dauert und was dich erwartet, statt es erst während einer echten Störung zu lernen.

Die Backup-Historie ist im Panel mit den Ausführungsdaten sichtbar. So kannst du einen bestimmten Tag für die Wiederherstellung auswählen, etwa den Tag vor einem fehlerhaften Plugin-Update, das die Website funktionsunfähig gemacht hat.

6. Backup, DSGVO und personenbezogene Kundendaten

Ein Backup der Datenbank mit personenbezogenen Kundendaten, etwa Bestellungen im Shop oder CRM-Kontakte, unterliegt denselben DSGVO-Regeln wie die Produktionsdaten. Es ist daher wichtig zu wissen, wo sich die Kopie physisch befindet und wie lange sie aufbewahrt wird.

Die Backup-Aufbewahrung, je nach Tarif 7, 14 oder 30 Tage, bedeutet, dass vom Kunden in der Produktionsumgebung gelöschte Daten während dieses Zeitraums noch in der Backup-Kopie vorhanden sein können. Das ist bei der Umsetzung des Rechts auf Löschung relevant.

Die Offsite-Kopie in Helsinki befindet sich physisch außerhalb des Produktionsservers in Falkenstein. Das solltest du bei der Bewertung berücksichtigen, wo die personenbezogenen Kundendaten, die in das Backup einfließen, tatsächlich gespeichert sind.

Für Unternehmen, die personenbezogene Daten in größerem Umfang verarbeiten, etwa Shops, CRM und medizinische Systeme, bietet ein höherer Tarif mit längerer Aufbewahrung und Offsite-Kopie einen besseren Schutz vor Datenverlust. Er erfordert aber auch das Wissen, wo diese Kopien physisch liegen.

7. Ausfallszenarien und was das Backup tatsächlich schützt

Das häufigste Szenario, vor dem das Backup schützt, ist ein menschlicher Fehler: eine versehentlich gelöschte Website, ein fehlgeschlagenes Plugin-Update, das die Datenbank beschädigt hat, oder eine unüberlegte Codeänderung, die ohne Tests in der Produktionsumgebung eingeführt wurde.

Ein zweites Szenario ist ein Angriff: Eine gehackte Website mit eingeschleustem Schadcode. Die Wiederherstellung aus einer Kopie von vor der Infektion ist meist schneller, als jede Datei und jeden Datenbankeintrag manuell auf Schadcode zu prüfen und zu bereinigen.

Das dritte, seltenste, aber schwerwiegendste Szenario ist der Ausfall des physischen Servers oder des Rechenzentrums. Davor schützt ausschließlich eine physisch getrennte Offsite-Kopie, denn ein lokaler Snapshot auf demselben Datenträger übersteht dessen Ausfall nicht.

Bei den meisten kleinen Projekten sind die ersten beiden Szenarien deutlich wahrscheinlicher als das dritte. Ein lokaler Snapshot (Box L, Box XL) bietet daher zu einem angemessenen Preis echten Schutz. Eine Offsite-Kopie (Box XXL) lohnt sich erst bei Projekten, in denen selbst ein seltener, aber katastrophaler Serverausfall inakzeptabel ist.

Auch wichtig: Ein Backup schützt nicht vor geschäftlichen Fehlern, etwa einem falschen Preis im Shop oder falschen E-Mail-Inhalten, die durch eine Automatisierung versendet wurden. Solche Fehler sind Teil der Daten, die das Backup getreu mitsamt den übrigen Daten kopiert, ohne einen Fehler vom korrekten Zustand unterscheiden zu können.

Prüfe regelmäßig, auch nur kurz, ob das Backup tatsächlich ausgeführt wird. Das Datum der letzten Kopie siehst du im Panel. So erkennst du ein Problem mit dem Backup-Mechanismus, bevor es im ungünstigsten Moment sichtbar wird, also genau dann, wenn du das Backup am dringendsten brauchst.

8. Wie Saplo den Backup-Status an Kunden mitteilt

Die Transparenz des Backup-Mechanismus ist genauso wichtig wie die Existenz des Backups selbst: Du solltest jederzeit prüfen können, wann die letzte Kopie erstellt wurde, ohne den Support nach dem Backup-Status deiner Anwendung fragen zu müssen.

Das Saplo-Panel zeigt die Historie der ausgeführten Backups mit Datum. So kannst du selbst prüfen, ob der Mechanismus ordnungsgemäß funktioniert, statt dich ausschließlich auf die Angabe in den Nutzungsbedingungen zu verlassen, dass jeden Nacht ein Backup erstellt wird.

Bei einem Problem mit dem Backup-Mechanismus, etwa wenn ein Snapshot wegen einer technischen Störung in einer Nacht nicht ausgeführt wurde, informiert das Saplo-Team über solche Vorfälle. Das entspricht dem Grundsatz, dass ein Nachweis wichtiger ist als die bloße Zusage, dass alles planmäßig funktioniert.

Bei geschäftskritischen Projekten, etwa Shops oder Anwendungen mit zahlenden Kunden, ist es eine gute Praxis, den Backup-Status regelmäßig selbst zu prüfen, auch nur einmal im Monat. Das gilt unabhängig davon, wie gut der automatische Mechanismus im Alltag funktioniert.

Eine klare Information darüber, welche Tarife ein Backup enthalten und für welche ein Aufpreis anfällt, hilft dir, die Box bewusst auszuwählen. So erfährst du nicht erst dann, dass es kein Backup gibt, wenn du es bereits brauchst.

9. Backup als Teil der Risikoanalyse eines Projekts, nicht als spätere Ergänzung

Bei der Planung eines neuen Projekts sollte von Anfang an bewertet werden, wie teuer der Datenverlust zu einem bestimmten Zeitpunkt der Entwicklung wäre: Bei einer Website im Aufbau ist er gering, da sich Code und Inhalte aus dem Repository wiederherstellen lassen. Bei einem Shop mit echten Bestellungen kann jedoch bereits der Verlust eines einzigen Tages Daten erhebliche finanzielle Folgen haben.

Diese Bewertung sollte die Wahl des Box-Plans von Anfang an beeinflussen und nicht auf einen Zeitpunkt verschoben werden, an dem das Projekt bereits einen realen Geschäftswert hat. Denn zu diesem Zeitpunkt erfordert die Migration zu einem Plan mit Backup einen zusätzlichen, wenn auch einfachen, Administrationsschritt, statt bereits Teil der ursprünglichen Entscheidung zu sein.

Für schrittweise wachsende Projekte, etwa eine zunächst einfache Website, die später um einen Shop oder ein Buchungssystem erweitert wird, ist genau dieser Übergang der natürliche Zeitpunkt, ein Backup zu erwägen: wenn die App beginnt, Daten zu speichern, deren Verlust wirklich wehtut, und nicht länger nur dekorative Website-Inhalte.

Die Kosten eines in einem höheren Box-Plan enthaltenen Backups lassen sich auch mit den Kosten manuell erstellter Eigenkopien wie Datenbankexporten und Dateiarchivierungen vergleichen. Zwar sind diese auf jedem Plan technisch möglich, sie erfordern aber eine regelmäßige Routine, die ein automatischer Backup-Mechanismus vollständig übernimmt.

Die endgültige Entscheidung, ob ein Backup erforderlich ist, sollte immer auf einer realistischen Bewertung des Werts der in der App gespeicherten Daten beruhen, nicht auf dem Preis einer Zusatzoption oder eines höheren Plans. Denn der tatsächliche Risikofaktor ist hier der Wert der verlorenen Daten, nicht die Kosten des Backups.

10. Zusammenfassung: Backup als bewusste Entscheidung, nicht als Zufall

Die Wahl eines Plans mit im Preis enthaltenem Backup, etwa Box L und höher, oder der Kauf eines Backups als Zusatzoption für den Einstiegsplan sollte auf einer bewussten Bewertung des Werts der in der jeweiligen App gespeicherten Daten beruhen und nicht auf Zufall oder Unkenntnis darüber, welcher Plan ein Backup enthält und welcher nicht. Bei einem Testprojekt oder Portfolio ist das Risiko gering. Bei einem Shop, einem CRM-System oder einer App mit zahlenden Kunden ist ein Backup jedoch keine Option mehr, sondern Teil der grundlegenden Verantwortung für den laufenden Geschäftsbetrieb, ähnlich wie eine Versicherung oder andere Standardmaßnahmen zur Absicherung operativer Risiken. Die Kosten des passenden Plans mit enthaltenem Backup sind normalerweise gering im Vergleich zu den Kosten schon eines einzigen Tages mit verlorenen Transaktionsdaten. Daher lässt sich diese Entscheidung im Budget jedes ernsthaft geführten Onlineprojekts leicht begründen.