Récupérer une base SQLite corrompue : copies, fichiers WAL et outils natifs

Traitez la récupération SQLite comme une récupération de données contrôlée

Pour récupérer une base de données SQLite corrompue, conservez une copie cohérente de la base de données et de ses fichiers journaux associés, puis comparez les sauvegardes existantes avant d’utiliser les outils de récupération natifs. Ne commencez pas par supprimer un fichier WAL ou par exécuter des commandes de nettoyage sur la seule source. La première étape correcte dépend si le problème est une corruption, des transactions validées manquantes, une base de données verrouillée ou une application qui attend un schéma différent.

Les outils natifs de SQLite peuvent extraire des données utiles, mais une base de données récupérée nécessite toujours des vérifications structurelles et applicatives. Un fichier qui s’ouvre peut contenir des enregistrements manquants, dupliqués ou modifiés. Par conséquent, séparez l’extraction réussie de l’acceptation du résultat. Ce guide se concentre sur les copies de travail, les sauvegardes existantes, l’état WAL préservé et la récupération native plutôt que de promettre une reconstruction parfaite de chaque fichier endommagé.

Établir une source de récupération cohérente

Empêchez l’application d’écrire dans la base de données concernée via son processus d’arrêt ou de maintenance normal, le cas échéant. Si la base de données doit rester active, utilisez une méthode de sauvegarde cohérente prise en charge plutôt que de copier un fichier en constante évolution au coup par coup. Enregistrez l’application, le chemin de la base de données, l’environnement SQLite et l’erreur exacte. Conservez ensuite la source avant de l’ouvrir avec des outils susceptibles de modifier l’état du journal.

Conservez les side-cars de base de données correspondants existants avec la source, en particulier un fichier WAL lorsqu’il est présent. Ne combinez pas une base de données d’une époque avec un WAL copié à partir d’un autre état sans rapport. Une sauvegarde ou un instantané de stockage cohérent est préférable à une copie occasionnelle de fichiers en direct. Conservez également une copie distincte intacte afin que chaque expérience de récupération démarre à partir de preuves connues plutôt que du résultat de la tentative précédente.

Voie gratuite 1 : valider une sauvegarde cohérente existante

1. Recherchez une sauvegarde existante prise en charge par l’application ou cohérente avec SQLite avant l’échec.
2. Restaurez-le dans un répertoire de test distinct plutôt que sur la base de données de production.
3. Ouvrez-le avec l’application appropriée ou l’environnement SQLite et exécutez des vérifications structurelles.
4. Comparez les enregistrements importants et le comportement des applications avant de les sélectionner comme référence de récupération.

Une sauvegarde existante peut être plus fiable que la récupération de pages endommagées, mais son âge compte. Comparez ses derniers enregistrements attendus avec l’heure d’interruption. Identifiez ensuite les transactions ultérieures manquantes. Une base de données propre d’hier peut être utile sans être suffisamment à jour pour la tâche prévue. Conservez la source endommagée tout en évaluant si des données valides plus récentes peuvent être récupérées séparément.

Vérifiez l’identité réelle de la sauvegarde

Inspectez les tables attendues et un petit ensemble d’enregistrements connus. Comparez également toute version d’application ou métadonnées de schéma utilisées par le logiciel. Un fichier avec la bonne extension peut appartenir à un autre profil ou à une version plus ancienne de l’application. Ne laissez pas l’application migrer la seule sauvegarde avant de la conserver, car la migration peut modifier la structure que vous souhaitiez évaluer.

S’il existe plusieurs candidats de sauvegarde, enregistrez leur provenance et leurs jalons de contenu. Par exemple, notez si une importation terminée spécifique ou un enregistrement modifié apparaît. Les délais de modification des dossiers permettent de trier les candidats mais ne permettent pas d’établir l’intégralité des transactions. Le contenu réel de la base de données et les attentes de l’application déterminent si la sauvegarde constitue une référence appropriée.

Route gratuite 2 : préserver un état WAL correspondant

1. Conservez un ensemble cohérent contenant la base de données et ses fichiers side-car correspondants existants.
2. Conservez un ensemble source intact et créez un ensemble de travail distinct pour inspection.
3. Ouvrez l’ensemble de travail dans un environnement SQLite approprié sans supprimer ni remplacer son WAL.
4. Vérifiez les enregistrements validés attendus et créez une nouvelle sauvegarde cohérente de tout résultat utilisable.

Un WAL fait partie de l’état persistant de la base de données lorsqu’il contient des transactions pertinentes. Le séparer de la base de données peut perdre les modifications validées ou produire un résultat incohérent. Cependant, trouver un WAL ne signifie pas automatiquement qu’il contient les enregistrements manquants. La base de données et WAL doivent aller ensemble et le résultat nécessite toujours une validation. N’attachez pas un WAL sans rapport simplement parce que son nom de base semble similaire.

N’utilisez pas le nettoyage du journal comme première réparation

Supprimer des side-cars, forcer un point de contrôle ou changer de mode de journal peut modifier des preuves utiles. Conservez l’état d’origine avant d’envisager de telles opérations et utilisez le processus pris en charge par l’application si nécessaire. Une erreur de verrouillage ou d’occupation ne prouve pas non plus une corruption. Déterminez si un autre processus détient toujours la base de données avant d’essayer de reconstruire son contenu.

Travaillez sur un répertoire séparé où vous pouvez suivre les fichiers modifiés par SQLite lors de l’ouverture. Comparez ensuite les données logiques avec l’état attendu. Si l’ensemble de travail devient utilisable, créez une sortie cohérente appropriée plutôt que de copier uniquement un fichier sélectionné pendant que les connexions restent actives. Cela préserve une frontière claire entre la preuve source et une base de données récupérée acceptée.

Route gratuite 3 : exécutez la récupération native de SQLite sur une copie

1. Obtenez un shell de ligne de commande SQLite officiel qui fournit la fonctionnalité .recover.
2. Ouvrez une copie de travail de la base de données endommagée dans le shell.
3. Sortie directe de .recover vers un nouveau fichier SQL, en préservant la base de données d’origine inchangée.
4. Lisez ce SQL dans une nouvelle base de données distincte et enregistrez toutes les erreurs signalées.

Pour un exemple interactif, démarrez sqlite3 avec une base de données copiée nommée working.db. Dans ce shell, utilisez .output recovered.sql, puis .recover, puis .output stdout et enfin .quit. Ce sont des commandes distinctes saisies une par une. Ensuite, démarrez sqlite3 avec une nouvelle destination nommée recovered.db et utilisez .read recovered.sql. Choisissez les noms de sortie inutilisés afin qu’une tentative de récupération antérieure reste disponible à des fins de comparaison.

Examiner le résultat de récupération avant acceptation

La récupération native tente d’extraire le contenu utilisable des structures endommagées. Il peut également restaurer du matériel précédemment supprimé ou placer des enregistrements incertains dans un tableau des objets trouvés. Par conséquent, examinez sa sortie et ses erreurs plutôt que de traiter une commande terminée comme une preuve d’exactitude. Conservez la sortie SQL et les notes à côté de la base de données récupérée afin de pouvoir retracer ce que le processus de récupération a fourni.

Pour les données confidentielles ou sensibles aux applications, n’importez pas un résultat de récupération directement dans le service en direct. Testez-le séparément avec des enregistrements et des relations représentatifs. La réapparition de lignes supprimées ou de valeurs modifiées peut être importante même lorsque la base de données réussit une vérification structurelle. La décision d’acceptation appropriée dépend de la signification des données, et pas seulement du fait qu’une requête renvoie des résultats.

Voie gratuite 4 : exporter du contenu lisible de manière sélective

1. Ouvrez uniquement une copie de travail avec un outil SQLite approprié.
2. Identifiez les tables ou requêtes qui restent lisibles sans erreurs.
3. Exportez les enregistrements utiles avec leurs définitions de colonnes et les relations pertinentes documentées.
4. Importez-les dans une base de données de reconstruction distincte et validez le résultat.

L’exportation sélective peut être utile lorsqu’une récupération complète produit trop d’incertitude ou qu’une zone endommagée empêche une utilisation normale. Cependant, il peut omettre des contraintes, des index, des déclencheurs, des vues ou des lignes illisibles. Gardez cette portée explicite. Un CSV contenant certains enregistrements constitue une récupération de données utile, mais il ne s’agit pas d’une restauration complète de la base de données d’origine de l’application.

Préserver les types et les relations

L’exportation de texte peut modifier la façon dont les valeurs sont représentées, en particulier pour les valeurs NULL, les champs binaires, les dates et les identifiants numériques. Enregistrez le schéma d’origine et inspectez le comportement d’importation. Comparez également les relations de clé primaire et étrangère, le cas échéant. Un tableau lisible peut devenir trompeur si ses identifiants ne se connectent plus aux enregistrements associés dans un autre tableau.

Par exemple, les pièces jointes récupérées peuvent nécessiter des lignes de métadonnées identifiant les éléments qui leur appartiennent. La récupération uniquement des noms de fichiers joints peut laisser un dossier de fichiers non attribués. Conservez les preuves de relation et comparez-les avec les enregistrements connus. Si vous ne parvenez pas à établir une connexion fiable, étiquetez ces éléments comme incertains plutôt que d’inventer des associations pour donner l’impression que la demande est complète.

Exécutez des vérifications structurelles sur la copie récupérée

Utilisez PRAGMA integrity_check; dans l’environnement SQLite approprié pour évaluer la cohérence structurelle de la base de données récupérée. Utilisez ensuite PRAGMA foreign_key_check; lorsque les relations de clé étrangère sont pertinentes. Enregistrez les résultats réels et les éventuelles erreurs. Ces vérifications répondent à différentes questions, et la réussite d’une telle vérification ne garantit pas que toutes les règles métier ou applicatives sont valables.

Ajouter des contrôles qui correspondent à la signification des données

Comparez le nombre de tables attendu, les identifiants importants et les valeurs d’enregistrement représentatives avec des preuves externes fiables. Testez également les jointures et les workflows d’application qui reposent sur les relations entre les tables. Une base de données peut être cohérente en interne tout en manquant une importation récente complète. À l’inverse, un nombre de lignes inattendu peut refléter la réactivation du matériel supprimé plutôt qu’une récupération réussie de l’état actuel prévu.

Vérifiez le codage du texte, le contenu binaire et les valeurs requises dans un exemple qui couvre les principaux types de données de l’application. Inspectez ensuite les cas limites pertinents, tels que les derniers enregistrements avant la panne. Cela rend l’acceptation plus significative que l’exécution d’une seule requête sur une table pratique et l’hypothèse que le reste de la base de données se comporte de la même manière.

Distinguer la corruption d’un environnement incompatible

Une application peut rejeter une base de données valide car elle attend un autre schéma, une extension requise ou un format chiffré. Enregistrez l’environnement exact et l’erreur avant de sélectionner un outil de récupération. Un shell SQLite générique ne peut pas nécessairement lire une base de données nécessitant une implémentation de chiffrement spécifique. Changer le nom du fichier ou exécuter récupération à plusieurs reprises ne fournira pas la clé ou l’extension manquante.

Séparez la migration des applications

Si une application plus récente propose une migration, conservez d’abord la source et testez la migration sur un candidat distinct. Comparez ensuite le schéma obtenu et les enregistrements importants. Une migration peut réussir tout en modifiant les comportements, elle mérite donc son propre contrôle d’acceptation. Ne confondez pas un fichier nouvellement migré avec une base de données historique récupérée intacte.

Examinez également les problèmes d’accès ordinaires tels que les autorisations, le stockage indisponible ou un autre processus détenant un verrou. Ceux-ci peuvent empêcher l’ouverture sans impliquer une corruption de la page. Résolvez le problème d’accès spécifique de la manière normale prise en charge. La reconstruction d’une base de données valide pour résoudre un problème de chemin ou d’autorisation ajoute une incertitude inutile aux données qui peuvent déjà être intactes.

Une récupération réussie pour un catalogue local endommagé

Supposons qu’un catalogue local signale une erreur de base de données après une écriture interrompue. Conservez un ensemble de sources cohérent et comparez d’abord la dernière sauvegarde prise en charge. Identifiez si la sauvegarde contient les éléments importants les plus récents. Si ce n’est pas le cas, exécutez une récupération native sur une copie candidate endommagée distincte et inspectez les enregistrements récupérés plutôt que de remplacer le catalogue immédiatement.

Rapprochez soigneusement les enregistrements valides

La sauvegarde peut fournir un schéma propre et des enregistrements anciens stables, tandis que la récupération fournit des entrées récentes. Comparez les identifiants et les tables associées avant toute fusion. N’ajoutez pas aveuglément chaque ligne récupérée, car le contenu supprimé ou dupliqué peut réapparaître. Créez un résultat de test distinct et enregistrez les données provenant de la sauvegarde et celles provenant d’une récupération incertaine.

Ouvrez ensuite le résultat dans un profil d’application de test et exercez des flux de travail représentatifs. Vérifiez l’affichage des éléments, la recherche, l’accès aux pièces jointes et la modification, le cas échéant. Gardez les preuves sources et les candidats rejetés séparés. Un lancement réussi n’est qu’une partie de l’acceptation ; l’application doit également utiliser correctement les relations et le contenu récupérés.

Évitez les expériences destructrices sur la seule source

Ne commencez pas par VACUUM, des réécritures de schéma ou des commandes de nettoyage sur l’original endommagé. De telles opérations peuvent modifier des pages ou supprimer des informations qu’une autre tentative de récupération pourrait utiliser. Conservez l’original et utilisez une nouvelle copie de travail pour chaque approche distincte. Conservez le résultat des commandes et les noms des candidats afin qu’une expérience échouée ne devienne pas une nouvelle référence inexpliquée.

Connaître les limites de la récupération de pages

Les pages manquantes ou écrasées peuvent rendre certaines informations définitivement indisponibles. La récupération native peut également récupérer des valeurs sans suffisamment de contexte pour identifier de manière fiable leur table d’origine. Énoncez ces lacunes au lieu de les combler de suppositions. Un ensemble de données vérifiées plus petit peut être plus utile qu’un résultat plus volumineux dont les enregistrements ne peuvent pas être fiables ou associés correctement.

Si la base de données prend en charge des décisions opérationnelles importantes, demandez au propriétaire des données responsable de revoir les critères d’acceptation. Les contrôles techniques établissent la lisibilité et la cohérence, tandis que le propriétaire peut comparer le contenu avec les documents réels qu’il représente. Il s’agit d’une division pratique du travail de vérification, et non d’une raison pour prétendre qu’une base de données structurellement propre doit être exacte.

Définir l’acceptation au niveau de l’enregistrement avant de fusionner la récupération

Choisissez des enregistrements représentatifs qui établissent si la base de données récupérée contient l’état prévu. Incluez un enregistrement plus ancien connu, un enregistrement récent et une relation impliquant une autre table. Comparez ensuite leurs valeurs avec des preuves d’application fiables. Cela transforme une vague affirmation de récupération réussie en une vérification de contenu concrète et permet d’identifier une base de données d’apparence claire qui manque encore de transactions récentes importantes.

Comparez les identifiants et les valeurs ensemble

Un identifiant d’enregistrement familier ne garantit pas que ses valeurs associées ont survécu correctement. Inspectez le texte important, les champs numériques, les valeurs nulles et les références binaires, le cas échéant. Vérifiez ensuite les lignes associées. Un enregistrement parent peut survivre tandis que ses lignes enfants disparaissent, ou une ligne récupérée peut perdre la relation qui lui donne du sens. Séparez les associations incertaines plutôt que d’inventer des liens pour donner à l’affichage de l’application un aspect complet.

Lors du rapprochement d’une sauvegarde propre avec des lignes récentes récupérées, documentez la source de chaque groupe importé. Comparez les clés avant l’insertion et inspectez les doublons potentiels. Ne présumez pas que tous les enregistrements absents de la sauvegarde sont de nouveaux enregistrements valides ; la récupération peut faire revivre le contenu précédemment supprimé. Une fusion contrôlée doit préserver la ligne de base propre et créer un résultat de test distinct que vous pouvez inspecter avant de remplacer une base de données fonctionnelle.

Examiner les objets de schéma ainsi que les lignes du tableau

Une base de données d’application utilisable peut s’appuyer sur des index, des vues, des déclencheurs, des contraintes et des métadonnées en plus des enregistrements visibles. Inventoriez le schéma attendu dans une sauvegarde connue ou une référence d’application prise en charge. Comparez ensuite le candidat récupéré. Les objets de schéma manquants peuvent provoquer des erreurs ou modifier le comportement même lorsqu’une simple requête de table réussit. Enregistrez donc les différences avant de tester l’application.

Distinguer un index manquant des données logiques manquantes

Certains dommages peuvent affecter les structures d’accès sans détruire tous les enregistrements sous-jacents, tandis que d’autres dommages suppriment le contenu lui-même. Ne déduisez pas la portée d’un seul message d’erreur. Inspectez les résultats de vérification natifs et comparez les données lisibles sur une copie de travail. Toute action de reconstruction doit avoir une cible claire et une source préservée, car une vaste réécriture peut modifier les preuves sans résoudre le problème d’application réel.

Inspectez également les métadonnées de l’application qui identifient la version du schéma ou la propriété du profil. Une base de données techniquement valide provenant d’un autre profil peut ne pas convenir même si ses noms de table correspondent. Conservez le contexte attendu de l’application dans le dossier d’acceptation. Cela évite de promouvoir un candidat structurellement propre mais sémantiquement erroné simplement parce qu’il s’ouvre dans un navigateur SQLite générique.

Interprétez le contenu perdu et trouvé avec prudence

La récupération native peut extraire des enregistrements qu’elle ne peut pas associer en toute confiance à leur table d’origine. Conservez cette sortie, mais ne l’insérez pas immédiatement dans une table comportant un nombre similaire de colonnes. Comparez les types, les identifiants et le contenu connu, et isolez les lignes incertaines. Le contexte structurel manquant peut être aussi important que les valeurs récupérées elles-mêmes.

Enregistrer l’incertitude à la plus petite portée utile

Vous pourrez peut-être vérifier un élément récupéré tout en laissant un autre non résolu. Gardez ces décisions séparées. Par exemple, un corps de note reconnaissable peut être utile pour récupérer du texte même lorsque sa relation de dossier d’origine ne peut pas être établie. Étiquetez-le en conséquence plutôt que de l’attribuer à un emplacement inventé. Cela préserve les informations précieuses sans transformer l’incertitude en un état d’application trompeur.

Si le propriétaire des données peut comparer la récupération avec des enregistrements faisant autorité, fournissez une liste de candidats claire et les détails de la source pertinents. Conservez la sortie SQL intacte et les copies de la base de données comme preuve. Un examen ultérieur pourrait résoudre une association qui n’est pas claire à l’heure actuelle, et la préservation des éléments bruts de récupération empêche qu’une décision précoce de reconstruction ne devienne la seule interprétation restante.

Testez l’application dans un profil ou un espace de travail distinct

Après les vérifications structurelles, utilisez un environnement de non-production pris en charge pour inspecter la base de données récupérée. Exercez les flux de travail de lecture et de modification représentatifs, puis comparez les enregistrements résultants. Cela répond aux attentes qu’une vérification SQLite générique ne peut pas exprimer, telles que les métadonnées requises ou les relations imposées par la logique de l’application. Gardez les modifications de l’environnement de test séparées du candidat de récupération accepté.

Inspecter le comportement après la réouverture

Fermez normalement l’application de test et rouvrez le même candidat. Ensuite, inspectez à nouveau les enregistrements importants. Certains problèmes apparaissent uniquement lorsque l’application enregistre l’état, reconstruit un cache ou recharge les relations. Un seul lancement réussi est donc un test d’acceptation incomplet. Enregistrez tout nouvel avertissement et comparez l’état de la base de données avant de décider si le candidat est prêt à continuer à l’utiliser.

Enfin, créez une sauvegarde cohérente prise en charge du résultat accepté et testez cette sauvegarde de manière indépendante. Conservez séparément la source endommagée d’origine, les side-cars correspondants, les résultats de récupération et les notes d’acceptation. Si la récupération reste partielle, identifiez clairement les enregistrements manquants ou incertains. Cela vous donne une base opérationnelle fiable tout en préservant les preuves nécessaires à toute reconstruction ultérieure ou enquête spécialisée.

Séparez la récupération de fichiers de l’acceptation de la transaction

Un nom de fichier de base de données récupéré est une entrée pour une évaluation logique, et non une déclaration selon laquelle chaque transaction a survécu. Comparez les enregistrements et les relations réels qui définissent l’état prévu de l’application. Enregistrez ensuite quels tests ont réussi et quelles lacunes subsistent. Cette distinction est particulièrement utile lorsqu’une analyse de fichier fournit à plusieurs candidats des dates plausibles mais des contenus différents ou un contexte side-car incomplet.

Préserver les étapes de récupération reproductibles

Utilisez une nouvelle copie de travail pour chaque approche de récupération distincte et enregistrez les noms de sortie. Conservez la version de l’outil et les options pertinentes avec les résultats. Comparez ensuite les candidats en utilisant les mêmes vérifications au niveau des dossiers. Cela rend l’enquête reproductible et évite qu’une amélioration apparente ne dépende d’un changement non documenté effectué lors d’une précédente tentative infructueuse.

Si vous choisissez finalement une sauvegarde plus ancienne et propre plutôt qu’un résultat de récupération plus important, indiquez pourquoi. Les relations vérifiées et le contenu connu peuvent être plus utiles que des lignes incertaines supplémentaires. Conservez la récupération séparément pour un examen ultérieur plutôt que de forcer chaque valeur extraite dans la base de données acceptée. Cela vous donne une base de référence fiable tout en conservant des informations potentiellement précieuses qui nécessitent encore une interprétation.

Quand la récupération de fichiers supprimés peut aider les données SQLite

PandaOffice Drecov est pertinent lorsqu’une base de données enregistrée, correspondant à un fichier journal existant ou une sauvegarde cohérente a été supprimée du stockage accessible. Il ne remplace pas les outils de récupération logique de SQLite et ne recrée pas les transactions écrasées. Réduisez également les écritures sur le stockage concerné. Si l’appareil lui-même signale des échecs de lecture répétés, évaluez cette condition avant d’exécuter une analyse de routine des fichiers supprimés.

Étape 1 : identifier le stockage de la base de données d’origine

Choisissez le lecteur ou la partition contenant la base de données de l’application et son emplacement de sauvegarde réel. Enregistrez le nom de base d’origine et tous les side-cars qui existaient avec celui-ci. Conservez la sortie de récupération sur un autre stockage sain. Évitez de lancer l’application sur l’emplacement concerné simplement pour générer une autre erreur, car cela pourrait créer de nouveaux fichiers ou modifier l’état du journal survivant.

Étape 2 : collecter des candidats cohérents dans une base de données

Passez en revue les noms, chemins, tailles et dates disponibles pour la base de données et les fichiers associés. Préservez plusieurs candidats plausibles sans combiner des versions sans rapport. Une analyse ne peut pas établir une cohérence transactionnelle à partir d’un seul nom de fichier. Conservez les détails de la source et traitez les ensembles de base de données et side-car récupérés comme des candidats nécessitant une validation SQLite et une application par la suite.

Étape 3 : récupérer ailleurs et valider le contenu logique

Restaurez les fichiers sélectionnés vers une destination distincte, conservez un ensemble récupéré intact et inspectez une autre copie de travail. Comparez les sauvegardes existantes, exécutez des vérifications ou des récupérations natives appropriées et testez les enregistrements et les relations importants. Ne renvoyez pas une récupération non validée directement au service. Un nom de fichier complet et une restauration de fichier réussie ne prouvent pas que les transactions prévues ont survécu.

Documenter la base de données acceptée et l’incertitude restante

Enregistrez le candidat source, les outils, les commandes, les erreurs, les vérifications et les tests d’application utilisés pour le résultat accepté. Gardez la base de données récupérée séparée de la sortie de récupération SQL et des preuves originales. Créez ensuite une sauvegarde cohérente prise en charge de l’état vérifié. Cela donne à la prochaine tâche de maintenance une base de référence fiable au lieu d’un ensemble de copies de base de données ambiguës.

Testez les futures sauvegardes en tant que restaurations réelles

Utilisez un exemple hors production pour tester la procédure de sauvegarde et de restauration de l’application. Vérifiez que la sortie s’ouvre indépendamment et contient les enregistrements récents attendus. Documentez également comment l’application utilise WAL et où appartient sa sauvegarde. Un test de restauration pratique fournit la preuve que la protection fonctionne, tandis que la simple copie d’un nom de fichier de base de données visible peut ignorer une partie de son état persistant.

Si certains enregistrements restent manquants ou incertains, répertoriez-les explicitement. Une récupération partielle peut toujours permettre de récupérer des informations précieuses, mais elle ne doit pas devenir une revendication sans réserve de restauration complète. Des limites claires vous aident à décider s’il faut reconstruire à partir d’autres enregistrements faisant autorité, conserver le résultat pour référence ou poursuivre une enquête spécialisée.

Ressources de récupération associées

Explorez les options de récupération pertinentes : Récupération du disque dur, Récupération de disque dur externe.

Pour un autre cas de récupération et ses vérifications pratiques, lire le guide de récupération associé.

Consultez les instructions du fournisseur pour la version installée : documentation officielle de récupération 1, documentation officielle de récupération 2, documentation officielle de récupération 3, documentation officielle de récupération 4.