Sicherungen — welche brauche ich und wie nutze ich sie

Server Manager hat vier verschiedene Bereiche rund um Sicherungen, jeweils für ein anderes Ziel. Inhaltlich überschneiden sie sich („meine Daten sichern, damit ich sie nicht verliere“), aber wenn du das falsche Werkzeug wählst, machst du entweder unnötig viel Arbeit oder bekommst eine Datei, die nicht das tut, was du wolltest. Dieser Artikel ordnet jedes Ziel dem richtigen Werkzeug zu und führt dich dann durch jeden Ablauf.

Kurzüberblick — welche Sicherung brauche ich?

Eine einzelne Datei wiederherstellen (Tab Dateien → 🗑 Sicherungen)

Verwende das, wenn: du im Tab Dateien eine Datei gelöscht oder überschrieben hast und sie zurückhaben möchtest.

Server Manager speichert automatisch jede Datei, die der Tab Dateien überschreiben oder löschen würde. Die vorherige Version landet in einem .helm-backup/-Ordner neben dem ursprünglichen Speicherort. Von jedem Namen werden die letzten 3 Versionen aufbewahrt; ältere Versionen werden herausrotiert.

Wichtig — das gilt pro Verzeichnis. Wenn du /var/www/site/blog/post.md gelöscht hast, liegt die Sicherung unter /var/www/site/blog/.helm-backup/, nicht unter /var/www/site/. Um sie zu finden, musst du zuerst in das Verzeichnis wechseln, in dem die Datei lag.

Schritte:

1. Öffne das Service-Panel der Site/App → Tab Dateien.

2. Navigiere zu dem Ordner, in dem die Datei früher lag — zum Beispiel /var/www/mysite.example.com/blog/, wenn du eine Datei in blog/ gelöscht hast.

3. Klicke in der Werkzeugleiste auf 🗑 Sicherungen.

4. Suche den Eintrag anhand von Name + Zeitstempel. Klicke auf Wiederherstellen, um ihn zurückzulegen, auf Herunterladen, um eine Kopie auf deinem Computer zu speichern, oder auf Löschen, um die Sicherung dauerhaft vom Server zu entfernen.

Auch eine Wiederherstellung lässt sich wieder rückgängig machen — der aktuelle Zustand am Zielpfad wird vor der Wiederherstellung in .helm-backup/ als Snapshot gespeichert. So kannst du die Wiederherstellung auf dieselbe Weise zurückrollen.

Was das NICHT abdeckt: Dateien, die über SFTP/FileZilla, SSH, die laufende App selbst oder ein erneutes Deployment geändert wurden. Nur Aktionen im Tab Dateien lösen die automatische Sicherung aus. Wenn du bei einem erneuten Deployment einen Ordner behalten möchtest, verwende .helm-keep.

Eine ganze Site oder App sichern (Tab Backup)

Verwende das, wenn: du ein portables Archiv einer ganzen Site oder App möchtest — Konfiguration, Secrets, Dateien und (bei containerisierten Dingen) die Daten-Volumes —, das du zur sicheren Aufbewahrung oder zum Transport auf deinem Computer behalten kannst.

Der Tab Backup hat drei Aktionen, die alle dasselbe Paketformat verwenden. Sie bilden den Lebenszyklus eines Pakets ab: erstellen → später wiederherstellen → oder auf einen anderen Server übertragen.

Was du oben im Tab siehst. Wenn für diese Workload noch Pakete auf dem Server liegen — meist, weil du ein Backup erstellt und nicht heruntergeladen hast oder ein Upload mitten in einer Wiederherstellung abgebrochen wurde — erscheinen sie oben als Liste mit Größe, Zeitstempel und einem Löschen-Button pro Zeile. Das ist der Bereich zum Aufräumen: Pakete werden nicht automatisch rotiert, alte Pakete belegen also unauffällig Speicherplatz, bis du sie entfernst. Wenn Pakete zu anderen Workloads gehören, siehst du einen kleinen Hinweis mit ihrer Anzahl; öffne den jeweiligen Backup-Tab der Workload, um sie zu bereinigen.

Backup erstellen

1. Öffne das Service-Panel → Tab Backup.
2. Für WordPress, Web-Apps und Datenbanken: Aktiviere Dienst während des Backups pausieren, wenn es sich um eine stark genutzte Site handelt (aktiver Shop, Mitgliedschaftsbereich, laufende Migration). Standardmäßig gibt es keine Ausfallzeit — schnell und in den meisten Fällen völlig ausreichend, aber alles, was während der ca. 30-sekündigen Erfassung geschrieben wird, kann nur teilweise erfasst werden (typischerweise eine verwaiste Datei: im Backup vorhanden, aber ohne DB-Zeile). Mit Pause wird der Dienst kurz angehalten (~30–60s Ausfallzeit), damit die Erfassung vollständig konsistent ist. Bei statischen Sites gibt es diesen Schalter nicht — es gibt keinen verwalteten Prozess, der pausiert werden könnte (Caddy liefert die Dateien direkt aus).
3. Klicke auf Backup erstellen. Der Chat übernimmt — Faro bereitet den tar-Befehl vor, du bestätigst ihn, und das Paket wird auf dem Server erstellt.
4. Wenn es fertig ist, erscheint im Chat ein Herunterladen-Button. Klicke darauf; die Datei wird per SFTP auf deinen Computer übertragen.

Was im Paket enthalten ist: die docker-compose.yml (oder das entsprechende Service-Manifest), jedes Secret in .env, alle benannten Volumes (Datenbankdaten, hochgeladene Dateien usw.) und eine kleine manifest.json, die die Workload beschreibt. Pakete für statische Sites enthalten den Dateibaum unter /var/www/<domain>/. Das Format beschreibt sich selbst — die spätere Wiederherstellung liest das Manifest und baut alles am richtigen Ort wieder auf.

Aus Paket wiederherstellen

Verwende das, wenn: du ein Paket hast, das du früher heruntergeladen hast (oder das dir ein Teammitglied geschickt hat), und den Dienst wiederherstellen möchtest — entweder auf diesem Server oder als Klon mit einer neuen Domain.

1. Öffne das Service-Panel → Tab Backup.
2. Klicke auf Aus Paket wiederherstellen. Ein Upload-Fenster öffnet sich (Drag-and-drop oder klicken zum Auswählen).
3. Wähle das .tar.gz-Paket aus. Klicke auf Hochladen.
4. Nach dem Upload passiert die eigentliche Wiederherstellung im Chat. Faro liest das Manifest des Pakets und stellt es entweder an Ort und Stelle wieder her oder fragt — wenn die Rezept-Struktur des Pakets nicht zur aktuellen Workload passt oder du eine andere Domain angibst —, ob es stattdessen auf eine neue Domain geklont werden soll. Du prüfst und bestätigst jeden Befehl, bevor irgendetwas ausgeführt wird.

Beim Klonen: Das Paket enthält die ursprüngliche Domain in seinem Manifest. Faro fragt nach der neuen Domain und schreibt die Caddyfile + wp-config.php-entsprechenden Referenzen so um, dass der Klon unter der neuen Adresse ausgeliefert wird. Der ursprüngliche Server läuft unverändert weiter.

Auf anderen Server verschieben

Verwende das, wenn: du eine Workload auf einem deiner gespeicherten Server hast und sie auf einen anderen verschieben (oder kopieren) möchtest — ohne das Paket manuell auf deinen Computer herunterzuladen und auf der anderen Seite wieder hochzuladen.

Dieser Button erscheint nur, wenn du mindestens zwei gespeicherte Server in Server Manager hast — die Zielauswahl braucht schließlich ein Ziel.

Voraussetzung: Erstelle zuerst ein Backup auf der Quelle (der Schritt Backup erstellen oben).

1. Öffne auf der Workload des Quellservers das Service-Panel → Tab Backup.
2. Klicke auf Auf anderen Server verschieben. Ein Assistent mit drei Schritten öffnet sich: - Schritt 1: Ziel auswählen. Wähle einen Zielserver aus deiner Liste gespeicherter Server aus und gib die Verschlüsselungs-Passphrase des Ziels ein. - Schritt 2: Backup auswählen. Wähle aus, welches Paket übertragen werden soll (zeigt jedes Paket auf der Quelle an). Klicke auf Übertragung starten. - Schritt 3: Übertragung. Das Paket wird Quelle → Ziel über Server Manager gestreamt — keine Kopie auf deinem Computer, kein öffentliches S3 dazwischen.
3. Wenn das Paket auf dem Ziel angekommen ist, wechselt Server Manager zum Zielserver und bietet dir an, das gerade angekommene Paket wiederherzustellen (ein Klick).

Nur die Datenbank sichern (Tab SQL-Dumps)

Verwende das, wenn: du nur den Datenbankinhalt möchtest, nicht den ganzen Stack. Häufige Fälle: Daten an eine Entwicklerin oder einen Entwickler zum Testen weitergeben, in eine andere Engine importieren (nun ja, es versuchen) oder vor einer destruktiven Migration schnell ein Sicherheitsnetz speichern.

Diesen Tab gibt es nur für Datenbank-Workloads (Postgres, MySQL, MariaDB).

1. Öffne das Service-Panel der Datenbank → Tab SQL-Dumps.
2. Klicke auf Dump erstellen. Faro führt pg_dump / mysqldump aus (passend zur Engine) und speichert die Ausgabe als .sql.gz unter /var/backups/<engine>/.
3. Der neue Dump erscheint in der Liste. Herunterladen überträgt ihn auf deinen Computer; Löschen entfernt ihn vom Server.

SQL-Dumps vs. Tab Backup — gleiche Workload, unterschiedliche Artefakte:

• Der SQL-Dump .sql.gz ist rohes SQL — psql my-app < dump.sql stellt ihn in jeder Postgres-Instanz der passenden Hauptversion wieder her, auch in einer Postgres-Instanz auf deinem Laptop.
• Das Paket aus dem Tab Backup ist ein Full-Stack-.tar.gz — die Datenbank, die Compose-Datei, die Secrets, die benannten Volumes. Die Wiederherstellung erstellt den gesamten Container-Stack neu.

Wenn du Daten nur ansehen oder umziehen möchtest: SQL-Dumps. Wenn du den ganzen Datenbankdienst an anderer Stelle klonen möchtest: Tab Backup.

Dinge, die oft mit Backups verwechselt werden

**.helm-keep-Marker* — behalten einen Ordner über ein erneutes Deployment* hinweg (keine Sicherung, hilft nicht bei versehentlichem Löschen). Nutze sie, wenn du einen Laufzeitordner wie uploads/ hast, der beim Pushen von neuem Code nicht gelöscht werden soll. Beschrieben in Mehrere Sites auf demselben Server.

Einen ganzen Server verschieben. Es gibt keinen einzelnen „Alles verschieben“-Button — Server Manager verschiebt jeweils eine Workload. Um einen Server mit mehreren Sites/Apps zu migrieren, wiederhole den Ablauf Backup erstellen → Auf anderen Server verschieben → Auf dem Ziel wiederherstellen für jede Workload (die Aktion Auf anderen Server verschieben befindet sich im Tab Backup jeder Workload).

Referenz

Wo Sicherungen auf der Festplatte liegen:

• Sicherungen aus dem Tab Dateien → <original-dir>/.helm-backup/<name>.<timestamp> (ein Ordner pro Verzeichnis)
• Pakete aus dem Tab Backup → /tmp/helm-backups/<id>/<bundle>.tar.gz auf dem Quellserver (bis du sie herunterlädst oder löschst)
• Uploads aus dem Wiederherstellen-Tab → /tmp/helm-restore/<id>/<bundle>.tar.gz (bis die Wiederherstellung abgeschlossen ist oder du sie löschst)
• SQL-Dumps → /var/backups/<engine>/<dbname>-<timestamp>.sql.gz

Aufbewahrung:

• Tab Dateien: die letzten 3 Versionen pro ursprünglichem Namen, die älteste wird herausrotiert.
• Tab Backup + SQL-Dumps: keine automatische Rotation — Pakete bleiben auf dem Server, bis du sie im Panel löschst.

Speicherplatz im Blick behalten. Jede Workload-Karte auf dem Startbildschirm zeigt neben ihrem Namen eine · N GB-Markierung, sobald Daten vorhanden sind. Für eine genauere Aufschlüsselung öffnet Serverdetails → auf der Serverkarte die Server-Info mit einem Tab Speicher, der die Speichernutzung pro Workload auflistet (größte zuerst, mit Links zum Öffnen des Panels per Klick), SQL-Dumps über alle Engines hinweg und eine Sammelansicht zum Aufräumen aller bereitgestellten Pakete auf dem Server. Außerdem zeigt der Startbildschirm eine gelbe/rote Warnkarte, wenn die Festplatte 80% / 90% überschreitet.

Secrets in Paketen: Die .env-Dateien in einem Paket aus dem Tab Backup enthalten Secrets im Klartext (Datenbankpasswörter, API-Schlüssel usw.). Behandle heruntergeladene Pakete so, wie du die ursprünglichen .env-Dateien behandeln würdest — nicht per E-Mail verschicken, nicht committen, nicht auf geteilten Laufwerken liegen lassen. Pakete werden nach dem Download vom Quellserver gelöscht (die Datei, die zu dir übertragen wurde, war eine Kopie).