Wie ein Skript meinen Server killte (Und warum du Backups brauchst)

Geschrieben von Joachim Namyslo

Terminal mit Cronjob, Drush-Datenbankdump und Backup-Datei, daneben eine Datenbank und die Uhrzeit 03:00.
Audiodatei
Songs
01

Lesedauer: 3 Minuten

2013 habe ich gelernt, was ein fehlendes Backup kostet: Ein fehlerhaftes Skript hat meinen kompletten Server geleert – Dateien, Datenbank, alles. Ein Backup hatte ich nicht.

Eigentlich wollte ich nur Bookstack installieren. Neben meiner Drupal-Installation. Dass Das offizielle Setup-Script für Ubuntu den ganzen Server abräumen und einfach mal alle Daten aus dem Verzeichnis /var/www löschen würde, damit hatte ich selbstverständlich nicht gerechnet. 

Seit dem weis ich, dass jeder gute Server ein Backup-Skript braucht und auch vom Festplattenplatz her so dimensioniert sein sollte, dass er gut dass doppelte von der Größe der eigentlichen Website in MB aufnehmen kann. Denn Backups solltest du in deiner Installation möglichst automatisieren.

Seit dem kenne ich kenne ich dieses Gefühl, wenn der Magen absackt nur all zu gut. Damit es dir nicht so geht, zeige ich dir in diesem Artikel, wie du dein Drupal-Backup in zehn Minuten automatisierst. 

Du richtest eine Sicherung ein, die jede Nacht von allein läuft, und du lernst den Befehl, mit dem du im Ernstfall alles zurückholst. Vorkenntnisse brauchst du nicht, nur Zugang zum Terminal deines Servers. Du musst auch keine Angst vor dem Terminal haben: Wir kopieren alle Befehle und erklären jeden einzelnen davon.

Was sichern wir überhaupt? Bei Drupal liegen deine Inhalte – Artikel, Nutzer, Einstellungen – in einer Datenbank. Den Code kannst du jederzeit neu herunterladen, die Datenbank nicht. Darum sichern wir sie. Dafür gibt es zwei Wege.

Methode A: Das Bash-Skript

Wenn du kein Drupal-spezifisches Tool nutzen willst, ist ein Bash-Skript der Standard. Es exportiert deine Datenbank, komprimiert sie und legt sie sicher ab. Hier ist das Skript, das ich mir damals gewünscht hätte:

#!/bin/bash

# --- KONFIGURATION (hier deine Daten eintragen) ---
DB_USER="dein_benutzername"
DB_PASSWORD="dein_passwort"
DB_NAME="name_der_datenbank"
BACKUP_DIR="/var/backups/mysql"
TIMESTAMP=$(date +"%Y%m%d%H%M%S")

# --- START DER SICHERUNG ---

# 1. Backup-Verzeichnis anlegen, falls es fehlt
mkdir -p $BACKUP_DIR

# 2. Datenbank exportieren
mysqldump -u$DB_USER -p$DB_PASSWORD $DB_NAME > $BACKUP_DIR/$DB_NAME-$TIMESTAMP.sql

# 3. Datei komprimieren
gzip $BACKUP_DIR/$DB_NAME-$TIMESTAMP.sql

# 4. Optional: alte Backups aufräumen (Vorsicht bei der Aktivierung!)
# find $BACKUP_DIR -type f -name "*.gz" -mtime +7 -exec rm {} \;

echo "Backup erfolgreich: $BACKUP_DIR/$DB_NAME-$TIMESTAMP.sql.gz"

Der Automatismus: Cronjob

Ein Skript alleine bringt dir jedoch  nichts, wenn du vergisst, es regelmäßig auszuführen. Damit dir das nicht passiert, gibt es unter Linux so genannte Cronjobs. Ein Cronjob ist ein Eintrag in der Aufgabenliste deines Servers: Er startet Befehle automatisch zu festen Zeiten. Öffne diese Liste (die Crontab) mit dem Befehl

crontab -e 

 und füge diese Zeile ein:

0 3 * * * /pfad/zu/deinem/backup_script.sh

Die Angabe bedeutet: jeden Tag um 03:00 Uhr morgens, während du schläfst, werden deine Daten gesichert.

Methode B: Der Drush-Weg

Als Drupal-Nutzer hast du ein Werkzeug, das anderen fehlt: Drush, die Kommandozeile für Drupal. Es kennt deine Datenbank-Zugangsdaten bereits aus der settings.php – du musst keine Passwörter in Skripte schreiben. Der Befehl für ein sofortiges, gezipptes Backup der Datenbank:

drush sql:dump --gzip --result-file=auto --extra-dump=--no-tablespaces

 

Der Restore: So holst du deine Seite zurück

Stell dir vor, wie ich damals, hast du versehentlich den Server gelöscht. Aber diesmal hast du eine Datei namens db-2025-05-18.sql.gz. Dieser Befehl stellt sie wieder her. Mach den Test am besten einmal in Ruhe, bevor du ihn wirklich brauchst – ein Backup, das du nicht zurückspielen kannst, hilft dir im Ernstfall nicht:

zcat db-2025-05-18.sql.gz | mysql -u dein_user -p name_der_datenbank

 

zcat entpackt dein Backup, die Pipe (|) schiebt die Daten direkt in den mysql-Befehl, und deine Datenbank ist wiederhergestellt.

Fazit: Lerne aus meinem Fehler von 2013. Technik kann versagen, Skripte können fehlerhaft sein, du kannst dich vertippen. Aber mit einem automatischen Backup ist das kein Totalverlust, sondern ein kurzer Rücksetzer.

Dein nächster Schritt: Nimm dir heute zehn Minuten, leg das Skript an, trag den Cronjob ein und teste einmal den Restore. Hochgeladene Bilder und Dateien liegen nicht in der Datenbank, sondern im Ordner sites/default/files – kopiere ihn regelmäßig zusätzlich. Dann kann dir ein Tippfehler nicht mehr die ganze Seite nehmen.