Récupération de données
Récupération de données au Pouzin (07250)
Si un volume Ceph RBD devient inaccessible au Pouzin, stoppez les écritures et le rééquilibrage. Datastrophe acquiert les OSD au laboratoire, reconstitue les OSDMap et chaque placement group (PG, groupe de placement), puis valide l'image RBD et son système de fichiers.
Diagnostic et devis
Reconstituer l'OSDMap à l'epoch utile avant d'assembler les objets RBD
L'inventaire associe chaque support à son OSD, son FSID, son type de stockage et ses partitions, sans démarrer les démons sur les originaux.
Les OSDMap disponibles sont alignées avec les historiques des placement groups. Les changements de poids, d'état ou de topologie restent datés.
Les objets candidats sont évalués par version et continuité. Les lacunes sont cartographiées avant de présenter une image RBD ou un snapshot.
- Disques OSD BlueStore ou FileStore d'un cluster Ceph
- Volumes RBD, snapshots et clones associés
- Nœuds MON, OSDMap, cartes CRUSH et historique des epochs
- Bases RocksDB, WAL BlueStore et métadonnées d'objets
- Systèmes de fichiers ou images de machines hébergés dans RBD
Attention
Le peering Ceph établit l'état autoritatif avant toute synchronisation d'objets
- Suspendre les clients RBD
- Désactiver le rééquilibrage et le backfill (analyse et synchronisation de l'ensemble du placement group)
- Ne réintégrer aucun OSD
- Conserver les nœuds MON et les cartes historiques
- Repérer chaque disque par son identifiant OSD
Aucun OSD reçu du Pouzin n'est réactivé dans le cluster d'origine. Les epochs, les journaux et les versions sont comparés sur des copies avant toute reconstruction.
Préparer le devis
Figer le cluster avant tout nouveau peering Ceph
Au Pouzin, interrompez les mécanismes automatiques avant qu'une synchronisation de placement group ou une activation d'OSD ne modifie l'état encore exploitable.
- Arrêter les écritures des clients
- Suspendre le recovery, les synchronisations de placement groups et le reweight (modification du poids des OSD)
- Étiqueter chaque support par OSD et nœud
- Conserver les données des nœuds MON
- Exporter les cartes déjà accessibles
- Lister pools, images et snapshots prioritaires
Comment ça marche
Acquérir les OSD, résoudre les placements puis valider le volume
- Au Pouzin, arrêtez les clients, le rééquilibrage et les opérations de réparation, puis identifiez chaque OSD sans le réintégrer au cluster.
- Les supports sont acquis séparément au laboratoire. UUID, FSID, identifiants OSD, partitions, journaux et erreurs de lecture restent liés à leur image.
- Les OSDMap et cartes CRUSH sont ordonnées selon leur epoch afin de reproduire la distribution valable au moment de l'incident.
- Les objets de chaque placement group (PG, groupe de placement) sont comparés par version et historique. Une réplique ancienne n'écrase jamais automatiquement une version plus récente.
- Les objets RBD retenus reconstituent une image candidate; snapshots, clones, système invité et fichiers prioritaires sont ensuite contrôlés.
Nos expertises
OSD, nœuds MON, OSDMap, placement groups, objets, RBD et données invitées restent corrélés
Notre expertise
Un OSD disponible n'est pas forcément porteur de la version utile d'un objet
Ceph distribue les objets sans table centrale unique décrivant chaque bloc du volume. La carte CRUSH, l'epoch de l'OSDMap et l'identité du pool sont nécessaires pour retrouver les ensembles de répliques attendus.
Un placement group (PG, groupe de placement) incomplet peut contenir des objets à des versions différentes. Le numéro d'objet seul ne permet pas de choisir: les journaux de PG, les versions et les intervalles d'activité servent à établir la continuité.
BlueStore associe données brutes et métadonnées RocksDB. Une opération d'activation ou de réparation sur le support d'origine peut compacter les bases, rejouer un journal ou transformer l'état qu'il fallait examiner.
Récupérer les objets ne suffit pas à prouver l'image RBD. Leur ordre, leur taille et les relations de snapshot doivent produire un volume invité cohérent, puis des fichiers réellement exportables.
- Cluster
- Le FSID et les epochs définissent le bon historique des OSDMap
- Placement
- CRUSH relie objets et OSD pour chaque epoch
- Répliques
- Versions et journaux départagent les copies
- RBD
- L'image reconstruite est validée au niveau invité
Prise en charge
Topologie Ceph et chronologie à documenter depuis Le Pouzin
Depuis Le Pouzin, conservez la liste des nœuds, OSD, pools, snapshots et clients, ainsi que les sorties d'état déjà disponibles. Notez l'ordre exact des pannes et redémarrages.
Le transport privé aller et retour est pris en charge. Le transporteur achemine les supports emballés et suivis jusqu'au laboratoire puis les retourne; il n'analyse ni le cluster ni les données.
Précisez le volume RBD, la machine ou le répertoire prioritaire. Les clés et secrets d'accès ne voyagent pas dans le colis et peuvent être communiqués séparément.
Des epochs du cluster jusqu'aux fichiers du volume invité
Choisir les bonnes répliques avant de reconstruire l'image RBD
Chaque placement group est résolu avec son historique propre. Les objets manquants ou contradictoires conservent un statut explicite.
L'image candidate est ouverte sur une copie isolée. Snapshots, partitions et système de fichiers sont contrôlés avant l'export des données demandées.
- OSD attribués Chaque disque garde son identité et son rôle.
- Chronologie des epochs La topologie historique guide le placement.
- Objets arbitrés Versions et journaux de PG départagent les répliques.
- Volume éprouvé Les fichiers invités confirment la reconstruction.
Carte
Situer l'origine de la demande au Pouzin
FAQ
Questions sur un volume Ceph RBD au Pouzin
Faut-il réintégrer un OSD qui semble sain?
Non. Son activation peut déclencher le peering: les OSD s'accordent alors sur l'état, les métadonnées et l'historique autoritatif du placement group, sans copier d'objet. Le recovery synchronise ensuite les répliques. Le backfill (analyse et synchronisation de l'ensemble du placement group) en est un cas particulier qui ne déduit pas seulement les objets à copier des journaux; ces écritures modifieraient l'état à comparer.
Pourquoi les cartes historiques du cluster sont-elles importantes?
Elles décrivent quels OSD devaient porter chaque placement group à une epoch donnée et éclairent les changements de topologie.
La majorité des répliques garantit-elle la bonne version?
Pas toujours. Les versions d'objets, les journaux de PG et la chronologie doivent confirmer la continuité avant tout choix.
Comment départager des répliques portant des versions différentes?
Les versions d'objets sont confrontées aux journaux du placement group, aux intervalles d'activité et à l'epoch (numéro de version de l'OSDMap) correspondante.
Quand un volume RBD est-il considéré comme récupéré?
Après reconstruction cohérente des objets, ouverture du système invité et vérification des fichiers prioritaires exportés.
Diagnostic et devis
Contrôler le contenu du volume après l'arbitrage de ses objets distribués
Le diagnostic et le devis sont gratuits. Avant paiement, la liste distingue les fichiers récupérables et vérifiés, partiels, détectés sans preuve d'intégrité et non exploitables. Le client paie seulement après acceptation de la liste et du prix. Sans résultat exploitable, après un échec final ou en cas de refus, aucun frais standard n'est dû. Une pièce rare et coûteuse exige un accord séparé, explicite et chiffré; son coût reste non remboursable même si la récupération n'aboutit pas.