Een ZimaOS RAID 1 herstellen na het opnieuw installeren van het systeem

Als ZimaOS opnieuw wordt geïnstalleerd en een bestaande RAID 1 als ongebruikte schijven verschijnt, klik dan niet meteen op RAID aanmaken. Het opnieuw aanmaken of formatteren van de array kan de gegevens vernietigen die nog op de schijven aanwezig zijn.

De eerste herstelroute moet de huidige officiële methode van ZimaOS zijn: het opgeslagen local-storage.db bestand uit de vorige systeeminstallatie. De communityhandleiding achter deze pagina beschrijft een ingrijpender alternatief voor het lastigere geval waarin geen back-up van die database is gemaakt. Dit alternatief is getest op ZimaOS 1.6.1, maar bevat destructieve RAID-bewerkingen en mag alleen worden overwogen nadat de brongegevens onafhankelijk zijn gekopieerd en gecontroleerd.

Eerste keuze: local-storage.db herstellen

ZimaOS bewaart informatie over de opslagconfiguratie in:

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

De huidige officiële herstelhandleiding raadt aan dit bestand vóór het opnieuw installeren van het systeem te downloaden en het na de nieuwe ZimaOS-installatie en het opnieuw opstarten terug te plaatsen in dezelfde map.

Officieel RAID-herstel in ZimaOS na herinstallatie

Als je nog toegang hebt tot de oude systeemschijf, probeer dan deze database te herstellen voordat je de RAID-ledenschijven aanraakt.

Waarom de data-array mogelijk nog intact is

ZimaOS gebruikt software-RAID van Linux. De schijven kunnen RAID-metadata behouden, zelfs wanneer de nieuwe ZimaOS-installatie de oude opslagdatabase niet meer heeft. Daarom kunnen schijven fysiek aanwezig lijken terwijl de oorspronkelijke pool niet meer door de gebruikersinterface wordt herkend.

ZimaOS 1.6 introduceerde ook verbeterd herstel van RAID-metadata en verbeterde heridentificatie, dus je mag niet aannemen dat een probleem dat oorspronkelijk op één systeem werd gezien, zich op elke nieuwere release identiek voordoet.

Maak geen nieuwe RAID aan voordat het herstelbesluit is genomen

Als de schijven gegevens bevatten die je nodig hebt, vermijd dan:

• een van beide schijven formatteren;
• een nieuwe RAID aanmaken op dezelfde schijven;
• uitvoeren wipefs of mdadm --zero-superblock voortijdig;
• raden welk apparaat /dev/sdX welk apparaat is.

Identificeer schijven vóór herstelwerkzaamheden aan de hand van model, serienummer en capaciteit, en vertrouw niet alleen op apparaatletters.

RAID-metadata alleen-lezen verifiëren

De community-auteur gebruikte eerst alleen-lezen inspectie om te bevestigen dat beide RAID 1-leden nog steeds bij dezelfde array hoorden.

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

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

Voor een gezonde RAID 1 moeten beide leden dezelfde array-UUID en compatibele RAID-metadata rapporteren. Als één lid ontbreekt, gedegradeerd is of andere metadata rapporteert, stop dan en vraag hulp bij gegevensherstel in plaats van een generieke herbouwprocedure te volgen.

Assembleer en mount de oude array als alleen-lezen

Voor geavanceerd herstel verkleint alleen-lezen assembleren de kans dat de bron wordt gewijzigd terwijl je controleert of de bestanden toegankelijk zijn:

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

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

Inspecteer vervolgens het bestandssysteem:

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

De bovenstaande apparaatnamen zijn slechts voorbeelden. Plak ze nooit ongewijzigd tenzij je hebt bevestigd dat ze overeenkomen met je hardware.

Maak een volledige offloadkopie voordat je een destructieve stap uitvoert

De bronworkflow gebruikte een externe ext4-schijf die groot genoeg was voor alle gebruikte RAID-gegevens. Voor Linux-toepassingsgegevens is ext4 nuttig omdat het normaal eigenaarschap, rechten, koppelingen, ACL's en uitgebreide kenmerken kan behouden.

Een gebruikelijke kopie in archiefstijl is:

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

Voer de kopie uit in tmux of een andere permanente terminal, als een verbroken SSH-verbinding de bewerking anders zou onderbreken.

Controleer de back-up voordat je verdergaat

Vertrouw niet alleen op een afsluitregel van rsync. Vergelijk het aantal bestanden en controleer de omvang van de belangrijkste mappen:

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

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

Voor onvervangbare gegevens heeft een tweede, onafhankelijke back-up de voorkeur. RAID is op zichzelf geen back-up.

Laatste redmiddel: gegevens offloaden, oude RAID-metagegevens verwijderen en opnieuw aanmaken in de interface

De oorspronkelijke communityauteur wilde dat de herstelde array weer normaal door de ZimaOS-gebruikersinterface kon worden beheerd. Hun methode als laatste redmiddel was:

1. controleer de oude array alleen-lezen;
2. kopieer alle gegevens naar een externe schijf;
3. controleer de kopie;
4. stop de oude md-array;
5. verwijder de oude RAID-metagegevens;
6. maak een nieuwe RAID 1 aan met de ZimaOS-opslaginterface;
7. herstel de gekopieerde bestanden;
8. controleer de herstelde gegevens.

Deze procedure vernietigt opzettelijk de oude RAID-metagegevens. Zodra je die stap uitvoert, wordt de offloadkopie je bron voor herstel. Gebruik deze aanpak niet als de kopie onvolledig is of als je niet zeker weet welk apparaat het is.

De onomkeerbare opdracht in de bronworkflow

De communityprocedure was:

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

Dit is geen opdracht voor probleemoplossing. Hiermee worden RAID-metagegevens van de opgegeven schijven verwijderd. Een verkeerd apparaatpad kan tot aanzienlijk gegevensverlies leiden.

Daarom raadt deze pagina niet aan om dit alleen uit te voeren omdat de ZimaOS-gebruikersinterface een RAID niet herkent. Herstellen local-storage.db, controleer het huidige herstelgedrag van ZimaOS en neem eerst contact op met support wanneer de array belangrijke gegevens bevat.

Waarom de array opnieuw aanmaken via de ZimaOS-gebruikersinterface?

Het doel van de bronworkflow was te eindigen met een opslagpool die normaal door ZimaOS wordt beheerd, in plaats van met een permanent handmatig samengesteld md-apparaat buiten de opslaginterface.

Nadat de oude gegevens veilig zijn geoffload en de schijven bewust zijn gereset, gebruikt u de huidige Opslag-interface om RAID 1 aan te maken en laat u de eerste synchronisatie voltooien.

Herstel de bestanden naar de nieuwe pool

Nadat de nieuwe pool is aangemaakt en gekoppeld, herstelt u de gegevens vanaf de offloadschijf:

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

Vervang /media/Storage met het daadwerkelijke bestemmingspad dat op uw systeem wordt weergegeven.

Controleer de herstelde pool

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

Laat de offloadschijf onaangeroerd totdat de RAID-synchronisatie is voltooid en u normale toegang hebt gecontroleerd via de Bestanden-interface van ZimaOS en de toepassingen die van de gegevens afhankelijk zijn.

Maak een back-up van local-storage.db vóór de volgende herinstallatie

Het eenvoudigste herstel is het herstel waarop u zich vooraf hebt voorbereid. Bewaar een actuele kopie van:

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

buiten het systeemstation. De officiële documentatie biedt nu een directe herstelprocedure met dit bestand.

Welk herstelpad moet u kiezen?

Veelgestelde vragen over RAID-herstel in ZimaOS

Wist het opnieuw installeren van ZimaOS RAID-gegevens automatisch?

Nee. Het opnieuw installeren van het systeemstation verschilt van het formatteren van de RAID-ledenschijven. De opslagconfiguratie kan verloren gaan terwijl de RAID-metagegevens en gegevens op de leden behouden blijven.

Moet ik op RAID aanmaken klikken als de oude schijven als ongebruikt worden weergegeven?

Niet voordat u hebt bevestigd dat er geen bestaande gegevens hoeven te worden hersteld. Het aanmaken van een nieuwe RAID kan destructief zijn.

Wat is het veiligste herstel als ik een back-up van local-storage.db heb gemaakt?

Gebruik de huidige officiële ZimaOS-procedure om die database te herstellen en opnieuw op te starten.

Is het veilig om het mdadm-superblok op nul te zetten?

Het is bewust destructief voor RAID-metagegevens. Gebruik dit alleen als onderdeel van een geverifieerd herstelplan nadat de gegevens veilig elders zijn gekopieerd.