Återställ ett ZimaOS RAID 1 efter ominstallation av systemet

Om ZimaOS installeras om och en befintlig RAID 1 visas som oanvända diskar ska du inte omedelbart klicka på Skapa RAID. Om arrayen återskapas eller formateras kan det förstöra data som fortfarande finns på medlemsdiskarna.

Den första återställningsvägen bör vara den aktuella officiella ZimaOS-metoden: återställ den sparade local-storage.db filen från den tidigare systeminstallationen. Community-handledningen bakom denna sida beskriver en mer ingripande reservmetod för det svårare fallet där databasen inte säkerhetskopierades. Reservmetoden testades på ZimaOS 1.6.1, men den innehåller destruktiva RAID-åtgärder och bör endast övervägas efter att källdatan har kopierats och verifierats oberoende.

Förstahandsval: Återställ local-storage.db

ZimaOS lagrar information om lagringskonfigurationen i:

/ZimaOS-HD/.casaos/db/local-storage.db

Den aktuella officiella återställningsguiden rekommenderar att du laddar ner denna fil innan du installerar om systemet och sedan placerar tillbaka den i samma katalog efter den nya ZimaOS-installationen och omstarten.

Officiell RAID-återställning i ZimaOS efter ominstallation

Om du fortfarande har åtkomst till den gamla systemdisken kan du försöka återställa denna databas innan du rör RAID-medlemsdiskarna.

Varför dataarrayen fortfarande kan vara intakt

ZimaOS använder Linux-programvaru-RAID. Medlemsdiskarna kan behålla RAID-metadata även när den nya ZimaOS-installationen inte längre har den gamla lagringsdatabasen. Därför kan diskarna visas som fysiskt anslutna medan gränssnittet inte längre känner igen den ursprungliga poolen.

ZimaOS 1.6 introducerade även förbättrad återställning av RAID-metadata och återidentifiering, så ett problem som ursprungligen uppstod på ett system bör inte antas uppstå på exakt samma sätt i varje nyare version.

Skapa inte en ny RAID innan återställningen är avgjord

Om diskarna innehåller data som du behöver ska du undvika:

• formatera någon av medlemsdiskarna;
• skapa en ny RAID över samma diskar;
• köra wipefs eller mdadm --zero-superblock för tidigt;
• att gissa vilken /dev/sdX vilken enhet det är.

Innan något återställningsarbete påbörjas ska diskarna identifieras efter modell, serienummer och kapacitet, i stället för att enbart förlita sig på enhetsbokstäver.

Verifiera RAID-metadata skrivskyddat

Community-författaren använde först skrivskyddad inspektion för att bekräfta att båda RAID 1-medlemmarna fortfarande tillhörde samma array.

lsblk -o NAME,SIZE,TYPE,MOUNTPOINT,FSTYPE,MODEL,SERIAL

mdadm --examine /dev/sda
mdadm --examine /dev/sdb

För en frisk RAID 1 ska båda medlemmarna rapportera samma array-UUID och kompatibla RAID-metadata. Om en medlem saknas, är degraderad eller rapporterar andra metadata, stoppa och be om återställningshjälp i stället för att följa en generell återskapandeinstruktion.

Montera den gamla arrayen skrivskyddad

Vid avancerad återställning minskar en skrivskyddad montering risken för att källan ändras medan du verifierar att filerna är tillgängliga:

mdadm --assemble --readonly /dev/md127 /dev/sda /dev/sdb

mkdir -p /DATA/oldraid
mount -o ro /dev/md127 /DATA/oldraid

Kontrollera sedan filsystemet:

df -h /DATA/oldraid
ls -la /DATA/oldraid
du -sh /DATA/oldraid/*

Enhetsnamnen ovan är endast exempel. Klistra aldrig in dem oförändrade om du inte har bekräftat att de motsvarar din hårdvara.

Skapa en fullständig avlastningskopia innan du utför något destruktivt

Källarbetsflödet använde en extern ext4-enhet som var tillräckligt stor för alla använda RAID-data. För Linux-programdata är ext4 användbart eftersom det kan bevara normalt ägarskap, behörigheter, länkar, ACL:er och utökade attribut.

En typisk arkivliknande kopiering är:

rsync -aHAX --info=progress2   /DATA/oldraid/   /DATA/offload/

Kör kopieringen i tmux eller en annan terminal som finns kvar om en SSH frånkoppling annars skulle avbryta processen.

Verifiera säkerhetskopian innan du går vidare

Förlita dig inte enbart på en rsync-rad med avslutningsstatus. Jämför antalet filer och kontrollera storleken på de viktigaste katalogerna:

find /DATA/oldraid -xdev -type f | wc -l
find /DATA/offload -xdev -type f | wc -l

du -sh /DATA/oldraid/*
du -sh /DATA/offload/*

För data som inte går att ersätta är en andra, oberoende säkerhetskopia att föredra. RAID är inte i sig en säkerhetskopia.

Sista utvägen: Avlasta, ta bort gammal RAID-metadata och återskapa i gränssnittet

Den ursprungliga författaren från communityn ville att den återställda arrayen skulle återgå till normal hantering via ZimaOS-gränssnittet. Metoden som användes i sista hand var:

1. verifiera den gamla arrayen skrivskyddad;
2. kopiera alla data till en extern enhet;
3. verifiera kopian;
4. stoppa den gamla md-arrayen;
5. ta bort den gamla RAID-metadatan;
6. skapa en ny RAID 1 med ZimaOS lagringsgränssnitt;
7. återställ de kopierade filerna;
8. verifiera de återställda data.

Den här proceduren förstör avsiktligt den gamla RAID-metadatan. När du har utfört steget blir avlastningskopian din återställningskälla. Använd inte den här metoden om kopieringen är ofullständig eller om du är osäker på enheternas identitet.

Det oåterkalleliga kommandot i källarbetsflödet

Den community-baserade proceduren använde:

mdadm --zero-superblock /dev/sda /dev/sdb

Det här är inte ett felsökningskommando. Det tar bort RAID-metadata från de angivna diskarna. En felaktig enhetssökväg kan orsaka omfattande dataförlust.

Därför rekommenderar den här sidan inte att du kör det enbart för att ZimaOS-gränssnittet inte känner igen en RAID. Återställ local-storage.db, kontrollera ZimaOS aktuella återställningsbeteende och kontakta supporten först när arrayen innehåller viktiga data.

Varför återskapa arrayen via ZimaOS-gränssnittet?

Syftet med källarbetsflödet var att avsluta med en lagringspool som hanteras normalt av ZimaOS, snarare än en permanent manuellt monterad md-enhet utanför lagringsgränssnittet.

När den gamla datan har avlastats säkert och diskarna avsiktligt har återställts använder du det aktuella lagringsgränssnittet för att skapa RAID 1 och låter den initiala synkroniseringen slutföras.

Återställ filerna till den nya poolen

När den nya poolen har skapats och monterats återställer du från avlastningsdisken:

rsync -aHAX --info=progress2   /DATA/offload/   /media/Storage/

Ersätt /media/Storage med den faktiska målsökväg som visas på ditt system.

Verifiera den återställda poolen

find /DATA/offload -xdev -type f | wc -l
find /media/Storage -xdev -type f | wc -l
du -sh /media/Storage/*
cat /proc/mdstat

Låt avlastningsdisken vara orörd tills RAID-synkroniseringen är klar och du har verifierat normal åtkomst via ZimaOS Filer-gränssnittet och de program som är beroende av datan.

Säkerhetskopiera local-storage.db före nästa ominstallation

Den enklaste återställningen är den som förbereds i förväg. Spara en aktuell kopia av:

/ZimaOS-HD/.casaos/db/local-storage.db

utanför systemdisken. Den officiella dokumentationen innehåller nu en direkt återställningsprocedur med hjälp av den här filen.

Vilken återställningsväg ska du välja?

Vanliga frågor om RAID-återställning i ZimaOS

Raderar en ominstallation av ZimaOS automatiskt RAID-data?

Nej. Att installera om systemdisken är något annat än att formatera RAID-medlemsdiskarna. Lagringskonfigurationen kan gå förlorad medan RAID-metadata och data finns kvar på medlemsdiskarna.

Bör jag klicka på Skapa RAID om de gamla diskarna visas som oanvända?

Inte förrän du har bekräftat att ingen befintlig data behöver återställas. Att skapa en ny RAID kan vara destruktivt.

Vilken är den säkraste återställningen om jag har säkerhetskopierat local-storage.db?

Använd den aktuella officiella ZimaOS-proceduren för att återställa databasen och starta om.

Är det säkert att nollställa mdadm-superblocket?

Det är avsiktligt destruktivt för RAID-metadata. Använd det endast som en del av en verifierad återställningsplan efter att data har kopierats säkert någon annanstans.