Aus einem Backup wiederherstellen

Du hast ein .tar.gz-Bundle, das du früher gespeichert hast (oder das dir ein Teammitglied geschickt hat, oder das gerade von einem anderen Server angekommen ist). Hier erfährst du, wie du daraus wieder einen laufenden Dienst machst — entweder am ursprünglichen Ort (wobei das Original überschrieben wird, falls es noch existiert) oder als Klon unter einer neuen Domain.

Suchst du die Anleitung zum Erstellen von Backups? Das ist ein eigener Artikel: Backups — welches brauche ich und wie verwende ich es. Dieser Artikel beginnt bei: „Ich habe bereits ein Bundle auf meinem Computer.“

Wo du die Wiederherstellung startest — drei Einstiegspunkte

Gleicher Ablauf, drei Türen. Nimm den Einstieg, der zu deiner Situation passt. (Zwei der Türen verwenden das Menü „Aktionen“ in der oberen Leiste — klicke auf den Begriff, um zu sehen, wo es ist.)

Alle drei Wege öffnen denselben Dialog Aus einem Backup wiederherstellen. Der einzige Unterschied ist, welchen Kontext Server Manager in dem Moment hat, in dem du ihn öffnest:

• Aus einem Dienst-Panel weiß der Dialog, welches Rezept und welchen Workload du erwartest — wenn das hochgeladene Bundle eine andere Struktur hat (z. B. du hast das WordPress-Panel geöffnet, lädst aber ein Postgres-Bundle hoch), zeigt er eine Warnung, damit du eine andere Datei auswählen kannst, bevor irgendetwas ausgeführt wird.
• Aus dem Menü Aktionen gibt es keine Erwartung — wiederhergestellt wird genau das, was im Bundle steht.
• Bei einer eingehenden Übertragung liegt das Bundle bereits auf dem Server; der Dialog bietet einen Ein-Klick-Button Dieses Bundle wiederherstellen an.

Schritt für Schritt

Wähle den Einstieg, der zu deiner Situation passt (siehe Tabelle oben). Der Dialog sieht in allen drei Fällen gleich aus:

Zieh die .tar.gz-Datei auf den Ablagebereich oder klicke irgendwo in den Bereich, um eine Dateiauswahl zu öffnen. Der Dialog akzeptiert Dateien mit der Endung .tar.gz oder .tgz.

Klicke auf Hochladen. Während das Bundle zum Server gestreamt wird, ersetzt ein Fortschrittsbalken den Ablagebereich (Upload in Teilen — selbst mehrere GB große Bundles überstehen wackelige Verbindungen).

Was wird hochgeladen? Dein Computer sendet die .tar.gz-Bytes über einen SFTP-ähnlichen Stream an den Server — verschlüsselt durch die SSH-Sitzung, über die du verbunden bist. Die Datei landet unter /tmp/helm-restore/<id>/<bundle>.tar.gz und bleibt dort, bis die Wiederherstellung abgeschlossen ist (danach wird sie bereinigt).

Wenn der Upload abgeschlossen ist, schließt sich der Dialog und Faro begrüßt dich im Chat mit der Manifest-Zusammenfassung, die es aus dem Bundle gelesen hat: Quelltitel, Quelldomain, Rezept und Zeitstempel des Backups. Dann stellt Faro dir eine kurze Frage:

Möchtest du am ursprünglichen Ort wiederherstellen (das vorhandene <name> überschreiben, falls es noch existiert) oder auf eine neue Domain klonen (das Original unverändert lassen und eine separate Kopie erstellen)?

Das ist der einzige Entscheidungspunkt. Ab hier bestimmt deine Antwort die weiteren Schritte.

4a. Am ursprünglichen Ort wiederherstellen

Wähle das, wenn:

• Der ursprüngliche Workload weg ist (gelöscht oder du bist auf einem frischen Server) und du ihn unter derselben Domain mit denselben Namen zurückholen möchtest.
• Das Original defekt oder falsch konfiguriert ist und du es löschen und aus dem Bundle neu erstellen möchtest.

Was Faro macht:

1. Liest docker-compose.yml und .env aus dem Bundle und erstellt sie unter dem ursprünglichen Installationspfad neu.
2. Stellt jedes benannte Docker-Volume (Datenbankdaten, hochgeladene Dateien usw.) aus den Volumes im Bundle wieder her.
3. Kopiert bei statischen Websites den Dateibaum zurück nach /var/www/<domain>/.
4. Wendet den Caddyfile-Block erneut an, damit die ursprüngliche Domain wieder ausgeliefert wird.
5. Startet den Dienst und führt einen Health Check aus.

Jeder Befehl pausiert und wartet auf deine Freigabe, bevor er ausgeführt wird — der Chat zeigt dir die exakten Zeilen wie docker compose up, tar xzf und caddy reload, die du gleich ausführen wirst.

4b. Auf eine neue Domain klonen

Wähle das, wenn:

• Das Original weiterlaufen soll, während eine Kopie unter einer anderen Domain online geht (Staging, Dev, Demo, zweites Unternehmen …).
• Du auf einen Server wiederherstellst, auf den eine andere Domain zeigt als die Quelldomain im Bundle.

Faro stellt eine zusätzliche Frage: Wie lautet die neue Domain? (z. B. staging.example.com).

Was Faro zusätzlich zu den Schritten der Wiederherstellung am ursprünglichen Ort macht:

1. Wählt einen neuen Compose-Projektnamen (damit die Container des Klons nicht mit denen des Originals kollidieren), z. B. mysite-com → staging-example-com.
2. Schreibt den Caddyfile-Eintrag um, damit er die neue Domain verwendet.
3. Erneuert Secrets in .env (neues DB-Passwort, neue App-Schlüssel) — der Klon teilt keine Zugangsdaten mit dem Original.
4. Führt bei WordPress wp search-replace <old-domain> <new-domain> im geklonten Container aus, damit Links in Beiträgen und Medienmetadaten auf die neue Domain zeigen.
5. Aktualisiert bei Web-Apps alle *_URL- / *_HOST-Umgebungsvariablen, die auf die alte Domain zeigen.
6. Fordert ein neues TLS-Zertifikat für die neue Domain an (Let's Encrypt über Caddy, automatisch).

Das Original läuft unverändert weiter.

Eine Datenbank klonen? Datenbanken haben keine Domain. Faro fragt stattdessen nach einem kurzen Suffix (z. B. staging oder qa) und leitet daraus einen eindeutigen Compose-Projektnamen, Containernamen und Listening-Port ab, damit beide Datenbanken parallel laufen, ohne zu kollidieren.

Wenn die Schritte abgeschlossen sind, zeigt Faro die endgültige URL (Klon) oder die nun wiederhergestellte Domain (am ursprünglichen Ort). Öffne sie im Browser; wenn sie nicht sofort lädt, gib Let's Encrypt 30–60 Sekunden Zeit, um das Zertifikat auszustellen, und versuche es erneut.

Das ursprüngliche Bundle wird automatisch aus /tmp/helm-restore/ entfernt, sobald die Wiederherstellung erfolgreich abgeschlossen ist.

Rezeptstruktur passt nicht

Wenn du den Wiederherstellungsdialog aus einem Dienst-Panel geöffnet hast (z. B. dem WordPress-Panel für mysite.com) und ein Bundle mit einem anderen Rezept hochlädst (z. B. ein Postgres-Bundle), macht der Dialog nicht einfach weiter — er warnt dich:

Du hast zwei Möglichkeiten:

• Andere Datei auswählen — fast immer die richtige Wahl (du hast das falsche Bundle erwischt).
• Dieses Bundle trotzdem verwenden — das Bundle steuert die Wiederherstellung. Dadurch wird also ein neuer Dienst mit dem Rezept aus dem Bundle eingerichtet und NICHT der Dienst geändert, dessen Panel du geöffnet hast. Wähle das nur, wenn dir das klar ist und du es genau so möchtest.

Die Prüfung auf Nichtübereinstimmungen wird nur ausgelöst, wenn der Dialog aus einem Dienst-Panel mit erwartetem Rezept geöffnet wurde. Der Weg Aktionen → Wiederherstellen überspringt sie vollständig (es gibt keine Erwartung, gegen die geprüft werden könnte).

Automatische Wiederherstellung nach einem Server-zu-Server-Umzug

Wenn du auf einem anderen Server Tab „Backup“ → Auf einen anderen Server verschieben verwendet hast und dadurch ein Bundle hierher übertragen wurde, öffnet sich der Wiederherstellungsdialog automatisch; dieses Bundle ist oben hervorgehoben:

Klicke auf Dieses Bundle wiederherstellen. Ab dort ist der restliche Ablauf identisch mit einer frischen Wiederherstellung (Faro fragt „am ursprünglichen Ort wiederherstellen“ oder „klonen“, du gibst Befehle frei usw.). Das Bundle liegt bereits auf dem Server, daher gibt es keinen Upload-Schritt.

Du kannst auch auf Anderes Bundle verwenden … klicken, um das vorgeladene Bundle zu verwerfen und die normale Dateiauswahl zu öffnen — praktisch, wenn du das falsche Bundle übertragen hast und neu anfangen möchtest.

Häufige Fragen

Wo bleibt das Original während eines Klons? Unverändert. Der Klon verwendet andere Containernamen, andere Volumes, andere Ports (bei Datenbanken) und andere Secrets. Du kannst den Klon später löschen, ohne das Original zu beeinflussen.

Kann ich ein Bundle auf einer anderen Linux-Distribution wiederherstellen? Ja. Das Bundle besteht nur aus Docker compose + benannten Volumes + (bei statischen Websites) einem Dateibaum. Server Manager übernimmt auf dem Ziel die distributionsspezifische Docker-Installation, falls Docker dort noch fehlt. Die Ausnahme sind native Web-App-Bundles (ohne Container) — sie hängen vom Paketmanager und systemd der Quelldistribution ab. Der Wiederherstellungsartikel sagt dir, wenn die Installation nicht übertragen werden kann.

Das Bundle ist riesig — läuft der Upload ab? Nein. Der Upload erfolgt in Teilen (~4 MB pro Teil), die der Server anschließend zusammensetzt. Bundles mit mehreren GB funktionieren; wenn deine Verbindung mitten im Upload abbricht, kannst du im Dialog abbrechen und neu starten, statt bei jedem Teil wieder bei null anzufangen.

Was passiert, wenn ich mitten in der Wiederherstellung abbreche? Ein Abbruch während des Uploads löscht die Teildatei und du landest wieder im Ablagebereich. Ein Abbruch während der Chat-Schritte (zwischen Freigaben) lässt alles bestehen, was Faro bereits erledigt hat — manche Container oder Volumes können also bereits existieren. Du kannst die Wiederherstellung mit demselben Bundle erneut ausführen oder Faro zuerst den Zwischenstand bereinigen lassen; wenn irgendetwas seltsam aussieht, frag im Chat nach und Faro diagnostiziert es.

Kann ich dasselbe Bundle mehrfach als verschiedene Klone wiederherstellen? Ja. Öffne den Dialog erneut, lade dasselbe Bundle hoch und wähle jedes Mal Klon mit einer anderen neuen Domain. Das Bundle bleibt dauerhaft gültig (es ist einfach ein Tarball).

Wo bleiben Dateien nach fehlgeschlagenen Wiederherstellungen? Unter /tmp/helm-restore/<id>/ auf dem Zielserver. Die Oberfläche Aktionen auf dem Startbildschirm zeigt verwaiste helm-restore-Verzeichnisse in der Bereinigungsansicht an, falls welche übrig bleiben. Sie können gefahrlos gelöscht werden.

Was hier NICHT behandelt wird

• **.helm-backup/-Dateien** (Rückgängig pro Datei im Tab „Dateien“) → siehe im Artikel Backups den Abschnitt „Eine einzelne Datei wiederherstellen“.
• **Rohe .sql.gz-DB-Dumps** (ladbar in jede Postgres-/MySQL-Datenbank) → siehe im Artikel Backups den Abschnitt „Nur die Datenbank sichern“.
• Wiederherstellen über Rezeptgrenzen hinweg (z. B. ein WordPress-Bundle als statische Website) — Bundles sind rezeptgebunden. Wähle ein Bundle, das zu dem passt, was du starten möchtest.

Referenz

Was die Wiederherstellung auf dem Zielserver braucht:

• Den per SSH erreichbaren Linux-Server, mit dem du in Server Manager verbunden bist.
• Speicherplatz zum Entpacken des Bundles (kurzzeitig ungefähr 2× die Bundle-Größe während des Entpackens).
• Installiertes Docker (Server Manager installiert es automatisch, falls es auf einem frischen Ziel fehlt).

Pfade während der Wiederherstellung:

• Hochgeladenes Bundle (temporär) → /tmp/helm-restore/<id>/<name>.tar.gz
• Entpackte Quelle → /tmp/helm-restore/<id>/extracted/
• Endgültige Installation — derselbe Pfad, den das Original verwendet hat (z. B. /opt/wordpress-mysite-com/, /var/www/mysite.example.com/, …)

Der Entscheidungsbaum auf einen Blick: