Het architecturale doel is verstandig: gebruik RAID 0-ssd's alleen voor de werklast die daadwerkelijk maximale doorvoer nodig heeft, bescherm deze werkpool met onafhankelijke HDD-back-ups en bewaar minstens één kopie op een andere locatie. RAID 0 biedt geen redundantie, dus één defecte SSD kan de volledige werkarray offline halen.
Het communityantwoord uit 2025 adviseerde zelfstandige roterende HDD's plus nachtelijke rsync, maar de oorspronkelijke poster stelde een belangrijk bezwaar: ZimaOS had al een automatische modus in Back-up, en wilde weten of het terugplaatsen van een oudere HDD in hetzelfde station automatisch zou worden herkend. De discussie eindigde voordat die vragen werden beantwoord. De huidige documentatie van IceWhale biedt inmiddels een duidelijker ondersteunde basis: de Back-up-app ondersteunt geplande taken, meerdere onafhankelijke bestemmingen, hervatten en fouttolerantie, en herstelpunten met versies. De huidige openbare documentatie beschrijft echter geen gegarandeerde workflow waarbij elke oude HDD in hetzelfde station automatisch op basis van identiteit wordt herkend en ermee wordt gesynchroniseerd.
RAID 0 heeft een echt back-upplan nodig
RAID 0 combineert SSD's voor capaciteit en prestaties, zonder pariteit of mirroring. Het defect raken van één schijf kan de array vernietigen. Voor professioneel werk moet de back-up als onderdeel van het ontwerp worden beschouwd, niet als iets dat later wordt toegevoegd.
Zelfstandige back-up-HDD's zijn geschikter voor rotatie dan RAID 1
De community adviseerde om elke HDD van 26 TB onafhankelijk te houden in plaats van twee ervan in RAID 1 te koppelen. Zo is elke schijf een volledige, verwijderbare kopie die extern kan worden opgeslagen en hoeft er niet telkens een mirror opnieuw te worden opgebouwd wanneer een schijf wordt gewisseld.
Dit is een aanbeveling uit de community en geen vereiste van IceWhale. RAID 1 kan de beschikbaarheid verbeteren zolang beide HDD's geïnstalleerd blijven, maar is onhandig als mechanisme voor fysieke rotatie en opslag op een andere locatie.
De huidige back-upfunctie van ZimaOS ondersteunt de essentiële 3-2-1-werkwijze
De huidige documentatie van IceWhale vermeldt dat één Back-up-app Zima-, USB-, LAN- of cloudbronnen en -bestemmingen kan gebruiken, taken volgens een schema kan uitvoeren, onderbroken overdrachten kan hervatten, versies en herstelpunten kan bewaren en meerdere taken vanaf één bron naar verschillende bestemmingen kan onderhouden.
Gebruik het huidige back-upmodel van ZimaOS.
Ga niet uit van het label uit 2025 dat “Automatisch” betekent: direct bij elke wijziging
De oorspronkelijke poster citeerde een tekst in de interface waarin stond dat Zima- en USB-bronnen direct konden worden uitgevoerd wanneer bestanden veranderden. Een andere officiële communitydiscussie uit dezelfde periode beschreef de automatische back-upfunctie van ZimaOS als iets dat op specifieke tijdstippen wordt uitgevoerd, meestal vroeg in de ochtend. De bron zelf bracht deze beschrijvingen nooit met elkaar in overeenstemming.
De huidige openbare documentatie beschrijft geplande back-ups en belooft geen replicatie op basis van bestandssysteemgebeurtenissen na elke wijziging. Gebruik voor productieplanning het huidige gedocumenteerde schema in plaats van te vertrouwen op een oude tekst in de interface.
rsync is een tool voor mirrors en overdrachten, niet automatisch voor back-ups met versies
Het communityscript gebruikte:
rsync -avh --delete ...De optie --delete zorgt ervoor dat de bestemming verwijderingen op de RAID 0-bron weerspiegelt. Dat kan nuttig zijn voor een mirror, maar kan er ook voor zorgen dat per ongeluk verwijderde bestanden naar de back-upschijf worden doorgegeven.
Als rsync wordt gebruikt, begin dan zonder destructieve opties, gebruik --dry-run, controleer het doelpad en ontwerp afzonderlijke snapshots of versiebeheer als herstel na verwijderingen belangrijk is.
Voor schijfrotatie zijn een stabiele identiteit en expliciete verificatie nodig
Het verwisselen van schijven in één fysiek station garandeert niet dat elke geplaatste schijf altijd dezelfde naam of hetzelfde mountpad krijgt. Een robuust rotatieproces moet de schijf identificeren aan de hand van een stabiele apparaat- of opslagidentiteit, bevestigen dat het verwachte doel is aangekoppeld en vervolgens de back-up starten.
Voer geen destructieve mirror-taak uit alleen omdat er “iets” op het oude doelpad is aangekoppeld.
Roteer externe kopieën voor kritieke gegevens vaker dan eens per enkele maanden
Een rotatie van drie of vier maanden laat een groot herstelpuntgat achter als de werkpool op locatie en de lokale back-up samen verloren gaan. Het juiste interval hangt af van de veranderingssnelheid en de bedrijfstolerantie, maar belangrijke professionele gegevens rechtvaardigen doorgaans een frequentere rotatie naar een externe locatie.
Test het herstel voordat je op de rotatie vertrouwt
Herstel voor elke back-up-HDD een representatief project of bestand, controleer de checksums of leesbaarheid in de toepassing en noteer de datum van de laatste geslaagde back-up voordat je de schijf naar een andere locatie brengt.
Veelgestelde vragen over RAID 0-back-ups
Is RAID 1 op de back-up-HDD's hetzelfde als roterende, onafhankelijke back-ups?
Nee. RAID 1 verbetert de beschikbaarheid zolang beide schijven deel uitmaken van de mirror; onafhankelijke schijven zijn gemakkelijker te verwijderen en extern op te slaan als afzonderlijke kopieën.
Belooft de huidige documentatie van ZimaOS echte realtime-replicatie na elke wijziging?
De huidige openbare documentatie over Back-up beschrijft geplande taken, hervatten en fouttolerantie en versies, maar geen gegarandeerde mirror op basis van bestandssysteemgebeurtenissen.
Is rsync --delete automatisch veiliger dan ZimaOS Back-up?
Nee. Het spiegelt verwijderingen bewust en vereist een zorgvuldige controle van het doel, plus afzonderlijk versiebeheer als je herstel na fouten wilt ondersteunen.
