Deze thread uit april 2026 begon als een breed bericht van een “nieuwe gebruiker die overweldigd was door ZimaOS” over back-ups en zelfgehoste e-mail. Het e-mailprobleem werd uiteindelijk van secundair belang: de gebruiker kreeg Mailcow goed genoeg werkend voor de eigen behoeften. Het onopgeloste technische verhaal betrof ZimaOS Backup, waarbij de weergegeven grootten niet consistent waren, de eerste uitvoering meestal werd voltooid en latere uitvoeringen konden vastlopen zonder verdere schijfactiviteit.
De bron is bijzonder nuttig omdat de gebruiker meer dan één ZimaBoard 2, meerdere interne en externe schijven, een Synology-netwerkbestemming en later ZimaOS 1.6.1 heeft getest. Het probleem moet daarom niet worden samengevat als één defecte USB-schijf of één onjuist netwerkpad.
De gebruiker wilde een eenvoudige back-up voor noodgevallen, geen archiefformaat
De gewenste werkwijze was eenvoudig: handmatig een back-up in 1-op-1-stijl starten, de herkenbare mappenstructuur behouden, versleuteling of ondoorzichtige pakketten vermijden en snel kunnen herstellen als een volledige ZimaBoard 2 uitviel.
Deze verwachting verschilt van software voor versiebeheer van back-ups, die opzettelijk historische kopieën bewaart. Wanneer versiebehoud is ingeschakeld, kan het gebruik op de bestemming legitiem groter zijn dan de omvang van de huidige brongegevens.
Het probleem aan de mailserverkant werd uiteindelijk losgekoppeld
In het oorspronkelijke bericht werd ook beschreven dat het lastig was om Synology Mail Plus te vervangen. Zima-Jerry stelde Stalwart voor, maar de gebruiker had specifiek POP3-ophaling nodig. Op 16 april meldde de gebruiker dat Mailcow werkte en dat de andere toepassingen naar tevredenheid functioneerden.
Die uitkomst is het vermelden waard, omdat hiermee wordt voorkomen dat de latere bespreking van Back-up verkeerd wordt geïnterpreteerd als bewijs dat Mailcow zelf het opslagprobleem veroorzaakte.
Grootte van back-upbestemming kwam niet overeen met de werkelijkheid
Op het ene bord kwam ongeveer 800 GB aan de bron overeen met ongeveer 2,7 TB in de bestemmingsmap. Op een ander bord leek bij ongeveer 105 GB aan de bron ongeveer 2 GB te ontbreken op de bestemming.
Versiebehoud kan een deel van de groei verklaren, maar niet een vastgelopen tweede run
Zima-Jerry vroeg of de functie “versie reserveren” was ingeschakeld. Het bewaren van vorige versies kan er legitiem voor zorgen dat een back-upbestemming groter is dan de huidige actieve bron.
De brongebruiker voerde de test later echter opnieuw uit met een nieuw geformatteerde externe USB-schijf en documenteerde een andere fout: de eerste back-up werd voltooid, de tweede back-up kopieerde enkele gegevens en maakte daarna geen voortgang meer.
De schone USB-test reproduceerde de fout bij de tweede run
De gebruiker verwijderde oude taken, startte de ZimaBoard 2 opnieuw op, formatteerde een externe schijf en maakte een nieuwe handmatige back-up met ingeschakelde versies. De eerste run duurde bijna twee dagen en kopieerde ongeveer 1,25 TB succesvol.
Nadat de schijf via Bestanden was losgekoppeld en opnieuw verbonden, kopieerde de tweede run enkele wijzigingen, waarna de voortgangsbalk vastliep en het USB-activiteitslampje uitging. Hetzelfde gedrag had zich voorgedaan met de Synology-bestemming.
IceWhale schaalde het back-upgedrag op
Zima-Jerry bedankte de gebruiker voor het gecontroleerd testen en zei dat de kwestie voor onderzoek zou worden doorgegeven aan het ontwikkelingsteam.
Een latere aan IceWhale gerelateerde reactie maakte onderscheid tussen twee bekende probleemgebieden: het back-uppen van alles /media/ZimaOS-HD had eerder Docker-pipe-/socketinhoud opgenomen, en de nauwkeurigheid van de weergave van de back-upvoortgang moest nog worden verbeterd.
Een back-up van de volledige systeemschijf is niet hetzelfde als een herstelbare systeemimage
De discussie ging later over noodherstel. Een teamreactie legde uit dat het blind back-uppen van de volledige systeemschijf ook wegwerpbare Docker-/runtimebestanden omvat en niet automatisch een ondersteunde workflow biedt waarmee je “deze map terugzet en het volledige ZimaOS-systeem precies terugkeert naar de vorige staat”.
Maak voor rampenplanning onderscheid tussen gebruikersgegevens, applicatiegegevens, databases, configuratie en vervangbare containerimages.
ZimaOS 1.6.0 wijzigde metagegevens voor opslagherstel
Een later officieel antwoord zei dat vanaf ZimaOS 1.6.0 ook informatie waarin wordt beschreven hoe een opslagapparaat moet worden aangekoppeld, naar de opslag zelf werd geschreven. Het doel was om RAID- of opslag met één schijf na een probleem met de systeemschijf gemakkelijker opnieuw te herkennen.
Dit verbetert het herstel van arrays, maar maakt van RAID geen back-up en lost op zichzelf de vastloper van de brongebruiker bij de tweede back-uprun niet op.
De gebruiker reproduceerde het probleem nog steeds op ZimaOS 1.6.1
Op 27 april meldde de oorspronkelijke poster dat de eerste back-up nog steeds werkte, maar dat de tweede en latere uitvoeringen meer dan zes uur vastliepen zonder verdere schrijfactiviteit. Na het sluiten en opnieuw openen van Back-up kon de bestemming als 0 B worden weergegeven.
Ze zeiden dat het patroon was getest met vier interne schijven, twee externe USB-schijven en drie ZimaBoard 2-systemen.
De huidige back-upworkflow is geëvolueerd
De huidige ZimaOS-documentatie beschrijft nu geplande back-uptaken naar lokale, USB-, NAS- en cloudbestemmingen als onderdeel van een 3-2-1-strategie.
Gebruik de huidige ZimaOS-back-upworkflow en bestemmingsopties in plaats van aan te nemen dat de interface van 1.5.x/1.6.1 tegenwoordig identiek werkt.
De huidige handleiding bewijst op zichzelf niet dat elke historische bug bij de tweede uitvoering in deze thread is opgelost. Controleer daarom het daadwerkelijke herstelgedrag op de versie die je gebruikt.
Controleer de back-up buiten de voortgangsbalk om
- vergelijk waar praktisch mogelijk de aantallen bestanden op de bron en bestemming;
- controleer de werkelijke capaciteit van de bestemming in plaats van alleen de Back-upinterface;
- test een tweede en derde incrementele uitvoering met versiebeheer;
- zet representatieve bestanden terug naar een andere locatie;
- documenteer welke applicatiedatabases en instellingen afzonderlijk moeten worden geback-upt.
Veelgestelde vragen over ZimaOS-back-ups
Trad het bronprobleem alleen op met een Synology NAS?
Nee. De gebruiker reproduceerde vergelijkbare vastlopers met een externe USB-schijf.
Mislukte de eerste back-up?
De gecontroleerde eerste uitvoering werd voltooid; het terugkerende probleem trad op bij latere uitvoeringen.
Was het probleem opgelost in ZimaOS 1.6.1?
Nee. De oorspronkelijke poster zei uitdrukkelijk dat het probleem daar nog steeds optrad.
Kan een back-upbestemming legitiem groter zijn dan de huidige bron?
Ja, wanneer versiebehoud is ingeschakeld, maar dat verklaart niet elk weergave- of vastgelopen-taaksymptoom in de thread.
