Récupération de données
Récupération de données à Annonay
À Annonay, arrêtez Odoo, PostgreSQL et les tâches planifiées. Conservez la base, les fichiers WAL, le filestore, les modules, la configuration, les journaux et les sauvegardes. Le laboratoire acquiert les supports, rapproche la base des fichiers sur des copies puis valide les enregistrements et les pièces jointes.
Diagnostic et devis
Diagnostiquer Odoo sans modifier la base
Le diagnostic distingue la panne d’un média, l’incomplétude du cluster PostgreSQL, l’absence de fichiers WAL, une sauvegarde logique partielle, un filestore absent, un module incompatible, une configuration perdue et un secret indisponible. Ces causes peuvent toutes produire une application inaccessible, mais elles exigent des acquisitions et des reconstructions différentes.
Les copies PostgreSQL sont examinées pour relever la version, la chronologie, les catalogues, les tables et les transactions disponibles. Les journaux Odoo, les configurations, les manifestes des modules et les arborescences du filestore complètent cette lecture. Aucune migration n'est exécutée sur les originaux.
- Disques durs contenant PostgreSQL, filestore ou modules Odoo
- SSD et NVMe portant la base applicative, les WAL, les index ou les journaux
- Serveurs physiques avec système, base et répertoires de données séparés
- NAS et ensembles RAID utilisés pour filestore, pièces jointes ou sauvegardes
Attention
Éviter restore, upgrade et nettoyage du filestore
- Ne relancez pas Odoo ou PostgreSQL sur les sources
- Ne restaurez pas une sauvegarde logique par-dessus l'unique base disponible
- Ne lancez pas de mise à niveau de modules ou de schéma
- Ne videz pas le filestore ou les pièces jointes orphelines
Toute opération susceptible de migrer le schéma, modifier les transactions ou supprimer des fichiers orphelins reste différée jusqu'à la création de copies protégées. La priorité est de préserver chaque génération avant d'établir une branche cohérente.
Comment ça marche
Des supports figés aux données Odoo validées
- Arrêtez le service Odoo, PostgreSQL, les workers, le cron, les imports et les connecteurs qui écrivent dans l'application. Ne lancez ni mise à niveau, ni restauration supplémentaire, ni réindexation. Notez l'heure de l'incident, les erreurs et toutes les commandes déjà exécutées.
- Inventoriez l'ensemble applicatif. Conservez le cluster PostgreSQL, les fichiers WAL disponibles, les sauvegardes logiques, le filestore, les pièces jointes, les modules standards et personnalisés, les fichiers de configuration, les secrets, les certificats, les versions de Python et d'Odoo, les journaux, les exports, les instantanés et les sauvegardes. Identifiez chaque hôte et chaque volume.
- Le laboratoire qualifie la stabilité physique de chaque média avant l'analyse logique. Un HDD instable, un SSD absent, un RAID dégradé, un espace de stockage virtuel corrompu ou un partage incomplet demande une acquisition adaptée. La salle blanche ne concerne qu'un disque dur mécanique qui doit être ouvert.
- Les volumes exploitables sont acquis bit à bit ou copiés vers un stockage sain en conservant les erreurs de lecture et les empreintes. Les originaux quittent le circuit d'essai. Les lectures PostgreSQL, les rapprochements du filestore et les démarrages contrôlés utilisent ensuite des duplications indépendantes.
Nos expertises
Supports et composants examinés pour Odoo
Préparer le devis
Préparer l'application sans lancer de migration
Une préparation contrôlée protège la base, les pièces jointes et les modules encore disponibles. Ne redémarrez pas les services avant la création de copies.
- Arrêter Odoo, PostgreSQL, workers, cron et connecteurs
- Noter l'heure de panne et toutes les commandes déjà tentées
- À identifier: versions Odoo, PostgreSQL, Python et système
- Conserver le cluster PostgreSQL, les WAL, les sauvegardes logiques et les catalogues
- À préserver: filestore, pièces jointes et exports
Notre expertise
Une méthode centrée sur les dépendances Odoo
Odoo partage son état entre PostgreSQL et des répertoires extérieurs à la base. Les pièces jointes peuvent être référencées dans les tables tandis que leur contenu réside dans le filestore. Une sauvegarde limitée à l'export SQL ne constitue donc pas toujours une application complète.
Les opérations réalisées après la panne sont datées précisément. Une restauration, un changement de version, une mise à niveau de module ou un nettoyage de filestore peut transformer les références. Cette chronologie permet de séparer l'incident initial des effets d'une tentative de reprise.
- Arrêt
- Stopper services et cron
- Base
- À préserver: PostgreSQL et WAL
- Fichiers
- À garder ensemble: filestore et modules
- Validation
- À contrôler: pièces et périodes
Prise en charge
Rassembler la base et le filestore Odoo à Annonay
Cette page répond aux demandes provenant d'Annonay sans déclarer de laboratoire local. Elle précise la préparation du dossier et son orientation vers le laboratoire; la méthode dépend des supports, de la version, des accès autorisés et du diagnostic réalisé avant le devis.
Laissez les services et stockages hors ligne après l'incident. Étiquetez serveurs, disques, LUN, volumes et rôles. Joignez les informations utiles: versions Odoo, PostgreSQL et système, erreurs, topologie, chemins de données et chronologie des restaurations ou mises à niveau déjà tentées.
Cohérence base-filestore
Relier PostgreSQL, pièces jointes et modules
Le périmètre utile inclut le cluster PostgreSQL, les fichiers WAL, les sauvegardes logiques, le filestore, les pièces jointes, les modules, la configuration, les secrets autorisés, les certificats, les journaux, les exports, les instantanés et les sauvegardes. Chaque composant garde sa provenance afin de comparer les générations sans les confondre.
Une base récente peut référencer des fichiers absents, tandis qu'un ancien filestore conserve des documents encore exploitables. Les identifiants, les sommes de contrôle, les tailles, les dates et les journaux guident le rapprochement; le nom du fichier seul ne suffit pas à retrouver son enregistrement.
- Base À conserver: PostgreSQL, catalogues et WAL disponibles.
- Fichiers À préserver: filestore, documents et sommes de contrôle.
- Modules À garder ensemble: code personnalisé et versions.
Carte
Orientation à Annonay selon l'application et le stockage
FAQ
Questions fréquentes sur Odoo et la récupération
Faut-il redémarrer Odoo pour vérifier les données?
Non sur la source. Le démarrage peut lancer cron, migrations ou écritures. La base et le filestore sont d'abord acquis, puis un essai éventuel utilise une copie isolée.
Un export logique PostgreSQL suffit-il à restaurer Odoo?
Pas toujours. Les pièces jointes résident souvent dans le filestore, et des modules ou secrets peuvent manquer. L’export logique doit être rapproché de ces dépendances.
Pourquoi conserver les WAL disponibles?
Ils peuvent préciser la chronologie PostgreSQL ou compléter une branche de reprise. Ils sont classés avec la base et ne sont jamais rejoués directement sur la source.
Les modules personnalisés sont-ils importants?
Oui. Ils peuvent définir des champs, tables et traitements nécessaires à l'interprétation. Leur version et leur configuration doivent rester associées à la base.
La sauvegarde la plus récente est-elle prioritaire?
Non systématiquement. Elle peut omettre le filestore ou suivre une migration incomplète. Images brutes, snapshots et fichiers sont comparés avant sélection.
Diagnostic et devis
Faire qualifier les dépendances avant reprise
Décrivez les versions, les volumes, la base, le filestore, les modules, les sauvegardes, les secrets autorisés, les symptômes et les opérations déjà tentées. Ces éléments cadrent les acquisitions et les scénarios de reconstruction, puis permettent d'établir le devis sans préjuger des données récupérables.