Källanvändaren ville återställa en test-NVMe till ett ohanterat tillstånd efter experiment med ZimaOS 1.5.3. Testdata spelade ingen roll. 777-Spiders officiella svar från communityteamet var att öppna diskdetaljerna, välja Inaktivera, bekräfta dialogrutan Formatera och inaktivera, vänta tills åtgärden slutförts och därefter fysiskt ta bort enheten. Originalförfattaren bekräftade att arbetsflödet fungerade.
Det finns en viktig versionsreservation: en separat rapport om ZimaOS 1.5.4 visade senare att bekräftelsen för Inaktivera kunde ange att disken skulle formateras, medan data faktiskt fanns kvar efter att den aktiverats igen. Därför bör dialogtexten från 2025 inte betraktas som en exakt garanti för vad Inaktivera gör med data i aktuella versioner. Om data är viktig bör du säkerhetskopiera den innan du använder Inaktivera eller Formatera.
Öppna diskdetaljerna i stället för att först gå över till SSH
Användaren övervägde först att manuellt avmontera eller ta bort partitioner via SSH eftersom sidan Lagring verkade sakna ett alternativ för borttagning. Den saknade åtgärden fanns helt enkelt bakom den lilla pilen på diskraden.
Källans arbetsflöde för Inaktivera bekräftades fungera
777-Spider instruerade användaren att:
- öppna måldisken;
- välja Inaktivera;
- bekräfta den till synes destruktiva dialogrutan;
- vänta tills disken tagits bort från den hanterade lagringen;
- därefter fysiskt ta bort den.
Carolus64 svarade att det fungerade som förväntat.
Dialogrutan i 1.5.3 angav uttryckligen Formatera och inaktivera
En senare rapport om 1.5.4 angav att Inaktivera faktiskt inte raderade data
I februari 2026 visade en annan användare att testmappen fanns kvar efter att en testdisk för lagring hade inaktiverats och aktiverats igen. Användaren kallade dialogrutan missvisande och föreslog att Inaktivera skulle separeras från valfri formatering.
Den senare informationen innebär att formuleringen i gränssnittet och det faktiska raderingsbeteendet inte var konsekvent över dessa versioner.
Betrakta Inaktivera och Formatera som potentiellt destruktiva tills motsatsen har verifierats
För aktuella versioner av ZimaOS är den säkraste regeln att:
- säkerhetskopiera data du är rädd om;
- identifiera exakt disk med modell, serienummer och kapacitet;
- bekräfta om den är fristående eller ingår i en array;
- läsa den aktuella bekräftelsedialogrutan;
- inte förlita dig på en gammal tråd som garanti för att data bevaras eller raderas.
Att ta bort en fristående disk är inte samma sak som att ta bort en RAID-medlem
Källans disk var fristående testlagring. Att ta bort en medlem från RAID 1/5/6 eller en annan poolad layout har helt andra konsekvenser för redundans och återuppbyggnad.
Använd inte denna sekvens för Inaktivera som en generell procedur för att ”krympa min RAID”.
Flytta AppData innan du inaktiverar en disk som innehåller program
Källanvändaren hade installerat och sedan tagit bort en WebDAV-app. På ett verkligt system kan måldisken fortfarande innehålla AppData, databaser, Docker-volymer, säkerhetskopieringsmål eller anpassade bind-monteringar.
Använd det aktuella arbetsflödet för datamigrering i ZimaOS innan du kopplar från lagring som innehåller hanterade programdata.
Källan hittade också ett problem med hur Firefox återgav popup-fönster
Om en aktuell bekräftelsedialogruta ser tom eller avklippt ut kan du prova den aktuella stabila versionen av ZimaOS och en annan webbläsare innan du utför lagringsåtgärder utan att kunna se dem ordentligt.
Vanliga frågor om borttagning av diskar
Lyckades källanvändaren ta bort den fristående NVMe-disken genom Inaktivera?
Ja. Användaren bekräftade att det hanterade arbetsflödet i gränssnittet fungerade.
Bevisar den historiska formuleringen ”Formatera och inaktivera” att disken raderas säkert?
Nej. En senare rapport om 1.5.4 visade att data fanns kvar efter Inaktivera, så det aktuella beteendet måste verifieras separat.
Kan samma arbetsflöde användas för att ta bort en RAID-medlem?
Utgå inte från det. Att ta bort en arraymedlem har andra krav på data och redundans.
