Schemat som behövdes för att leva med ett beständigt Docker-tillstånd
Författaren ville ha veckovisa kopior av AppData till en RAID 1-pool och en andra kopia från den poolen till en ständigt ansluten USB-disk. Systemets crontab och en schemaläggningsapp från communityn behöll inte uppgifterna på ett tillförlitligt sätt efter omstart, så schemaläggningen flyttades till en Portainer-hanterad Ofelia-stack som lagrades under beständiga ZimaOS-data.
Den resulterande designen separerade tre lager: skalskript på RAID-lagringen, en Ofelia-container som tillhandahöll schemat och kortlivade rsync-containrar som utförde varje kopiering.
Lagra skript och loggar på beständig lagring
I exemplet placerades skripten under en sökväg som /media/RAID1/scripts. Den katalogen monterades med läs- och skrivåtkomst i schemaläggaren som /scripts. Loggar skrevs bredvid skripten så att de kunde granskas via Filer eller en nätverksresurs efter att jobbet hade slutförts.
Alla sökvägar i exemplet är installationsspecifika. Om du kopierar författarens RAID-namn utan att kontrollera den faktiska monterings sökvägen kan en säkerhetskopia skickas till fel plats eller så kan jobbet misslyckas tyst.
Ofelia tillhandahöll ett omstartståligt schema
Portainer-stacken använde Ofelia-avbildningen, angav restart: always, monterade skriptkatalogen och lagrade schemaläggningsetiketter tillsammans med containern. I exemplet schemalades AppData till 23:30 varje söndag och de allmänna NAS-data till 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"Författaren uppgav att schemaläggaren och dess jobb återkom inom ungefär en minut efter omstart utan att en ny SSH-session behövdes.
AppData-skriptet stoppade Plex före kopieringen
För att minska risken att kopiera en Plex-databas som ändrades aktivt stoppade skriptet Plex, körde rsync från en skrivskyddad AppData-källmontering och startade sedan om Plex. Schemaläggarcontainern installerade Docker CLI vid behov och styrde syskoncontainrar via Docker-uttaget.
Att montera /var/run/docker.sock ger schemaläggaren omfattande kontroll över Docker-värden. Att köra den som root och med privilegier ökar den behörigheten ytterligare. Tråden presenterar detta som författarens fungerande design, inte som en säkerhetsmodell med minsta möjliga behörighet.
rsync --delete skapar en exakt spegel, inte versionshistorik
I exemplet användes rsync -avH --delete. Alternativet --delete tar bort filer på målet som inte längre finns i källan. Det skapar en exakt spegel men kan också återspegla oavsiktlig radering eller korruption.
Testa först utan radering, bekräfta källans och målets monteringar och granska loggen innan du aktiverar ett obevakat schema. En spegel på en alltid ansluten USB-disk är inte heller likvärdig med en offline- eller oföränderlig säkerhetskopia.
Omstartstålighet löste inte återanslutning av USB
Författaren bad separat om att en ansluten USB-disk skulle sluta visas som en ny disk efter omstart. Ofelia bevarar jobbkonfigurationen, men en ändrad eller otillgänglig monteringssökväg kan fortfarande göra att säkerhetskopieringsmålet slutar fungera. Stabil identifiering av lagringen och kontroll av monteringar före rsync är fortfarande separata krav.
Vanliga frågor
Varför överlevde schemat omstarten?
Jobbdefinitionerna fanns i en omstartaktiverad Portainer-stack och skripten fanns på beständig lagring i stället för i en temporär system-crontab.
Skapar detta historiska säkerhetskopieringsversioner?
Nej. Det dokumenterade rsync-kommandot skapar en spegel och använder --delete. Versionsbevarande kräver en annan design.
Varför stoppades Plex före kopieringen av AppData?
Författaren gjorde det för att minska risken att kopiera databasen medan den ändrades.
