Den här tråden dokumenterar en verklig produktlucka som senare blev en inbyggd funktion. I ZimaOS 1.4.1 övergick en tvådiskars RAID 1 till ett degraderat, skrivskyddat läge efter att en 750 GB-enhet hade gått sönder. Ersättningsdisken syntes som en separat frisk hårddisk, men lagringsgränssnittet erbjöd ingen tydlig åtgärd för att ”ersätta och bygga om”.
IceWhale hanterade först berörda användare genom teknisk support och CLI-diagnostik. Därefter meddelade Zima-Giorgio att ZimaOS 1.4.4 skulle erbjuda en mer omfattande reparationsprocess för RAID 1. De aktuella officiella versionsanteckningarna för 1.4.4 bekräftar att RAID1-reparation lades till för degraderade eller skadade arrayer.
Käll-RAID-enheten övergick till läget Protecting / skrivskyddad
Ersättningshårddisken identifierades separat
Lagringssidan i 1.4.1 varnade för att nya diskar krävdes
IceWhale uppmanade användare att undvika riskfylld självreparation
Zima-Giorgio erbjöd teknisk hjälp och bad erfarna användare att samla in lsblk och mdadm -D /dev/md0 resultat. Han publicerade inte någon destruktiv återuppbyggnadsinstruktion.
Efter att tekniker privat hade reparerat en senare användares array varnade han uttryckligen för att utföra RAID-operationer på rotnivå utan tillräckliga kunskaper eller direkta instruktioner från tekniker.
ZimaOS 1.4.4 lade till RAID 1-reparation i WebUI
Den 4 september 2025 sa Zima-Giorgio att 1.4.4 skulle erbjuda en mer omfattande reparationsprocess för RAID 1. När en annan användare bad om CLI-hjälp för 1.4.4 svarade Giorgio att 1.4.4 kunde utföra reparationen via WebUI.
Aktuella versionsanteckningar från IceWhale bekräftar: ”Lade till en RAID 1-reparationsfunktion: reparation kan utföras när RAID 1-arrayen är degraderad eller skadad.”
Använd den officiella RAID 1-reparationsfunktionen i ZimaOS 1.4.4 i stället för att återskapa äldre experiment med root/mdadm.
1.4.4 åtgärdade även problem med tidigare använda diskar under återställning
Samma versionsinformation anger att ZimaOS åtgärdade ett problem där tidigare använda diskar inte kunde väljas under RAID-återställning. Det är direkt relevant för arbetsflöden med ersättningsdiskar där en disk redan kan innehålla gamla signaturer eller ha initierats separat.
Använd en ersättningsdisk som är minst lika stor som den felaktiga medlemmen
En RAID 1-återuppbyggnad kräver en ersättningsmedlem som är tillräckligt stor för arrayens befintliga datalayout. Nominellt identiska diskar på ”750 GB” eller ”2 TB” kan skilja sig något i antal sektorer, så en disk med mindre användbar kapacitet kan avvisas.
Säkerhetskopiera läsbara data före en riskfylld återställning när det är möjligt
En degraderad RAID 1 har redan förlorat sin redundans. Om den återstående disken fallerar under återuppbyggnaden kan arrayen gå förlorad. Kopiera oersättliga data till en oberoende disk innan du utför en ingripande återställning, när arrayen går att läsa och data inte redan är säkerhetskopierade.
Klicka inte på Skapa RAID med befintliga medlemsdiskar
Om ZimaOS visar gamla RAID-medlemmar som oanvända eller separata diskar kan skapandet av en ny RAID skriva över metadata. Ta reda på om du reparerar en befintlig degraderad array eller avsiktligt skapar en ny tom array innan du fortsätter.
En RAID 1-återuppbyggnad innebär hög belastning på den överlevande disken
Under en återuppbyggnad måste ZimaOS läsa den överlevande medlemmen omfattande samtidigt som ersättningen skrivs. Om den återstående gamla disken redan är på gränsen till att fallera är detta ett av de tillfällen då oläsbara sektorer eller andra fel sannolikt upptäcks.
Därför bör en extern säkerhetskopia av oersättliga data göras innan återuppbyggnaden, så länge den degraderade arrayen fortfarande går att läsa.
Formatera inte ersättningen bara för att den visas som separat lagring
I källfallet hade användaren redan formaterat den nya disken och ZimaOS visade den som HDD-Storage. Senare korrigeringar i 1.4.4 åtgärdade specifikt att diskar som hade använts tidigare inte var tillgängliga för RAID-återställning.
På ett aktuellt system ska du följa arbetsflödet för RAID-reparation och låta ZimaOS förbereda den valda ersättningsdisken. Om du formaterar eller skapar ett annat lagringsutrymme först kan det tillföra metadata som återställningsgränssnittet sedan måste hantera.
Skrivskyddad diagnostik är säkrare än manuell RAID-mutation
Kommandona som Zima-Giorgio efterfrågade—lsblk och mdadm -D /dev/md0—användes diagnostiska läsningar för att identifiera enheten och arrayens tillstånd. Det skiljer sig mycket från kommandon som lägger till medlemmar, nollställer superblock, tvingar fram montering eller återskapar arrayer.
Om supporten ber om CLI-utdata ska du samla in den begärda skrivskyddade informationen exakt och undvika att improvisera med destruktiva mdadm-åtgärder från orelaterade Linux-guider.
Verifiera arrayen när återskapandet är klart
Betrakta inte återställningen som slutförd så snart ersättningsdisken har godkänts. Vänta tills synkroniseringen/återskapandet är klart, bekräfta att RAID återgår till statusen frisk/skyddad, öppna representativa filer och verifiera de program som är beroende av lagringspoolen.
Låt den externa säkerhetskopian vara orörd tills dessa kontroller har godkänts.
Förbered dig för nästa diskfel medan arrayen är frisk
RAID 1 ger tid att ersätta en trasig medlem, men eliminerar inte behovet av säkerhetskopiering. Behåll en oberoende kopia av viktiga data, anteckna diskarnas modeller och serienummer och kontrollera regelbundet deras hälsa så att ett degraderat tillstånd upptäcks innan en andra medlem går sönder.
Vanliga frågor om återställning av RAID 1
Saknades RAID 1-reparation i ZimaOS 1.4.1-gränssnittet?
Användaren i källan kunde se den degraderade arrayen och ersättningsdisken, men hade ingen vanlig reparationsåtgärd.
Lade IceWhale senare till ett reparationsflöde i WebUI:t?
Ja. IceWhale uppgav att 1.4.4 kunde reparera RAID 1 via WebUI:t, och de officiella versionsanteckningarna listar RAID1-reparation som en ny funktion.
Bör nuvarande användare köra root-kommandon med mdadm från den gamla tråden?
Nej. IceWhale varnade uttryckligen användare för att utföra RAID-åtgärder på root-nivå om de inte förstod riskerna eller hade fått instruktioner från ingenjörer.
