Solution communautaire

La récupération RAID de ZimaOS fonctionne-t-elle ? Ce que la panne de 2024 a signifié

A ZimaCube owner deliberately broke a RAID5 to test drive replacement and found that the 1.2.1 recovery UI could not accept the replacement disk.

Réponse actuelle : Oui, la récupération RAID existe — mais cet échec de 2024 s’est produit alors que le remplacement était désactivé

Le test ayant échoué est historiquement avéré. Dans ZimaOS 1.2.1, IceWhale a explicitement indiqué que le remplacement RAID avait été désactivé en raison d’un problème de vérification. La boîte de dialogue de récupération vide ne prouvait donc pas que la récupération RAID ne pouvait jamais fonctionner ; il s’agissait d’une fonctionnalité désactivée dans une version spécifique.

Page Stockage de ZimaOS affichant un RAID dégradé en mode lecture seule et demandant un disque de remplacement
Le test de 2024 a volontairement retiré puis reformaté un membre du RAID5. ZimaOS a verrouillé la grappe dégradée en lecture seule et demandé un disque de remplacement.
Boîte de dialogue de récupération RAID de ZimaOS indiquant qu’aucun disque dur n’est disponible pour le test de remplacement ayant échoué
La boîte de dialogue de récupération RAID ne pouvait pas proposer le disque réinséré dans ZimaOS 1.2.1, ce qui correspond à la déclaration ultérieure d’IceWhale selon laquelle le remplacement avait été temporairement désactivé.

Ne recréez pas et ne formatez pas un RAID lorsque les données sont encore importantes

Les pratiques actuelles de récupération sont beaucoup plus prudentes. Si une grappe existante n’est plus reconnue après une réinstallation ou la perte de la base de données de stockage, préservez les disques membres et récupérez la configuration RAID enregistrée avant de créer une nouvelle grappe. La page récupération RAID de ZimaOS explique la méthode actuelle avec local-storage.db ainsi que la limite à partir de laquelle le recours devient destructif.

L’outil Linux d’inspection des grappes mdadm constitue la référence en amont pour identifier une grappe md.

Un test de remplacement ayant échoué et une mise à jour ayant échoué étaient deux problèmes différents

Écran des paramètres généraux de ZimaOS 1.2.0 sans la notification de mise à jour attendue
L’écran ZimaOS 1.2.0 d’un autre utilisateur n’affichait pas l’invite de mise à jour attendue ; la discussion a ensuite établi que ce problème précis était dû au blocage du trafic de téléchargement par le pare-feu.

La discussion a ensuite mentionné un système en version 1.2.0 qui ne pouvait pas voir la mise à jour. Ce cas s’est révélé lié au pare-feu : le téléchargement de la mise à jour était bloqué. Ne confondez pas une mise à jour logicielle indisponible avec l’échec du remplacement d’un membre du RAID, simplement parce que les deux problèmes sont apparus dans la même discussion.

Testez la récupération avec des données que vous pouvez perdre

L’intention initiale était bonne : vérifier le mode dégradé et le comportement de remplacement avant de confier des données importantes à une grappe. Utilisez des fichiers de test jetables, retirez proprement un membre, vérifiez que la grappe passe en mode dégradé et en lecture seule comme prévu, ajoutez un disque de remplacement connu et surveillez l’état de la reconstruction.

Le fonctionnement de Linux MD fournit le modèle de niveau inférieur.

La récupération RAID ne remplace pas une sauvegarde

Une reconstruction RAID réussie protège contre la défaillance d’un disque membre. Elle ne protège pas contre une suppression accidentelle, une corruption du système de fichiers, un logiciel malveillant, des erreurs de contrôleur ou la création d’une nouvelle grappe sur les mauvais disques. Conservez une deuxième copie vérifiée en dehors de la grappe.

Pour le matériel actuel à plusieurs disques et la planification de la récupération, le stockage ZimaCube 2 fournit le contexte de la plateforme actuelle.