Perte de données sur un Disque externe sur un windows server 2012 R2

Bonjour à nouveau esdras yaloula,

Je fais un suivi pour m'assurer que vous avez résolu le problème. Pour récapituler, vous devez immédiatement isoler la station de travail de l'utilisateur du réseau afin d'empêcher l' __ agent Fichiers hors__ ligne de se synchroniser et potentiellement de remplacer le cache local (C:\Windows\CSC). En même temps, concernant le lecteur serveur, évitez strictement de l'exécution chkdsk tant que vous n'avez pas créé un clone brut, secteur par secteur ; le système de fichiers pointe actuellement vers une ancienne transaction MFT (2023), et les outils de réparation standards peuvent supprimer définitivement les données « non indexées » de 2024–2026 comme espace libre. Veuillez confirmer si vous avez sécurisé avec succès l'image médico-légale ou si vous avez besoin d'une syntaxe spécifique pour extraire les fichiers du cache CSC du client.

Si le problème a été résolu avec succès, merci d'envisager d'accepter la réponse car cela aide aussi d'autres personnes partageant la même question. Merci!

Vice-président

Bonjour esdras yaloula,

Cela ressemble à un échec critique de la table de fichiers maîtresse NTFS (MFT) combiné à une mauvaise compréhension du comportement de mise en cache côté client Windows. L'utilisation d'une clé USB externe comme partage réseau principal sur Windows Server 2012 R2 est très instable pour la production car les contrôleurs USB ne respectent généralement pas les commandes strictes de Flush File Buffers requises par NTFS pour l'intégrité transactionnelle, notamment en cas de coupure de courant ou de suppression dangereuse. Le phénomène où le disque montre des données de 2023 indique que la MFT a été corrompue ou est revenue à un état antérieur ; essentiellement, le cache d'écriture en mémoire et le journal NTFS ($LogFile) n'étaient probablement pas engagés sur le disque lors de son débranchement, ce qui a conduit le système de fichiers à monter une version plus ancienne et cohérente de la table d'allocation des fichiers pointant vers les anciennes données. Les données « récentes » existent physiquement sur le plateau dans « l'espace libre » mais ne sont pas actuellement indexées.

L'incident de données « fantôme » que vous avez décrit, où un utilisateur a vu des fichiers récents après que vous ayez débranché le disque, est la preuve la plus cruciale et votre meilleur espoir de récupération. Puisque le disque physique était déconnecté du serveur, cet utilisateur consultait sans aucun doute la __ base de données Windows Offline Files (Client-Side Caching)__ stockée localement sur sa propre station de travail, généralement située à C:\Windows\CSC. Les clients Windows mettent automatiquement en cache les partages réseau si la fonction « Fichiers hors ligne » est activée (ce qui est souvent par défaut). Lorsque le disque serveur s'est mis hors ligne, la machine cliente basculait sans interruption vers ce cache local. Les données ont disparu plus tard parce que le client a probablement tenté de se resynchroniser avec le serveur (que vous aviez brièvement reconnecté ou remplacé par la copie interne), a détecté un décalage de version ou un état « serveur plus récent » (même si le serveur était en réalité plus ancien), et a invalidé son cache local.

Pour récupérer ces données, vous devez immédiatement isoler la station de travail de l'utilisateur spécifique qui a vu les fichiers. Ne le connectez pas au réseau. Vous devez essayer d'extraire les données du dossier CSC de ce client. Des outils comme CSCCMD (dépassés mais utiles) ou accéder au cache via l'interface du Centre de synchronisation en étant strictement hors ligne pourraient vous permettre de copier ces fichiers dans un dossier local. Pour le disque serveur externe lui-même, ne lancez pas encore Chkdsk. Chkdsk interprète les incohérences du système de fichiers comme des erreurs et peut les « corriger » en supprimant les fragments de fichiers orphelins qui constituent vos données récentes. Vous devez d'abord créer une image brute, secteur par secteur, du disque externe à l'aide d'un outil comme dd un logiciel d'imagerie médico-légale équivalent pour un volume de stockage sain. Ce n'est qu'après avoir une image sécurisée que vous devez lancer chkdsk X: /f /r (en remplaçant X par la lettre du lecteur) sur le disque d'origine pour tenter de réparer le MFT. Si Chkdsk ne restaure pas l'index récent, vous devrez exécuter un logiciel professionnel de récupération de données (comme R-Studio ou GetDataBack) sur l' image disque que vous avez créée, en scrutant spécifiquement les « Fichiers perdus » ou les signatures brutes de fichiers, car la table des fichiers ne pointe probablement plus vers les secteurs de données 2024-2026.

Si vous avez d'autres questions, n'hésitez pas à laisser un message. Bonne journée!

Vice-président