Denna tråd från april 2026 började som ett brett inlägg från en ”ny användare som är överväldigad av ZimaOS”, med fokus på säkerhetskopiering och självhostad e-post. E-postproblemet blev så småningom sekundärt: användaren fick Mailcow att fungera tillräckligt bra för sina behov. Den olösta tekniska frågan gällde ZimaOS Backup, där de visade storlekarna var inkonsekventa, den första körningen vanligtvis slutfördes och senare körningar kunde frysa utan fortsatt diskaktivitet.
Källan är särskilt användbar eftersom användaren testade mer än en ZimaBoard 2, flera interna och externa enheter, en Synology-nätverksdestination och senare ZimaOS 1.6.1. Problemet bör därför inte sammanfattas som en enda trasig USB-disk eller en felaktig nätverkssökväg.
Användaren ville ha en enkel katastrofsäkerhetskopia, inte ett arkivformat
Det önskade arbetsflödet var enkelt: starta en 1:1-liknande säkerhetskopiering manuellt, bevara den igenkännliga mappstrukturen, undvika kryptering eller ogenomskinliga paket och kunna återställa snabbt om en hel ZimaBoard 2 skulle gå sönder.
Denna förväntan skiljer sig från versionshanterad säkerhetskopieringsprogramvara som avsiktligt behåller historiska kopior. När kvarhållning av versioner är aktiverad kan destinationsanvändningen legitimt överstiga storleken på det aktuella källdatasetet.
Problemet på e-postserversidan separerades så småningom
Det ursprungliga inlägget beskrev också svårigheter med att ersätta Synology Mail Plus. Zima-Jerry föreslog Stalwart, men användaren behövde specifikt hämtning via POP3. Den 16 april rapporterade användaren att Mailcow fungerade och att de andra applikationerna var tillfredsställande.
Det utfallet är värt att bevara, eftersom det förhindrar att den senare diskussionen om säkerhetskopiering misstolkas som bevis för att Mailcow självt orsakade lagringsproblemet.
Storlekarna på säkerhetskopieringsdestinationen stämde inte med verkligheten
På ett kort motsvarade cirka 800 GB vid källan ungefär 2,7 TB i målkatalogen. På ett annat verkade cirka 105 GB vid källan sakna ungefär 2 GB i målet.
Versionslagring kan förklara viss tillväxt, men inte en frusen andra körning
Zima-Jerry frågade om funktionen ”reserverad version” var aktiverad. Att behålla tidigare versioner kan legitimt göra säkerhetskopieringsmålet större än den aktuella källan.
Användaren återställde dock senare testet med en nyformaterad extern USB-disk och dokumenterade ett annat fel: den första säkerhetskopieringen slutfördes, medan den andra kopierade vissa data och sedan slutade göra framsteg.
Det rena USB-testet återskapade felet vid den andra körningen
Användaren raderade gamla jobb, startade om ZimaBoard 2, formaterade en extern enhet och skapade en ny manuell säkerhetskopiering med versionshantering aktiverad. Den första körningen tog nästan två dagar och kopierade ungefär 1,25 TB utan problem.
Efter att ha kopplat från och återanslutit enheten via Filer kopierade den andra körningen vissa ändringar, varefter förloppsindikatorn frös och USB-aktivitetslampan slocknade. Samma beteende hade förekommit med Synology-målet.
IceWhale eskalerade säkerhetskopieringsbeteendet
Zima-Jerry tackade användaren för den kontrollerade testningen och sade att problemet skulle vidarebefordras till utvecklingsteamet för utredning.
Ett senare svar relaterat till IceWhale skilde mellan två kända problemområden: säkerhetskopiering av allt /media/ZimaOS-HD hade tidigare inkluderat innehåll från Docker-rör/-socketar, och visningen av säkerhetskopieringens förlopp behövde fortfarande förbättras.
Att säkerhetskopiera hela systemenheten är inte samma sak som en återställningsbar systemavbildning
Diskussionen övergick senare till katastrofåterställning. Ett teamsvar förklarade att en blind säkerhetskopiering av hela systemdisken även inkluderar förbrukningsbara Docker-/runtimefiler och inte automatiskt ger ett stödd arbetsflöde för att ”återställa den här mappen så att hela ZimaOS-systemet återställs exakt som tidigare”.
För katastrofplanering bör du skilja mellan användardata, programdata, databaser, konfiguration och utbytbara containeravbildningar.
ZimaOS 1.6.0 ändrade metadata för lagringsåterställning
Ett senare officiellt svar sa att information om hur en lagringsenhet ska monteras från och med ZimaOS 1.6.0 också skrevs till själva lagringsenheten. Avsikten var att göra RAID- eller enkel disklagring lättare att identifiera igen efter problem med systemdisken.
Detta förbättrar återställningen av en array, men gör inte RAID till en säkerhetskopia och åtgärdar inte i sig källanvändarens hängning vid den andra säkerhetskopieringskörningen.
Användaren återskapade fortfarande problemet i ZimaOS 1.6.1
Den 27 april rapporterade originalskribenten att den första säkerhetskopieringen fortfarande fungerade, men att den andra och senare körningar hängde sig i mer än sex timmar utan ytterligare skrivaktivitet. När Backup stängdes och öppnades igen kunde destinationen visas som 0 B.
De sa att mönstret hade testats med fyra interna enheter, två externa USB-enheter och tre ZimaBoard 2-system.
Det aktuella arbetsflödet för säkerhetskopiering har utvecklats
Den aktuella ZimaOS-dokumentationen beskriver nu schemalagda säkerhetskopieringsuppgifter till lokala destinationer, USB, NAS och moln som en del av en 3-2-1-strategi.
Använd det aktuella arbetsflödet för ZimaOS-säkerhetskopiering och destinationsalternativen i stället för att anta att gränssnittet i 1.5.x/1.6.1 fungerar identiskt i dag.
Den aktuella guiden bevisar inte i sig att alla historiska buggar vid andra körningen i den här tråden har åtgärdats, så verifiera att faktisk återställning fungerar i den version du kör.
Verifiera säkerhetskopieringen utanför förloppsindikatorn
- jämför antalet filer i källa och destination där det är praktiskt möjligt;
- kontrollera den faktiska kapaciteten på destinationen i stället för att bara förlita dig på säkerhetskopieringsgränssnittet;
- testa en andra och tredje inkrementell versionskörning;
- återställ representativa filer till en annan plats;
- dokumentera vilka programdatabaser och inställningar som måste säkerhetskopieras separat.
Vanliga frågor om ZimaOS Backup
Uppstod källproblemet endast med en Synology NAS?
Nej. Användaren återskapade liknande frysningar med en extern USB-enhet.
Misslyckades den första säkerhetskopieringen?
Den kontrollerade första körningen slutfördes; det återkommande problemet uppstod vid senare körningar.
Var problemet borta i ZimaOS 1.6.1?
Nej. Originalskribenten sa uttryckligen att problemet fortfarande uppstod där.
Kan en säkerhetskopieringsdestination legitimt vara större än den aktuella källan?
Ja, när versionsbevaring är aktiverad, men det förklarar inte alla visnings- eller hängningssymtom för jobb i tråden.
