Récupérer le RAID 1 de ZimaOS après la réinstallation du système d’exploitation

Si ZimaOS est réinstallé et qu’un RAID 1 existant apparaît comme des disques inutilisés, ne cliquez pas immédiatement sur Créer un RAID. La recréation ou le formatage de la baie peut détruire les données encore présentes sur les disques membres.

La première méthode de récupération doit être la méthode officielle actuelle de ZimaOS : restaurer la sauvegarde local-storage.db fichier provenant de l’installation précédente du système. Le tutoriel communautaire associé à cette page décrit une solution de secours plus invasive pour le cas plus difficile où cette base de données n’a pas été sauvegardée. Cette solution a été testée sur ZimaOS 1.6.1, mais elle inclut des opérations RAID destructrices et ne doit être envisagée qu’après avoir copié et vérifié les données sources indépendamment.

Premier choix : restaurer local-storage.db

ZimaOS conserve les informations de configuration du stockage dans :

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

Le guide officiel actuel de récupération recommande de télécharger ce fichier avant de réinstaller le système, puis de le remettre dans le même répertoire après la nouvelle installation de ZimaOS et le redémarrage.

Récupération officielle d’un RAID ZimaOS après réinstallation

Si vous avez encore accès à l’ancien disque système, essayez de récupérer cette base de données avant de toucher aux disques membres du RAID.

Pourquoi la baie de données peut être encore intacte

ZimaOS utilise le RAID logiciel de Linux. Les disques membres peuvent conserver leurs métadonnées RAID même lorsque la nouvelle installation de ZimaOS ne possède plus l’ancienne base de données de stockage. C’est pourquoi les disques peuvent apparaître physiquement présents alors que l’interface utilisateur ne reconnaît plus le pool d’origine.

ZimaOS 1.6 a également introduit une meilleure récupération des métadonnées RAID et un meilleur comportement de réidentification. Un problème observé à l’origine sur un système ne doit donc pas être considéré comme identique sur toutes les versions plus récentes.

Ne créez pas de nouveau RAID avant d’avoir décidé de la méthode de récupération

Si les disques contiennent des données dont vous avez besoin, évitez :

formater l’un des disques membres ;
créer un nouveau RAID sur les mêmes disques ;
exécuter wipefs ou mdadm --zero-superblock prématurément ;
deviner lequel /dev/sdX quel est le périphérique.

Avant toute opération de récupération, identifiez les disques par leur modèle, leur numéro de série et leur capacité, plutôt que de vous fier uniquement aux lettres des périphériques.

Vérifier les métadonnées RAID en lecture seule

L’auteur de la communauté a d’abord effectué une inspection en lecture seule pour confirmer que les deux membres du RAID 1 appartenaient toujours à la même baie.

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

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

Pour qu’un RAID 1 soit sain, ses deux membres doivent signaler le même UUID de baie et des métadonnées RAID compatibles. Si un membre est absent, dégradé ou signale des métadonnées différentes, arrêtez-vous et demandez de l’aide pour la récupération plutôt que de suivre une procédure générique de reconstruction.

Assemblez et montez l’ancien array en lecture seule

Pour une récupération avancée, un assemblage en lecture seule réduit le risque de modifier la source pendant la vérification de l’accessibilité des fichiers :

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

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

Inspectez ensuite le système de fichiers :

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

Les noms de périphériques ci-dessus sont uniquement des exemples. Ne les collez jamais tels quels sans avoir confirmé qu’ils correspondent à votre matériel.

Créez une copie déportée complète avant toute étape destructive

Le processus décrit dans la source utilise un disque externe au format ext4, suffisamment grand pour contenir toutes les données utilisées du RAID. Pour les données d’applications Linux, ext4 est utile, car il peut préserver les propriétaires, les permissions, les liens, les ACL et les attributs étendus habituels.

Une copie typique de type archivage est la suivante :

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

Exécutez la copie dans tmux ou un autre terminal persistant si une déconnexion SSH interromprait autrement l’opération.

Vérifiez la sauvegarde avant d’aller plus loin

Ne vous fiez pas uniquement à la ligne de sortie d’rsync. Comparez le nombre de fichiers et examinez la taille des principaux répertoires :

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

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

Pour les données irremplaçables, il est préférable de disposer d’une seconde sauvegarde indépendante. Un RAID ne constitue pas en soi une sauvegarde.

Dernier recours : déporter les données, supprimer les anciennes métadonnées RAID, puis recréer l’array dans l’interface

L’auteur original de la procédure communautaire souhaitait que l’array récupéré soit à nouveau géré normalement via l’interface de ZimaOS. Sa méthode de dernier recours était la suivante :

vérifiez l’ancien array en lecture seule ;
copiez toutes les données sur un disque externe ;
vérifiez la copie ;
arrêtez l’ancien array md ;
supprimez les anciennes métadonnées RAID ;
créez un nouveau RAID 1 via l’interface de stockage de ZimaOS ;
restaurez les fichiers copiés ;
vérifiez les données restaurées.

Cette procédure détruit intentionnellement les anciennes métadonnées RAID. Une fois cette étape effectuée, la copie déportée devient votre source de récupération. N’utilisez pas cette approche si la copie est incomplète ou si vous avez le moindre doute sur l’identité des périphériques.

La commande irréversible du processus décrit dans la source

La procédure utilisée par la communauté :

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

Il ne s’agit pas d’une commande de dépannage. Elle supprime les métadonnées RAID des disques spécifiés. Un chemin de périphérique incorrect peut entraîner une perte de données majeure.

Pour cette raison, cette page ne recommande pas de l’exécuter simplement parce que l’interface de ZimaOS ne reconnaît pas un RAID. Restaurer local-storage.db, vérifiez le comportement actuel de récupération de ZimaOS et contactez d’abord le support lorsque l’array contient des données importantes.

Pourquoi recréer l’array via l’interface de ZimaOS ?

L’objectif du processus source était de terminer avec un pool de stockage géré normalement par ZimaOS, plutôt qu’avec un périphérique md assemblé manuellement et maintenu en dehors de l’interface de stockage.

Une fois les anciennes données transférées en toute sécurité et les disques intentionnellement réinitialisés, utilisez l’interface Stockage actuelle pour créer un RAID 1 et laissez la synchronisation initiale se terminer.

Restaurez les fichiers dans le nouveau pool

Une fois le nouveau pool créé et monté, restaurez les données depuis le disque de transfert :

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

Remplacez /media/Storage avec le chemin de destination réel affiché par votre système.

Vérifiez le pool restauré

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

Laissez le disque de transfert intact jusqu’à la fin de la synchronisation RAID et vérifiez que l’accès normal fonctionne via l’interface Fichiers de ZimaOS ainsi que dans les applications qui dépendent des données.

Sauvegardez local-storage.db avant la prochaine réinstallation

La récupération la plus simple est celle qui a été préparée à l’avance. Conservez une copie à jour de :

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

en dehors du disque système. La documentation officielle fournit désormais une procédure de restauration directe à l’aide de ce fichier.

Quel chemin de récupération choisir ?

Situation	Action recommandée
Vous avez sauvegardé local-storage.db.	Utilisez la méthode officielle de restauration de la base de données.
L’ancien disque système est toujours lisible.	Récupérez local-storage.db avant de modifier les disques RAID.
Aucune sauvegarde de la base de données, mais les métadonnées RAID semblent saines.	Mettez en pause les actions destructives et demandez de l’aide ou des conseils en récupération.
Vous disposez d’une copie complète et vérifiée des données transférées et souhaitez intentionnellement créer une baie propre gérée par l’interface.	Envisagez la méthode communautaire de transfert, recréation et restauration.
Les membres du RAID affichent des métadonnées incohérentes ou dégradées.	Arrêtez-vous et consultez des conseils spécialisés en matière de récupération.

FAQ sur la récupération d’un RAID ZimaOS

La réinstallation de ZimaOS efface-t-elle automatiquement les données RAID ?

Non. Réinstaller le disque système est différent du formatage des disques membres du RAID. La configuration du stockage peut être perdue tandis que les métadonnées RAID et les données restent sur les disques membres.

Dois-je cliquer sur « Créer un RAID » si les anciens disques apparaissent comme inutilisés ?

Pas avant d’avoir confirmé qu’aucune donnée existante ne doit être récupérée. La création d’un nouveau RAID peut être destructive.

Quelle est la récupération la plus sûre si j’ai sauvegardé local-storage.db ?

Utilisez la procédure officielle actuelle de ZimaOS pour restaurer cette base de données, puis redémarrez.

La remise à zéro du superbloc mdadm est-elle sûre ?

Cette opération est intentionnellement destructive pour les métadonnées RAID. Utilisez-la uniquement dans le cadre d’un plan de récupération vérifié, après avoir copié les données en lieu sûr ailleurs.