De planning die nodig was om in een persistente Docker-status te leven
De auteur wilde wekelijks kopieën van AppData maken naar een RAID 1-pool en een tweede kopie van die pool naar een continu aangesloten USB-schijf. De crontab van het systeem en een community-app voor planning behielden taken niet betrouwbaar na een herstart, dus verplaatste de auteur de planning naar een door Portainer beheerde Ofelia-stack die werd opgeslagen onder persistente ZimaOS-gegevens.
Het uiteindelijke ontwerp scheidde drie lagen: shellscripts op de RAID-opslag, een Ofelia-container die de planning verzorgde en kortstondige rsync-containers die elke kopie uitvoerden.
Scripts en logboeken opslaan op persistente opslag
In het voorbeeld werden scripts opgeslagen onder een pad zoals /media/RAID1/scripts. Die map werd met lees- en schrijfrechten in de scheduler gemount als /scripts. Logboeken werden naast de scripts geschreven, zodat ze na afloop van de taak via Bestanden of een netwerkshare konden worden bekeken.
Elk pad in het voorbeeld is specifiek voor de installatie. Als je de RAID-naam van de auteur kopieert zonder het daadwerkelijke mountpad te controleren, kan een back-up naar de verkeerde locatie worden gestuurd of kan de taak stilletjes mislukken.
Ofelia leverde een planning die herstarts overleeft
De Portainer-stack gebruikte de Ofelia-image, stelde restart: always in, mountte de scriptmap en bewaarde de planningslabels bij de container. In het voorbeeld werd AppData elke zondag om 23:30 gepland en de algemene NAS-gegevens om 23:45.
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"De auteur meldde dat de scheduler en de bijbehorende taken binnen ongeveer een minuut na een herstart weer beschikbaar waren, zonder dat een nieuwe SSH-sessie nodig was.
Het AppData-script stopte Plex vóór het kopiëren
Om de kans te verkleinen dat een actief gewijzigde Plex-database werd gekopieerd, stopte het script Plex, voerde het rsync uit vanaf een alleen-lezen gemounte AppData-bron en startte het Plex daarna opnieuw. De scheduler-container installeerde indien nodig een Docker-CLI en beheerde naastliggende containers via de Docker-socket.
Het mounten van /var/run/docker.sock geeft de scheduler uitgebreide controle over de Docker-host. Het uitvoeren ervan als root en met verhoogde rechten vergroot die bevoegdheid nog verder. De thread presenteert dit als de werkende opzet van de auteur, niet als een beveiligingsmodel volgens het principe van minimale rechten.
rsync --delete maakt een exacte spiegel, geen versiegeschiedenis
In het voorbeeld werd rsync -avH --delete gebruikt. De optie --delete verwijdert doelbestanden die niet langer in de bron bestaan. Dat levert een exacte spiegel op, maar kan ook per ongeluk verwijderde of beschadigde gegevens reproduceren.
Test eerst zonder verwijderen, controleer de bron- en doelmounts en bekijk het logboek voordat je een onbeheerde planning inschakelt. Een spiegel op een altijd aangesloten USB-schijf is bovendien niet hetzelfde als een offline of onveranderlijke back-up.
Persistente planning loste het opnieuw verbinden van USB niet op
De auteur vroeg afzonderlijk om ervoor te zorgen dat een aangesloten USB-schijf na een herstart niet als een nieuwe schijf zou verschijnen. Ofelia bewaart de taakconfiguratie, maar een gewijzigd of niet-beschikbaar mountpad kan het back-updoel nog steeds onbruikbaar maken. Een stabiele identificatie van de opslag en het controleren van mounts vóór rsync blijven afzonderlijke vereisten.
Veelgestelde vragen
Waarom bleef deze planning na een herstart behouden?
De taakdefinities stonden in een voor herstarts ingeschakelde Portainer-stack en de scripts stonden op persistente opslag in plaats van in een vluchtige systeem-crontab.
Maakt dit historische back-upversies aan?
Nee. De gedocumenteerde rsync-opdracht maakt een spiegel en gebruikt --delete. Versiebehoud vereist een ander ontwerp.
Waarom werd Plex gestopt vóór het kopiëren van AppData?
De auteur deed dit om het risico te verkleinen dat de database werd gekopieerd terwijl deze werd gewijzigd.
