Daten sichern und wiederherstellen

Seit Containly 2.2.0 sichert die Seite Backups (Tastenkürzel G R) die Daten eines Stacks (benannte Volumes, den Stack-Ordner mit Compose-Datei und .env, die Container-Konfiguration mit Image-Digests), eines einzelnen Containers oder eines einzelnen Volumes und stellt sie wieder her. Manuelle Backups, Wiederherstellung auf demselben Host, Datenbank-Dumps, Download und Import sowie die Aufbewahrung sind kostenlos. Zeitpläne, geplante Prüfung und die Ziele S3 und SFTP brauchen Pro (seit 2.3.0). Ab Containly 2.5.0 brauchen auch die Ziele SMB und NFS sowie das Wiederherstellen auf einem anderen Docker-Host Pro.

Verfügbar ab Containly 2.5.0: anonyme Volumes, SMB- und NFS-Ziele und Wiederherstellen auf einem anderen Host. Aktualisiere deine Installation, um diese Funktionen zu nutzen (siehe die Anleitung zum Aktualisieren).

Video: Containly-Backups in 7 Minuten zeigt Ziele, Pläne, Datenbank-Dumps, Wiederherstellen sowie Herunterladen und Importieren.

Ein Backup-Ziel anlegen

Unter Ziel hinzufügen wählst du, wohin die Sicherungen geschrieben werden:

• Ein Ordner auf dem Docker-Host (Standard /var/backups/containly). Containly schreibt über einen kurzlebigen, gehärteten Hilfscontainer mit gemountetem Pfad. Das funktioniert auf Socket-, TCP-, SSH- und Agent-Hosts. Nimm einen absoluten Pfad, nicht unter /etc, /proc, /var/lib/docker oder einem Stack-Ordner.
• Ein Ordner im Containly-Container: unter /backups (eigener Mount) oder im Daten-Volume unter /data/backups.

Bei beiden Ordner-Arten öffnet Durchsuchen (seit 2.4.0) einen Ordner-Explorer: Ordner durchklicken, neu anlegen und auswählen, statt den Pfad zu tippen.

• S3-kompatibler Speicher (Pro): Amazon S3, Hetzner Object Storage, Backblaze B2, MinIO, Cloudflare R2, Wasabi und andere, mit Vorlagen für Endpunkt und Region. Auf entfernte Ziele kommen nur verschlüsselte Sätze.
• SFTP (Pro): mit Passwort oder privatem Schlüssel (verschlüsselt gespeichert). Der Host-Schlüssel des Servers wird beim ersten erfolgreichen Verbindungstest gemerkt und danach bei jeder Verbindung geprüft.
• SMB (Pro, ab Containly 2.5.0): Server, Port (Standard 445), Freigabe, optional Domäne und Unterordner, Benutzername und Passwort (verschlüsselt gespeichert). Es gilt nur SMB3 mit verschlüsselter Sitzung; ein Server, der nicht verschlüsseln kann, wird abgelehnt. Nimm eine eigene Freigabe nur für Backups. Siehe unten SMB-Voraussetzungen.
• NFS (Pro, ab Containly 2.5.0): Server, Export (nicht /), NFSv4 oder NFSv4.1 und ein optionaler Unterordner. Der gewählte Docker-Host bindet den Export über einen kurzlebigen Hilfscontainer ohne zusätzliche Rechte ein.

„Verbindung testen“ prüft das Ziel und zeigt den freien Platz (SMB kann keinen freien Platz melden, deshalb wird keiner angezeigt); „Nach Sicherungen suchen“ findet vorhandene Sätze. Endet deine Pro-Lizenz, bleiben Sätze auf S3, SFTP, SMB und NFS sichtbar, lassen sich prüfen und herunterladen und können auf demselben Host wiederhergestellt werden. Neue Ziele und neue Backups dorthin brauchen Pro.

Jetzt sichern

Jetzt sichern gibt es in der Backup-Übersicht, in der Stack-Liste und im Stack-Inspektor (Tab „Backups“), in der Container-Übersicht und auf der Seite Volumes.

• Standardmässig verschlüsselt: Streaming-Tar, zstd-Kompression und AES-256-GCM mit einem Schlüssel aus deiner Passphrase. Die Passphrase wird nie gespeichert. Unverschlüsselte Backups sind auf lokalen Zielen möglich. Beim Anlegen eines Backup-Schlüssels erzeugt Generieren (seit 2.4.0) eine starke Passphrase, füllt beide Felder aus und kopiert sie mit einem Klick.
• Konsistenz: live, die Container während des Backups stoppen (danach werden sie wieder gestartet), Pre- und Post-Hooks oder Datenbank-Dump.
• Datenbank-Dumps (kostenlos, seit 2.3.0): PostgreSQL, MariaDB und MySQL, MongoDB und Redis. Containly erkennt die Datenbanken eines Stacks am Image und wählt sie vor. Der Dump läuft im laufenden Container, ohne ihn zu stoppen. Zugangsdaten liest Containly zur Laufzeit aus dem Container und speichert sie nie. Beim Wiederherstellen wird der Dump geladen, sobald die Container wieder laufen.
• Anonyme Volumes (ab Containly 2.5.0): Container- und Stack-Backups enthalten standardmässig auch anonyme Docker-Volumes (die mit zufälligem Namen, die Docker für eine VOLUME-Zeile in einem Image anlegt). Du kannst das pro Plan oder pro Backup abschalten. Containly erkennt sie am Containernamen und am Mount-Pfad, nicht am zufälligen Namen. Eine Wiederherstellung landet deshalb im Volume, das heute an diesem Pfad eingebunden ist. Datenbank-Dumps funktionieren auch damit. Ältere Backups bleiben lesbar.
• Läufe zeigen Phasen, Fortschritt und ein Protokoll live. Einen Satz kannst du prüfen, anheften und löschen.

Wiederherstellen

Eine Wiederherstellung beginnt immer mit einer Vorschau auf dem Server: was passiert, Konflikte, riskante Einstellungen und Speicherplatz.

• Als Kopie: neben dem Original, mit neuen Namen. Nichts wird überschrieben.
• Ersetzen: überschreibt die aktuellen Daten. Du tippst zur Bestätigung den Namen; vorher wird eine Sicherheitskopie angelegt und 7 Tage angeheftet.

Wiederherstellen auf demselben Host ist kostenlos.

Anonyme Volumes

Eine Wiederherstellung legt die Daten in das Volume, das jetzt am gleichen Pfad im Container eingebunden ist. Gibt es den Container nicht mehr, legt Containly ein benanntes lokales Volume an. Für die Wiederherstellung eines Stacks mit anonymen Volumes müssen die Konfiguration und alle Volumes des Stacks ausgewählt sein; Containly schreibt dann eine Compose-Override-Datei (.containly-restore-volumes.json), damit die Zuordnung bleibt. Startest du den Stack von Hand mit docker compose, hänge hinter deine Compose-Datei -f .containly-restore-volumes.json an. Kann Containly nicht eindeutig sagen, welches Volume gemeint ist (zum Beispiel bei mehreren Replikaten), oder wäre eine Teilauswahl unsicher, blockiert die Vorschau die Wiederherstellung und nennt den Grund.

Wiederherstellen auf einem anderen Host (Pro, ab Containly 2.5.0)

Ein Container, ein Volume oder ein Compose-Stack lässt sich auf einen anderen Docker-Host wiederherstellen, den Containly verwaltet, als Kopie oder durch Ersetzen des Vorhandenen.

• Im Wiederherstellungs-Assistenten wählst du den Zielhost und einen Namen. Bei einem Stack wählst du zusätzlich einen der Stack-Ordner, die für den Zielhost eingerichtet sind; der Stack landet in <Stack-Ordner>/<Name>, mit neuem Projektnamen und neuen Volume-Namen.
• Die Vorschau prüft alles auf dem Zielhost. Ein Stack wird abgelehnt, wenn seine Compose-Datei privilegiert ist, Host-Namespaces, Geräte oder gefährliche Capabilities nutzt, volumes_from verwendet, externe Volumes braucht oder Ordner ausserhalb des Stack-Ordners auf dem Zielhost anspricht (zum Beispiel ein Bind-Mount eines Pfads auf dem alten Host). Containly migriert nicht beliebige Bind-Mounts: Nur Daten innerhalb des Stack-Ordners reisen mit.
• Wer auf dem Zielhost etwas Vorhandenes ersetzt, bekommt zuerst eine Sicherheitskopie auf diesem Zielhost und tippt wie bisher den Namen zur Bestätigung. Eine Kopie überschreibt nie etwas.
• Der Quellhost wird nie verändert.
• Auch Datenbank-Dumps werden auf dem Zielhost geladen. Ein Stack, der mit einem Dump statt dem rohen Datenbank-Volume gesichert wurde, bekommt ein leeres Volume, das der Dump füllt, sobald die Datenbank bereit ist.

Ohne Pro lehnt Containly das Wiederherstellen auf einem anderen Host ab und weist darauf hin, dass dafür eine Pro-Lizenz nötig ist.

Pläne und Aufbewahrung

Ein Plan bündelt Inhalt, Ziel, Schlüssel, Kompression und Aufbewahrung. Du startest ihn mit Jetzt ausführen oder gibst ihm einen Zeitplan (Pro): stündlich, an gewählten Wochentagen oder monatlich zu einer festen Uhrzeit. Ein verpasster Lauf wird am selben Tag nachgeholt. Ohne aktive Pro-Lizenz pausieren geplante Pläne und laufen weiter, sobald Pro wieder aktiv ist; die Einstellungen bleiben erhalten. Auf Wunsch liest ein Plan alle N Tage seinen neusten Satz vollständig zurück und prüft ihn (Pro). Die Aufbewahrung behält die gewählte Zahl letzter, täglicher, wöchentlicher, monatlicher und jährlicher Sicherungen; ältere Sicherungen des Plans werden nach jedem Lauf gelöscht, die neuste und angeheftete bleiben immer.

Benachrichtigungen: backup.failed (an), backup.succeeded (aus) und backup.stale (warnt, wenn ein geplanter Plan seit der eingestellten Zahl Tage, Standard 3, keine erfolgreiche Sicherung hat), per E-Mail und in der App. Viewer können alles ansehen, aber nichts ändern.

Herunterladen und importieren

Einen vollständigen Satz kannst du als einzelne .clbk-Datei herunterladen (die Verschlüsselung bleibt erhalten) und in einer anderen Containly-Instanz auf eines ihrer Ziele importieren. Jede Datei wird dabei gegen das Manifest geprüft. Kostenlos.

SMB-Voraussetzungen

Das SMB-Ziel ist bewusst streng, weil Containly mit einem Passwort auf einen Server in deinem Netz zugreift.

• Der Server muss SMB3 mit Verschlüsselung anbieten. Ältere Protokollversionen ohne Verschlüsselung werden nicht verwendet.
• Der Containly-Container startet smbclient in einer Sandbox (Landlock), die nur die eine Verbindung zur geprüften Serveradresse erlaubt. Das braucht auf dem Rechner, auf dem Containly läuft, Linux-Kernel 6.7 oder neuer und das Standard-Seccomp-Profil von Docker (es erlaubt die nötigen Systemaufrufe). Fehlt eines davon, zeigt „Verbindung testen“ eine klare Fehlermeldung und SMB bleibt aus. Es gibt keinen Ersatzweg ohne Sandbox. Andere Ziele, auch NFS, sind davon nicht betroffen.
• Zur Laufzeit getestet: Linux mit Docker Engine. Für arm64 lässt sich der Helfer übersetzen, er wurde aber nicht auf echter arm64-Hardware ausgeführt, und Docker Desktop wurde nicht getestet. Behandle beides als nicht geprüft.
• Nimm eine eigene Freigabe und schalte auf dem Server symbolische Links und Wide Links aus.

Ein Backup ohne Containly lesen

Jeder Satz hat eine unverschlüsselte manifest.json und lässt sich mit dem Wiederherstellungs-Tool scripts/clbk-decrypt.mjs lesen (im Image unter /app/scripts). Das Format ist in docs/backup-format.md im Containly-Repository beschrieben.

docker run --rm -i -e CLBK_PASSPHRASE -v "$PWD:/w" amslertec/containly \
  node /app/scripts/clbk-decrypt.mjs /w/<set-dir> --verify

Nicht dasselbe: die Containly-Konfiguration

Einstellungen, Containly-Konfiguration sichert die Konfiguration von Containly selbst (mit Passphrase verschlüsselt, auch nach Zeitplan). Volumes, Stacks und Container sicherst du auf der Seite Backups.