Vandaag beginnen met één NVMe en later overstappen op RAID is een redelijk plan voor een homeserver, maar de veilige migratieroute is niet “klik op JBOD naar RAID converteren”. In de brondiscussie van februari 2026 werd een gecontroleerde workflow aanbevolen: back-up maken → nieuwe array creëren → herstellen → verifiëren, in plaats van ervan uit te gaan dat ZimaOS de bestaande opslag met één schijf ter plekke kon transformeren.
De huidige versie van ZimaOS heeft sinds die post betere migratietools. Via Instellingen > Datamigratie kun je nu Docker-images, Docker-applicatiegegevens en ZimaOS-gebruikersdatabases tussen opslagruimtes verplaatsen. Dat maakt de migratie van applicatiestatus eenvoudiger, maar zet een reeds gebruikte schijf met één schijf nog steeds niet om in een redundante RAID 1/5-indeling zonder een afzonderlijke doelarray.
De gebruiker uit de bron begon met één NVMe en een USB-back-upschijf
Het systeem gebruikte de ingebouwde eMMC voor ZimaOS, één NVMe-SSD die als JBOD-opslag was geconfigureerd en een USB-harde schijf voor back-ups. De gebruiker wilde later meer NVMe-opslag toevoegen en alles naar RAID 1 of RAID 5 verplaatsen.
Dit is precies de situatie waarin het belangrijk is om een geverifieerde, onafhankelijke back-up te behouden, omdat het wijzigen van de opslagtopologie kan inhouden dat nieuwe schijven worden geïnitialiseerd en dat de oude indeling met één schijf uiteindelijk wordt gewist.
Ga er niet van uit dat JBOD met één schijf ter plekke kan worden geconverteerd
Het antwoord uit de community stelde dat de opslaginterface van ZimaOS geen ondersteunde workflow bood om JBOD met één schijf naar RAID te converteren. In plaats daarvan werd aanbevolen een nieuwe array te bouwen met ongebruikte schijven.
De huidige openbare documentatie over Opslag ondersteunt nu het toevoegen van schijven aan bepaalde bestaande RAID-indelingen, met name uitbreiding van RAID 5. Dat is echter iets anders dan een niet-redundante opslagruimte met één schijf ter plekke omzetten naar RAID.
Maak een back-up van meer dan alleen de voor de hand liggende gedeelde mappen
Bescherm het volgende voordat je de opslag wijzigt:
- gewone gedeelde bestanden;
- Docker-applicatiegegevens;
- aangepaste mappen die via bind mounts zijn gekoppeld;
- applicatiedatabases;
- Compose/YAML-definities voor aangepaste apps;
- belangrijke configuratie die niet automatisch opnieuw wordt aangemaakt.
Een back-up moet worden geverifieerd door daadwerkelijk representatieve bestanden te openen of een testherstel uit te voeren, niet alleen door te controleren of een taak als voltooid wordt weergegeven.
Maak de nieuwe RAID aan voordat je de oude schijf wist
De veiligste migratiearchitectuur is om de oorspronkelijke NVMe onaangeroerd te laten terwijl de nieuwe RAID op nieuw toegevoegde schijven wordt aangemaakt. Zo blijft de oorspronkelijke opslag een extra herstelbron totdat de nieuwe array is gevalideerd.
De huidige versie van ZimaOS maakt arrays aan via Instellingen > Opslag. Gebruik de huidige installatieprocedure voor ZimaOS-opslag in plaats van oude handmatige mdadm-procedures te herhalen.
Kies RAID 1 of RAID 5 op basis van het aantal schijven en de verwachte groei
RAID 1 is de eenvoudige spiegeling met twee schijven. RAID 5 begint met drie schijven en levert één schijf aan capaciteit in voor bescherming tegen het uitvallen van één schijf.
De huidige documentatie van ZimaOS positioneert RAID 5 als een optie voor bibliotheken die groeien en vermeldt dat er in de loop van de tijd schijven kunnen worden toegevoegd. RAID 5 kan daarom aantrekkelijk zijn als je verwacht dat de opslagpool na de eerste migratie wordt uitgebreid.
Met de huidige datamigratie kun je beheerde ZimaOS-gegevens verplaatsen
Volgens de huidige documentatie van IceWhale kun je via Instellingen > Datamigratie het volgende verplaatsen:
- Docker-images;
- Docker-applicatiegegevens;
- gebruikersdatabases zoals Galerij, Downloads, Documenten, Media en Back-up.
Gebruik de huidige datamigratieprocedure van ZimaOS nadat de doelopslag beschikbaar is.
Aangepaste bind mounts moeten nog steeds handmatig worden gecontroleerd
Ingebouwde migratiecategorieën bieden geen garantie dat elk aangepast hostpad in iedere Compose-stack automatisch wordt aangepast. Controleer toepassingen die ongebruikelijke mappen buiten de standaardlocaties die door ZimaOS worden beheerd koppelen.
Controleer na de migratie de volumekoppeling van elke belangrijke app en bevestig dat de map aan de hostzijde naar de nieuwe opslag verwijst.
Controleer de nieuwe RAID voordat je de oorspronkelijke NVMe een andere bestemming geeft
Bevestig het volgende:
- de RAID wordt als gezond weergegeven;
- belangrijke gedeelde mappen de verwachte bestanden bevatten;
- Docker-apps starten en hun databases intact zijn;
- machtigingen vanaf normale clients correct werken;
- back-uptaken naar de bedoelde bron en bestemming verwijzen.
Pas daarna mag je de oorspronkelijke NVMe wissen of opnieuw gebruiken.
Behoud de USB-back-up nadat je naar RAID bent overgestapt
RAID beschermt de beschikbaarheid na het uitvallen van een schijf in de array. Het beschermt niet tegen per ongeluk verwijderen, ransomware, beschadigde applicaties, diefstal of verlies van de volledige server.
De USB-back-up uit het oorspronkelijke plan blijft ook na de RAID-migratie nuttig en kan deel gaan uitmaken van een bredere 3-2-1-strategie.
Veelgestelde vragen over JBOD naar RAID
Kan de huidige versie van ZimaOS AppData tussen opslagruimtes verplaatsen?
Ja. De huidige datamigratietool bevat Docker-applicatiegegevens en Docker-images.
Betekent dit dat een JBOD-schijf met één schijf ter plekke kan worden omgezet naar RAID 1?
Nee. Gegevens verplaatsen en de opslagtopologie wijzigen zijn afzonderlijke bewerkingen.
Wanneer moet de oorspronkelijke schijf worden gewist?
Pas nadat de nieuwe array, bestanden, applicatiestatus, machtigingen en back-ups zijn gecontroleerd.
