Analyse
Identifier la couche en panne
Un serveur vidéo multi-disques peut échouer à cinq niveaux successifs : disque physique, géométrie RAID, système de fichiers, stockage NAS, puis catalogue VMS. Une période vide dans la console ne révèle pas la couche fautive.
| Couche | Indice possible | Question du diagnostic |
|---|---|---|
| Disque | Absence, lenteur, secteurs instables | Quelles zones peuvent être acquises ? |
| RAID | Grappe dégradée ou incohérente | Quel ordre, niveau, stripe et décalage ? |
| Système de fichiers | Volume non monté, métadonnées corrompues | Où se trouvent les fichiers et bases ? |
| NAS/partage | Droits ou service indisponibles | Les blocs existent-ils malgré l’accès perdu ? |
| VMS | Calendrier vide, service arrêté | Quels flux correspondent aux canaux et heures ? |
Datastrophe traite ces couches dans cet ordre. Remonter trop tôt le VMS sur un RAID incertain peut produire des fichiers apparemment lisibles mais assemblés avec une mauvaise parité. L’inventaire initial relève modèle, baies, capacités, alertes, contrôleur, dernier remplacement et opérations tentées.
La chronologie des opérations est aussi importante que la topologie. Un membre déclaré défaillant, remplacé puis suivi d’un second défaut ne représente pas le même état qu’une panne simultanée. Les métadonnées du contrôleur, les journaux et les anciens disques permettent parfois de distinguer l’état cohérent le plus récent d’une reconstruction partielle.
Topologie à vérifier — la topologie des caméras IP localise une perte entre la caméra et sa destination. Un stockage central multi-disques exige ensuite de qualifier la géométrie RAID, le système de fichiers et le catalogue VMS.
Analyse
Préserver les disques et l’ordre RAID
L’ordre physique, le niveau RAID, la taille de bande, la rotation de parité et le décalage de départ déterminent la lecture logique. Un disque remplacé trop tôt peut contenir un état antérieur plus utile que le membre reconstruit ; il doit être conservé avec la baie.
Figer l’historique
Photographiez les emplacements et messages, étiquetez chaque support, notez les remplacements, rebuilds, extensions ou changements de contrôleur. Ne laissez pas le NAS initialiser un membre « neuf » ni poursuivre une synchronisation.
Acquérir chaque membre
Les disques sont imagés séparément avec cartographie des zones illisibles. L’ordre et la géométrie sont ensuite testés sur des copies. Une cohérence de système de fichiers et plusieurs fichiers répartis sur des bandes différentes servent à valider l’hypothèse ; le simple fait que le volume monte ne suffit pas.
Les paramètres peuvent varier au sein d’un même parc. Le niveau RAID affiché ne renseigne pas toujours le décalage de données, la rotation de parité ou une zone réservée par le contrôleur. Une mauvaise hypothèse peut produire des en-têtes valides sur de petits fichiers et corrompre les gros conteneurs qui traversent de nombreuses bandes. La validation utilise donc des structures situées à plusieurs endroits du volume.
Séparer récupération et remise en service
La reconstruction virtuelle sert à lire les données, pas à certifier le stockage pour la production. La vidéosurveillance doit repartir sur une infrastructure saine distincte pendant que les sources restent figées.
Analyse
Comprendre le rôle du serveur VMS
Le VMS conserve souvent plusieurs familles de données : configuration des caméras, catalogue des enregistrements, journaux, événements et flux bruts. Une base peut être corrompue alors que les vidéos subsistent ; l’inverse est aussi possible.
Les flux peuvent être encapsulés dans des conteneurs propriétaires autour de codecs comme H.264 ou H.265/HEVC. Retrouver des blocs vidéo ne restitue donc pas automatiquement le canal, l'heure ni la continuité : ces attributs dépendent encore des index, journaux et règles de rétention du VMS.
Après reconstruction du volume, le laboratoire cherche séparément :
- Identifiants et noms de caméras ;
- Chemins et politiques de rétention ;
- Index temporels et tables d’événements ;
- Journaux d’arrêt, de perte de volume ou de réindexation ;
- Conteneurs vidéo et lecteurs natifs.
Ces éléments sont ensuite rapprochés. Les index et conteneurs vidéo peuvent reconstruire une piste quand la console refuse de démarrer. Si l’identifiant d’une caméra ou l’heure restent incertains, cette incertitude doit accompagner la séquence.
Un serveur VMS virtualisé ajoute éventuellement l’espace de stockage partagé, le disque virtuel et les snapshots avant l’application. Chaque couche doit être documentée ; restaurer un snapshot au hasard pourrait remplacer l’état recherché.
Les bases applicatives sont conservées avec leurs journaux. Copier uniquement le fichier principal pendant que le service tourne peut séparer une transaction de son journal. Si un copie mémoire ou un export de configuration existe, il sert de repère mais ne remplace pas l’état reçu. La rétention peut aussi répartir les canaux sur plusieurs pools : une caméra peut être complète tandis qu’une autre dépend d’un membre illisible. Le verdict descend donc au niveau piste et plage.
Analyse
Éviter les réparations automatiques
Les fonctions « réparer », « vérifier », « initialiser » et « reconstruire » modifient les métadonnées du RAID ou du système de fichiers. Elles conviennent à une maintenance ordinaire avec sauvegarde validée, pas à la préservation de la seule copie d’une séquence critique.
Évitez également :
- La copie massive depuis un volume qui ralentit ou perd des membres ;
- La restauration d’un snapshot sur le volume source ;
- La réinstallation du VMS et la création d’une base neuve ;
- Le remplacement successif de plusieurs disques ;
- L’export applicatif prolongé quand des erreurs matérielles apparaissent.
Règle multi-disques — aucune action corrective ne doit précéder l’inventaire, le repérage et l’acquisition des membres disponibles.
Les sauvegardes et snapshots existants sont conservés à part. Ils peuvent fournir une configuration ou un index antérieur, mais leur restauration ne doit pas écraser l’état post-incident avant comparaison.
Analyse
Construire une restitution exploitable
La restitution distingue la reconstruction du stockage et l’interprétation VMS. Le compte rendu peut préciser la géométrie retenue, les membres incomplets, le système de fichiers lu, la version du VMS et les sources utilisées pour attribuer chaque séquence.
Le livrable classe au minimum : caméra ou canal, plage, fuseau, version native, version de consultation et état de continuité. Une séquence issue d’un RAID virtuellement remonté n’est pas présentée comme un export direct de la console. Un horodatage déduit d’un journal partiel reste signalé comme tel.
Pour la couche physique, la récupération de données RAID détaille la prise en charge. Pour l’installation complète, le service de récupération NVR cadre l’envoi. Si l’usage exige une restitution vidéo documentée, copies, empreintes et transformations doivent être identifiables.
Un volume remonté est une étape ; une vidéo attribuée et contrôlée est le résultat. Certaines caméras peuvent rester partielles si des bandes ou index manquent, et aucune reconstruction RAID ne recrée des blocs réellement absents.
Le dossier d’envoi doit inclure les membres présents, ceux remplacés, le contrôleur ou sa configuration si disponible, les captures de la baie et le modèle du VMS. Une liste numérotée suffit à préserver l’ordre. Si la production doit reprendre, un stockage neuf est préparé séparément ; aucun membre source n’est réintroduit pour gagner quelques heures au prix d’un nouveau rebuild.
Sources techniques primaires et limites
La documentation du noyau Linux sur les ensembles MD décrit superblocs, rôles, assemblage et états d’un RAID logiciel. Elle ne permet pas d’appliquer automatiquement une géométrie ou une génération à une baie propriétaire, et ne justifie aucune reconstruction sur les membres originaux.
Faire qualifier le dossier « Vidéosurveillance RAID, NAS, VMS : reconstruire le stockage »
Transmettez à Datastrophe tous les membres actifs, retirés et de secours avec leur ordre de slot, le contrôleur et son cache, les configurations, les cartes d’erreurs et les volumes prioritaires. Les codes, clés et éléments d’authentification autorisés sont communiqués par un canal distinct ; ils ne sont jamais inscrits sur le support ni dans le colis.
Datastrophe réalise directement le diagnostic, les contrôles d’intégrité et la récupération dans son laboratoire, avec sa propre équipe. Le diagnostic et le devis sont gratuits. Le transport privé aller et retour est systématiquement pris en charge ; le transporteur déplace uniquement le colis scellé, sans accéder aux données ni les traiter.
Avant tout paiement, le client reçoit le prix proposé et une liste contrôlée. Chaque élément y est classé, dans cet ordre, recoverable_verified, partial, detected_unverified ou unrecoverable. Seuls les éléments recoverable_verified, dont le contenu a été contrôlé et jugé exploitable, sont présentés comme récupérables. Le client paie seulement après avoir accepté la liste et le prix ; la préparation du résultat et la restitution interviennent ensuite.
Si aucune donnée exploitable n’est vérifiée, si la récupération échoue ou si le client refuse la liste ou le prix, aucun frais standard n’est dû. La seule exception concerne une pièce rare, coûteuse et non remboursable : elle ne peut être commandée qu’après une proposition séparée, explicite et chiffrée.