Drupal-Backup - und Disaster-Recovery-Strategien

Was ist ein Drupal-Backup und warum ist es wichtig?

Ein Drupal-Backup ist der Prozess, regelmäßig sichere Kopien aller Komponenten zu erstellen, die eine Website zum Laufen benötigt. Nur Dateien zu kopieren oder lediglich einen Datenbank-Dump zu ziehen, ergibt ein unvollständiges Backup. Ein vollständiges Drupal-Backup deckt drei zentrale Ebenen ab:

• Datenbank: Hier liegen sämtliche Inhalte, Nutzerinformationen, Konfigurationen und Sitzungsdaten. Ohne einen Datenbank-Dump lässt sich der Content nicht wiederherstellen.
• Nutzerdateien: Bilder, PDFs, Kursmaterialien, Fotos von Lehrenden — alle hochgeladenen Medien. Diese befinden sich in der Regel unter sites/default/files.
• Code und Konfiguration: Drupal Core, Module, individueller Code, Theme-Dateien und exportierte Konfigurationsdateien (Config Sync).

Ein Backup ist nicht nur ein Sicherheitsnetz für den Ernstfall — es spielt auch bei geplanten Vorgängen eine entscheidende Rolle. Vor einem Update des Drupal Core, bei der Installation eines neuen Moduls, bei umfangreichen Änderungen an Berechtigungsstrukturen oder Anzeigekonfigurationen oder vor einer größeren Content-Migration wird dringend empfohlen, ein Backup anzulegen. Selbst gut getestete Updates können sich in einer Produktivumgebung mit individuellem Code unvorhersehbar verhalten.

Warum ist das so wichtig?

Datenverlust beginnt in der Regel nicht mit einem Cyberangriff — er beginnt mit menschlichem Versagen, einem fehlgeschlagenen Update, einer beschädigten Speicherung oder einem Ausfall beim Hosting-Anbieter. Deshalb reicht „wir haben ein Backup" allein nicht aus. Entscheidend ist, wo das Backup liegt, wie oft es ausgeführt wird und wie oft es getestet wird.

Backup und Disaster Recovery sind nicht dasselbe

Diese beiden Begriffe werden oft synonym verwendet, bezeichnen jedoch unterschiedliche Konzepte. Ein Backup ist der Vorgang, eine Kopie der eigenen Daten zu erstellen. Ein Disaster-Recovery-Plan ist die vollständige Sammlung von Verfahren, die befolgt werden, um eine Website nach einem Ausfall innerhalb eines festgelegten Zeitrahmens auf einem definierten Service-Level wieder online zu bringen.

Anders ausgedrückt: Ein Backup ist eine Datei; ein Disaster-Recovery-Plan ist ein schriftliches Dokument. Der Plan legt klar fest, wer was wann tut, wo die Backups gespeichert werden, wie lange die Wiederherstellung dauert und welches Maß an Datenverlust akzeptabel ist.

RTO und RPO: die zwei zentralen Kennzahlen des Disaster Recovery

Ein professioneller Disaster-Recovery-Plan hat zwei kritische Parameter:

• RTO (Recovery Time Objective): die maximal akzeptable Zeitspanne, bis das System wieder betriebsbereit ist. Beträgt der RTO beispielsweise 2 Stunden, muss die Website innerhalb von 2 Stunden nach einem Ausfall wieder online sein.
• RPO (Recovery Point Objective): das maximal akzeptable Zeitfenster für Datenverlust. Beträgt der RPO 1 Stunde, darf nach der Wiederherstellung höchstens eine Stunde an Daten verloren gehen — das bedeutet, Backups müssen mindestens stündlich laufen.

Bei Universitätswebsites müssen diese Kennzahlen umso strenger festgelegt werden, je näher Einschreibungszeiträume, die Bekanntgabe von Prüfungsergebnissen oder Akkreditierungsprozesse rücken. Eine Website, die am Bewerbungstag ausfällt, schadet mit einem Schlag sowohl der Erfahrung der Studieninteressierten als auch dem Ruf der Institution.

Die 3-2-1-Backup-Regel: der Industriestandard

In der Backup-Welt ist die 3-2-1-Regel der Goldstandard:

• Man sollte mindestens 3 Kopien seiner Daten haben (1 Original, 2 Backups).
• Diese Kopien sollten auf mindestens 2 verschiedenen Medien oder Geräten liegen.
• Mindestens 1 Kopie sollte offsite aufbewahrt werden.

Für Drupal funktioniert diese Regel in der Praxis so: Die erste Kopie liegt auf dem Produktivserver, der die Website betreibt, die zweite Kopie auf einem unabhängigen Backup-Server oder einem Cloud-Speicherdienst (wie Amazon S3 oder Azure Blob) und die dritte Kopie an einem völlig separaten Standort. Ein Backup, das auf demselben Server gespeichert ist, hört in dem Moment auf, ein Backup zu sein, in dem der Server ausfällt.

Backup-Methoden für Drupal-Websites

Das Drupal-Ökosystem bietet mehrere Backup-Methoden. Welche davon geeignet ist, hängt von der Website-Größe, dem Traffic, der technischen Kapazität des Teams und der Hosting-Infrastruktur ab.

Backup and Migrate Modul

Das bekannteste Backup-Modul von Drupal. Es unterstützt Backups von Datenbank, Dateien und Code, geplante Backup-Definitionen, gzip/bzip/zip - Komprimierung und optionale Verschlüsselung. Die Oberfläche eignet sich gut für kleine und mittelgroße Websites — da die Backups jedoch vollständig auf dem Produktivserver gespeichert werden, reicht das Modul allein nicht als Disaster-Recovery-Lösung aus. Fällt der Server aus, geht auch der Zugriff auf die Backups verloren.

Backup über die Kommandozeile mit Drush

Drush ist das Kommandozeilen-Tool von Drupal. Befehle wie drush sql-dump für Datenbank-Dumps und drush archive-dump zum gemeinsamen Archivieren von Code und Datenbank ermöglichen es, einen vollständigen Backup-Workflow zu skripten. In Kombination mit Cron auf dem Server lässt sich so eine automatisierte, planbare Backup-Pipeline aufbauen. Diese Methode ist entwicklerfreundlich und für große Websites zuverlässiger als modulbasierte Lösungen.

Server-seitige (Snapshot-)Backups

Dies ist die Backup-Methode auf Basis von Festplatten-Snapshots, die von Hosting-Anbietern oder Cloud-Plattformen angeboten wird. Verwaltete Drupal-Plattformen wie Pantheon, Acquia und Platform.sh bieten automatisierte, snapshot-basierte Backups. Der Vorteil: Es wird ein Momentaufnahme-Abbild des gesamten Servers erstellt. Der Nachteil: Manche Anbieter nutzen diese Backups nur für ihre eigenen internen Disaster-Recovery-Prozesse — das bedeutet, der Website-Betreiber erhält keinen Ad-hoc-Zugriff zur Wiederherstellung. Das sollte vor Vertragsabschluss unbedingt geprüft werden.

Restic Backup Modul

Das Modul Restic Backup bietet einen moderneren Ansatz und eignet sich besonders gut für das Backup hochgeladener Dateien. Inkrementelle Backups und Deduplizierung halten die Speicherkosten niedrig. Es kann auf SFTP- oder S3-Ziele sichern. Für Universitätswebsites mit umfangreichen Medienbibliotheken bietet eine Kombination aus Git für den Code, Retention Database Backup für die Datenbank und Restic für Dateien einen umfassenden Schutz.

Backup-Häufigkeit und Aufbewahrungsrichtlinie

Die Backup-Häufigkeit hängt davon ab, wie schnell sich die Website verändert. Für ein Universitätsportal mit regelmäßigen Content-Updates und vielen gleichzeitigen Nutzern könnte eine praktikable Aufbewahrungsrichtlinie so aussehen:

Diese Richtlinie kann je nach Änderungsgeschwindigkeit der Website und Sensibilität der Daten weiter verschärft werden. An Tagen der Prüfungsergebnisveröffentlichung oder während Einschreibungszeiträumen ist es beispielsweise sinnvoll, das Backup-Intervall auf Stunden zu verkürzen.

Drupal-Backup für den Hochschulbereich: Was ist anders?

Eine Unternehmenswebsite und eine Universitätswebsite scheinen auf den ersten Blick ähnliche Backup-Anforderungen zu haben, doch die Details der Umsetzung unterscheiden sich erheblich.

• Multisite-Architektur: Universitäten betreiben in der Regel Dutzende Subsites für die Hauptwebsite, Fakultäten, Institute, die Bibliothek und Forschungszentren. Jede benötigt ihre eigene Backup-Richtlinie, doch alle müssen unter einem einheitlichen Disaster-Recovery-Rahmen verwaltet werden.
• LMS-Integration: Bei Drupal-Websites, die mit Moodle, Canvas oder institutionellen LMS-Plattformen integriert sind, muss das Backup Integrationsparameter und Caches konsistent erfassen.
• Personenbezogene Daten und Vorschriften: Studierendendaten unterliegen dem Datenschutzrecht. An Standorten in der EU gilt die DSGVO (Datenschutz-Grundverordnung) — in Deutschland ergänzt durch das BDSG (Bundesdatenschutzgesetz) sowie gegebenenfalls landesspezifische Datenschutzgesetze der Hochschulen; in den USA gilt die FERPA, in Kalifornien die CCPA, und andere Regionen haben ihre eigenen Rahmenwerke. Backups müssen verschlüsselt und mit kontrolliertem Zugriff versehen sein.
• Spitzenlastzeiträume: Während Einschreibungszeiträumen, Bewerbungstagen oder der Bekanntgabe von Prüfungsergebnissen müssen die RTO/RPO-Schwellenwerte enger gefasst werden. Die Kosten eines Ausfalls sind in diesen Zeiträumen um ein Vielfaches höher als an gewöhnlichen Tagen.
• Akkreditierung und Audits: Prüfungen wie ABET, AACSB oder regionale Akkreditierungsstellen können verlangen, dass der Content-Verlauf der Website aufbewahrt und abrufbar bleibt. Hier werden langfristige Archiv-Backups unverzichtbar.

Schritt-für-Schritt-Plan zur Disaster Recovery in Drupal

Ein Backup allein ist noch kein Disaster-Recovery-Plan. Die folgenden Schritte bieten einen Disaster-Recovery-Rahmen, der auf Hochschulebene anwendbar ist.

1. Kritische Assets inventarisieren. Auflisten, welche Systeme (Hauptwebsite, Bewerbungsportal, Bibliothek, Alumni) welche Prioritätsstufe haben.
2. RTO- und RPO-Werte für jedes System festlegen. Das bestimmt direkt die Backup-Häufigkeit und die Wahl der Technologie.
3. Die Backup-Architektur nach dem 3-2-1-Prinzip aufbauen: Produktion, separater Server oder Cloud, offsite.
4. Backups verschlüsseln. Das ist eine Compliance-Anforderung der DSGVO, FERPA und ähnlicher Vorschriften — und ein durchgesickertes Backup stellt ohnehin ein erhebliches Sicherheitsrisiko dar.
5. Den Wiederherstellungsprozess dokumentieren. Wer macht was, in welcher Reihenfolge? Wer übernimmt, wenn die verantwortliche Person im Urlaub ist?
6. Den Disaster-Recovery-Plan regelmäßig testen. Ein Plan, der nur auf dem Papier existiert, versagt in der Regel, wenn tatsächlich eine Krise eintritt.
7. Mit Versionskontrolle integrieren. Den Code in Git verwalten, sodass Backups nur die Datenbank und Dateien abdecken müssen.
8. Einen Kommunikationsplan vorbereiten. Im Voraus festlegen, wie Studierende, Lehrende und die Presse während eines Ausfalls informiert werden.

Vertrauen Sie keinen Backups, die Sie nicht getestet haben

Wenn wir die teuerste Lektion dieser Branche in einem Satz zusammenfassen müssten: Ein ungetestetes Backup ist kein Backup. Viele Teams haben jahrelang Backups durchgeführt, nur um bei ihrem ersten Wiederherstellungsversuch festzustellen, dass das Backup beschädigt, unvollständig oder die falsche Version war.

Die Lösung ist einfach. In regelmäßigen Abständen (zum Beispiel vierteljährlich) sollte eine reale Backup-Datei in einer Staging-Umgebung wiederhergestellt werden. Auf der wiederhergestellten Website werden Content-Integrität, Nutzersitzungen, Konfigurationseinstellungen und Integrationen einzeln überprüft. Die Ergebnisse werden dokumentiert, festgestellte Probleme behoben und ein Testverlauf-Protokoll geführt.

Häufige Fehler beim Backup

• Backups auf demselben Server aufbewahren: Fällt der Server aus, geht auch der Zugriff auf die Backups verloren.
• Nur die Datenbank sichern: Ohne Code und Nutzerdateien lässt sich die Website nicht wiederherstellen.
• Backups nicht verschlüsseln: Ein durchgesickertes Backup verursacht einen Schaden, der einem Sicherheitsvorfall in der Produktivumgebung gleichkommt.
• Den Wiederherstellungsprozess nicht dokumentieren: Improvisation in der Krise erhöht das Fehlerrisiko.
• Backups nicht testen: Ein defektes Backup kann gefährlicher sein als gar kein Backup.
• Die richtige Werkzeugauswahl vernachlässigen: Modulbasierte Backups reichen in manchen kritischen Szenarien nicht aus — sie sollten mit serverseitigen Backups kombiniert werden.

Letzte Aktualisierung: 21.07.2026 11:21