Backup und Wiederherstellung

Ein vollständiges Backup braucht drei Bestandteile. Fehlt einer, ist die Wiederherstellung unvollständig:

1. Datenbank — Konten, Links, Protokolle, Einstellungen, Seiten. Das ist der wesentliche Teil: Hier stecken die Slugs.
2. storage/app/ — Logo, eigenes Theme, aktualisierte Public Suffix List.
3. .env — enthält APP_KEY.

# Datenbank
mysqldump --single-transaction --quick -u <user> -p <db> | gzip > db-$(date +%F).sql.gz

# Ablagen
tar czf storage-$(date +%F).tar.gz -C /var/www/shortlink storage/app

Bei einem Kürzungsdienst ist das Datenbank-Backup die eigentliche Sicherung. Geht die Datenbank verloren, sind nicht „Daten" weg, sondern jede ausgegebene Adresse ist ungültig — jeder gedruckte Flyer, jeder QR-Code, jeder Link in einer alten Mail. Ein Kürzungsdienst hat keine Kopie beim Nutzer, aus der man nachladen könnte: Der Nutzer hat nur die kurze Adresse, und was dahinter stand, wusste ausschließlich dieser Server.

Und schlimmer als „weg" ist „teilweise wiederhergestellt": Ein Backup, das einen Teil der Slugs nicht enthält, gibt sie zur Neuvergabe frei. Der nächste angelegte Link kann einen alten erben.

Ohne APP_KEY sind das gespeicherte SMTP-Passwort und verschlüsselte Sitzungen unlesbar. Beides lässt sich neu setzen — die Slugs nicht.

Der Knopf in der Oberfläche: Einstellungen → Wartung

Unter Einstellungen → Wartung liegt oben Datenbank herunterladen. Er liefert je Treiber:

Wofür er gedacht ist — und wofür nicht. Er ist der Handgriff vor einem Eingriff: vor dem Aufräumen, vor einem Update, vor dem Umschalten des Link-Modus. Er ist kein Ersatz für die regelmäßige Sicherung oben — die läuft ohne Klick und liegt nicht im Download-Ordner eines Arbeitsplatzrechners.

Ohne mysqldump und ohne Shell-Aufruf. Der Dump wird in PHP erzeugt. Der Grund ist nicht Vorliebe: Auf gehärteten und geteilten Hosts sind exec/shell_exec gesperrt und mysqldump liegt dort oft gar nicht. Ein Knopf, der bei der Hälfte der Installationen eine leere Datei liefert, ist schlimmer als keiner — man merkt es erst, wenn man die Sicherung braucht.

• Nur die Tabellen dieser Installation. Ist DB_PREFIX gesetzt, werden ausschließlich Tabellen mit diesem Präfix gesichert. In einer geteilten Datenbank bleiben fremde Anwendungen unberührt. Ohne Präfix ist diese Grenze nicht zu erkennen — dann werden alle Tabellen des Schemas gesichert.
• Gelesen wird in Blöcken (500 Zeilen) und der Text als Strom ausgeliefert. Der Speicherbedarf bleibt damit unabhängig von der Größe von click_logs.
• PostgreSQL und SQL Server stehen in config/database.php, werden hier aber nicht bedient. Der Knopf erscheint dann nicht; stattdessen steht ein Hinweis auf die Werkzeuge des Datenbanksystems.

Die Datei ist selbst ein personenbezogener Datenbestand. Sie enthält Passwort-Hashes, Sitzungen, Klick-Protokolle mit gekürzten IP-Adressen und Versandprotokolle mit Empfängeradressen. Verschlüsselt aufbewahren, nicht in einen geteilten Ordner legen, nach Gebrauch löschen.

Sie enthält die .env NICHT — und damit nicht den APP_KEY. Die Spalten two_factor_secret und two_factor_recovery_codes sind mit ihm verschlüsselt. Wer die Datenbank ohne die passende .env zurückspielt, hat eine Installation, in die niemand mit zweitem Faktor mehr hineinkommt: Die Daten sind da, der Schlüssel fehlt. Sichere die .env immer zusammen mit der Datenbank.

Scheitert die Sicherung, steht der Grund im Protokoll (storage/logs). Die häufigsten Ursachen sind fehlender Platz und fehlendes Schreibrecht im Temp-Verzeichnis des Servers.

Wiederherstellung

gunzip < db-2026-08-14.sql.gz | mysql -u <user> -p <db>
tar xzf storage-2026-08-14.tar.gz -C /var/www/shortlink
php artisan storage:link
php artisan config:cache

Danach prüfen: Anmeldung, ein Aufruf eines bestehenden Shortlinks (leitet er weiter?), ein passwortgeschützter Link, Test-Mail, Einstellungen → Systemdaten (Schreibrechte), und Einstellungen → Links (steht die Domain-Liste noch?).

Teste die Wiederherstellung, bevor du sie brauchst. Ein Backup, das nie zurückgespielt wurde, ist eine Annahme, keine Sicherung.