Der Zeitplan für einen persistenten Docker-Zustand
Der Autor wollte wöchentlich Kopien von AppData in einen RAID-1-Pool und eine zweite Kopie von diesem Pool auf eine dauerhaft angeschlossene USB-Festplatte erstellen. Die System-Crontab und eine Community-Zeitplan-App behielten Aufgaben nach einem Neustart nicht zuverlässig bei. Deshalb verlegte er die Zeitplanung in einen über Portainer verwalteten Ofelia-Stack, der unter persistenten ZimaOS-Daten gespeichert wurde.
Das daraus entstandene Design trennte drei Ebenen: Shell-Skripte auf dem RAID-Speicher, einen Ofelia-Container für die Zeitplanung und kurzlebige rsync-Container, die die einzelnen Kopien erstellten.
Skripte und Protokolle auf persistentem Speicher ablegen
Im Beispiel wurden die Skripte unter einem Pfad wie /media/RAID1/scripts abgelegt. Dieses Verzeichnis wurde mit Lese- und Schreibzugriff als /scripts in den Scheduler eingebunden. Die Protokolle wurden neben den Skripten gespeichert, sodass sie nach Abschluss des Jobs über Files oder eine Netzwerkfreigabe eingesehen werden konnten.
Jeder Pfad im Beispiel ist installationsspezifisch. Wenn Sie den RAID-Namen des Autors kopieren, ohne den tatsächlichen Einhängepfad zu prüfen, kann die Sicherung am falschen Ort landen oder der Job unbemerkt fehlschlagen.
Ofelia stellte den neustartfesten Zeitplan bereit
Der Portainer-Stack verwendete das Ofelia-Image, setzte restart: always, band das Skriptverzeichnis ein und speicherte die Zeitplan-Labels beim Container. Im Beispiel wurden AppData für jeden Sonntag um 23:30 Uhr und die allgemeinen NAS-Daten um 23:45 Uhr eingeplant.
ofelia.job-local.appdata.schedule: "0 30 23 * * 0"
ofelia.job-local.appdata.command: "/bin/sh /scripts/backup_appdata.sh"
ofelia.job-local.nas_home.schedule: "0 45 23 * * 0"
ofelia.job-local.nas_home.command: "/bin/sh /scripts/backup_nas_home.sh"Der Autor berichtete, dass der Scheduler und seine Jobs innerhalb von ungefähr einer Minute nach dem Neustart wieder verfügbar waren, ohne dass eine weitere SSH-Sitzung erforderlich war.
Das AppData-Skript beendete Plex vor dem Kopieren
Um das Risiko zu verringern, eine sich gerade ändernde Plex-Datenbank zu kopieren, beendete das Skript Plex, führte rsync von einer schreibgeschützt eingebundenen AppData-Quelle aus und startete Plex anschließend wieder. Der Scheduler-Container installierte bei Bedarf eine Docker-CLI und steuerte über den Docker-Socket benachbarte Container.
Die Einbindung von /var/run/docker.sock verleiht dem Scheduler weitreichende Kontrolle über den Docker-Host. Die Ausführung als Root und mit erweiterten Berechtigungen erhöht diese Zugriffsmacht zusätzlich. Der Beitrag beschreibt dies als funktionierendes Design des Autors, nicht als Sicherheitsmodell mit geringstmöglichen Berechtigungen.
rsync --delete erstellt einen exakten Spiegel, keine versionierte Historie
Im Beispiel wurde rsync -avH --delete verwendet. Die Option --delete entfernt Zieldateien, die an der Quelle nicht mehr vorhanden sind. Dadurch entsteht ein exakter Spiegel, versehentliche Löschungen oder Beschädigungen können jedoch ebenfalls übernommen werden.
Testen Sie zunächst ohne Löschvorgänge, bestätigen Sie die Einbindungen von Quelle und Ziel und prüfen Sie das Protokoll, bevor Sie einen unbeaufsichtigten Zeitplan aktivieren. Ein Spiegel auf einer dauerhaft angeschlossenen USB-Festplatte ist außerdem nicht gleichbedeutend mit einer Offline- oder unveränderlichen Sicherung.
Die Neustartfestigkeit löste die USB-Wiederverbindung nicht
Der Autor bat außerdem darum, dass eine angeschlossene USB-Festplatte nach einem Neustart nicht als neue Festplatte angezeigt wird. Ofelia bewahrt die Job-Konfiguration, doch ein geänderter oder nicht verfügbarer Einhängepfad kann das Sicherungsziel weiterhin unbrauchbar machen. Eine stabile Identifizierung des Speichers und die Überprüfung der Einbindungen vor der Ausführung von rsync bleiben separate Anforderungen.
FAQ
Warum blieb dieser Zeitplan nach einem Neustart erhalten?
Die Job-Definitionen befanden sich in einem für Neustarts konfigurierten Portainer-Stack, und die Skripte lagen auf persistentem Speicher statt in einer flüchtigen System-Crontab.
Erstellt dies historische Sicherungsversionen?
Nein. Der dokumentierte rsync-Befehl erstellt einen Spiegel und verwendet --delete. Für die Aufbewahrung von Versionen ist ein anderes Design erforderlich.
Warum wurde Plex vor dem Kopieren von AppData beendet?
Der Autor tat dies, um das Risiko zu verringern, die Datenbank während einer Änderung zu kopieren.
