Récupération de données
Récupération de données à Grasse (06130)
À Grasse, arrêtez PostgreSQL et conservez PGDATA avec les volumes de tablespaces déplacés. Le laboratoire image les supports, rapproche les OID, les catalogues, la tablespace_map et le WAL, puis valide sur des copies les bases réellement rattachables.
Diagnostic et devis
Rattacher chaque OID PostgreSQL au bon volume de tablespace
Le diagnostic distingue support non monté, copie incomplète et disque défaillant, car leurs acquisitions diffèrent.
PGDATA est relevé avec version, pg_control, catalogues et pg_tblspc, sans modifier les liens.
OID, tailles de relations, chronologies des sauvegardes et WAL excluent les volumes homonymes incompatibles.
La topologie est testée sur duplication; les objets métier sont lus, mais un index n'est pas une table.
- SSD système portant PGDATA, le catalogue et pg_tblspc
- HDD mécanique avec des tablespaces externes déplacés
- LUN dont le point de montage a changé après restauration
- Disque externe avec une copie partielle d'un tablespace
- NAS ou RAID avec volumes PostgreSQL de générations différentes
- Serveur ou VM avec configuration, journaux et montages
- Support flash avec sauvegarde de base, tablespace_map ou WAL
- Images disque protégées pour tester sans écrire
Attention
Éviter de rattacher PGDATA à une génération de tablespace incorrecte
- Ne recréez pas les liens pg_tblspc dans PGDATA
- Ne montez pas un volume candidat au chemin attendu pour tester
- Ne démarrez pas PostgreSQL avec un tablespace manquant ou incompatible
- Ne copiez pas de répertoires d'OID sur les volumes sources
- Ne lancez ni réindexation ni VACUUM sur le cluster reçu
- Ne supprimez pas les liens cassés avant l'inventaire
- Ne mélangez pas WAL et sauvegardes sans provenance
- Gardez les journaux, les fichiers de montage et les captures d'erreurs
À Grasse, recréer un lien, remonter un volume ou démarrer PostgreSQL peut écrire dans une mauvaise arborescence. Les supports restent isolés jusqu'à comparaison sur des copies.
Comment ça marche
Des volumes isolés aux objets PostgreSQL vérifiés
- Arrêtez PostgreSQL et bloquez les montages automatiques; notez chemins, changements et essais.
- Étiquetez PGDATA et chaque volume avec points de montage, dates, tailles et identifiants.
- Le laboratoire qualifie séparément chaque support; la salle blanche reste limitée à un HDD mécanique.
- Les médias stables sont copiés en images contrôlées, en conservant métadonnées et liens d'origine.
- Sur des copies, les OID de pg_tblspc et des catalogues sont rapprochés des volumes, de la tablespace_map, de pg_control, des sauvegardes et du WAL.
- Une topologie candidate est reconstruite en environnement isolé avant contrôle des bases, relations et objets prioritaires.
- Après accord, la restitution documente les tablespaces absents et les objets non vérifiés.
Nos expertises
Supports examinés lors d'une migration de tablespaces PostgreSQL
Préparer le devis
Conserver les chemins et volumes avant tout nouveau montage
Depuis Grasse, étiquetez les supports et conservez la configuration pour retracer la topologie sans test sur le cluster original.
- Arrêter PostgreSQL et les tâches qui l'écrivent
- Empêcher le montage automatique des volumes
- Étiqueter PGDATA et chaque support externe
- Noter les anciens et les nouveaux points de montage
- Conserver le répertoire pg_tblspc et ses liens observés
- Joindre la tablespace_map et la configuration
- Garder les sauvegardes et le WAL avec leur provenance
- Signaler les démarrages déjà tentés
- Lister les bases et les tables prioritaires
- Transmettre les accès par le canal prévu
Notre expertise
Une reconstruction guidée par les identifiants du cluster
Un tablespace est référencé par OID et stocké hors PGDATA; le nom du volume ne suffit pas.
PGDATA et les fichiers de relations peuvent être sur deux hôtes; ils doivent provenir d'un état compatible.
Tablespace_map, liens pg_tblspc, catalogues et journaux de montage se complètent; aucun indice isolé ne suffit.
Les volumes concurrents restent montés uniquement sur des copies contrôlées, sans modifier la source.
La validation contrôle les bases, les schémas, les tables, les index et les échantillons; le démarrage seul ne prouve rien.
Conservez tout disque ayant porté PGDATA ou un tablespace, ainsi que clés USB et cartes contenant une sauvegarde.
- PGDATA
- Conserver le catalogue
- OID de tablespaces
- Identifier les volumes
- Points de montage
- Retracer les chemins
- Objets SQL
- Valider les relations
Prise en charge
Préparer depuis Grasse les volumes PostgreSQL déplacés
Cette page traite les demandes venant de Grasse sans annoncer d'implantation locale.
Notez ancien et nouvel hôte, points de montage, ordre des copies et messages exacts de PostgreSQL.
Photographiez les connexions; étiquetez les LUN, les disques et les membres RAID, puis conservez la configuration et les montages.
Listez les bases, les schémas, les tables et les périodes prioritaires sans requête sur la source; les secrets suivent le canal autorisé.
Le devis sépare acquisition, inventaire des OID, reconstruction des chemins, récupération et validation, sans garantie sur un tablespace manquant.
OID et volumes à raccorder
Reconstituer la topologie des tablespaces sans substitution hasardeuse
Le périmètre réunit PGDATA, pg_tblspc, catalogues, volumes, tablespace_map, pg_control, configuration et WAL.
Deux volumes peuvent partager un chemin tout en venant de sauvegardes différentes; identifiants et chronologie priment.
HDD, SSD, LUN, NAS, RAID, serveur et VM sont couverts; la salle blanche ne vaut que pour un HDD à ouvrir.
La restitution peut fournir des exports logiques depuis un cluster isolé, avec les limites signalées.
- Répertoire PGDATA Identifier la version et le catalogue.
- Liens pg_tblspc Conserver les OID et chemins observés.
- Volumes externes Comparer les générations sans les mélanger.
- WAL et sauvegardes Établir une chronologie compatible.
- Relations métier Contrôler les objets et données prioritaires.
Carte
Orienter l'analyse selon la topologie et l'état des supports
FAQ
Questions sur les tablespaces PostgreSQL déplacés
Puis-je recréer un lien pg_tblspc vers le volume le plus récent?
Non sur la source. Le volume doit d'abord être rapproché de l'OID, de la version et de la chronologie.
Un point de montage identique garantit-il le bon tablespace?
Non. Plusieurs générations peuvent partager le même chemin; catalogues et fichiers de relations doivent correspondre.
Faut-il conserver les liens symboliques cassés?
Oui. Ils documentent les OID et chemins attendus avant la migration.
La tablespace_map suffit-elle à reconstruire les chemins?
Elle aide pour une sauvegarde donnée, mais doit être comparée aux volumes et catalogues.
PostgreSQL peut-il démarrer avec un tablespace absent?
Un démarrage ne garantit pas l'accès aux objets et peut modifier l'état; les tests passent par une copie reconstruite.
La salle blanche est-elle nécessaire pour PostgreSQL?
Seulement si un HDD mécanique doit être ouvert; SSD, LUN ou mauvais rattachement appellent une autre méthode.
Les index manquants empêchent-ils toute récupération?
Pas toujours. Les données de table et les index sont distingués; tout dépend de l'état des relations utiles.
Peut-on restituer seulement certaines bases?
Oui, si leurs catalogues, tablespaces et relations sont cohérents; le périmètre peut privilégier les objets métier essentiels.
La restitution redémarre-t-elle nécessairement le serveur?
Non. Des exports contrôlés depuis un environnement isolé peuvent être plus sûrs qu'une remise en service directe.
Diagnostic et devis
Faire identifier les bons volumes avant toute remise en service
Décrivez la migration, les hôtes, les points de montage, les supports et les objets prioritaires pour chiffrer le rattachement sans promettre qu'un volume homonyme est compatible.