Nos prestations
Réparation matérielle Maintenance serveurs Récupération de données Mise à niveau & upgradePar constructeur
Dell PowerEdge HPE ProLiant Lenovo ThinkSystem Fujitsu Primergy Supermicro IBM System x / Power Acer AltosIntervention & différenciateurs
Datacenter Lombardie Aruba Ponte San Pietro Au-delà du support constructeurReconstruction d'archives : les métadonnées avant les fichiers. Sans droits d'accès, l'archive ne fonctionne pas.
Après une panne de stockage, la donnée brute est récupérable, mais il faut reconstruire la structure : ACL, attributs étendus, liens, arborescence, ownership. Une archive documentaire sans métadonnées correctes n'est pas une archive fonctionnelle — c'est un simple ensemble de fichiers. Nous travaillons sur la partie du recovery que l'on néglige le plus souvent.
Récupérer les fichiers ne suffit pas.
Sur un serveur de fichiers, une archive documentaire ou un document management system, la structure autour des fichiers est aussi critique que les fichiers eux-mêmes :
- ACL Windows NTFS ou ACL POSIX Linux : qui peut lire/écrire quoi.
- Attributs étendus : classification, tags, métadonnées propres à certaines applications.
- Ownership : lien entre le fichier et l'utilisateur/groupe du système.
- Timestamps : création, modification, accès — souvent utilisés par les audits internes.
- Liens symboliques et hard links : relations entre fichiers, essentielles dans de nombreux applicatifs.
- Arborescence des dossiers : hiérarchie qui reflète les processus métier.
Un recovery « rapide » qui sauve seulement les octets mais perd ces métadonnées laisse une archive inexploitable tant que le travail n'est pas refait à la main.
Scénarios typiques.
- Après un recovery RAID : une fois la récupération de données byte-level effectuée, reconstruction des métadonnées.
- Migration de serveur de fichiers entre systèmes : préservation fidèle des ACL, de l'ownership et des timestamps.
- Corruption de filesystem récupérée : restauration de la logique du filesystem, au-delà de la restauration des fichiers isolés.
- Intégration avec un DMS (document management) : alignement entre métadonnées filesystem et métadonnées applicatives.
Ni « indexation », ni « saisie de données ».
Pour clarifier le périmètre : nous ne faisons pas de saisie manuelle de documents, nous n'effectuons pas d'OCR sur des numérisations, nous ne construisons pas de taxonomies applicatives. Notre périmètre est le niveau filesystem et infrastructure : la structure que le système d'exploitation utilise pour organiser et protéger les fichiers. Pour des reconstructions applicatives, il faut un partenaire DMS/ECM dédié.
Les questions qu'on nous pose le plus souvent.
Les métadonnées sont-elles toujours récupérées avec les fichiers ?
Lorsque le recovery est mené correctement au niveau filesystem, oui — c'est notre standard. Lorsque le recovery est mené en mode « carve » (extraction des fichiers depuis la matière brute sans reconstruction de la structure, typique des scénarios catastrophiques), les métadonnées doivent être reconstruites dans un second temps. On les récupère souvent depuis des sauvegardes partielles, des logs applicatifs ou des sources corrélées.
Les ACL Windows NTFS très complexes sont-elles récupérables ?
Oui, lorsque le filesystem est récupérable au niveau logique. La structure ACL NTFS (DACL, SACL, owner, SID) est préservée. Lorsque le domaine Active Directory a été modifié entre la panne et le recovery (utilisateurs supprimés, SID history modifié), il peut être nécessaire de mapper les anciens SID sur les nouveaux — une opération que nous gérons avec des scripts dédiés.
Le faites-vous aussi sur NAS Synology/QNAP ?
Oui. Les NAS Synology (Btrfs/ext4) et QNAP (Btrfs/ZFS/ext4) ont des modèles d'ACL/permissions spécifiques et leurs propres outils d'administration. Nous travaillons au niveau du filesystem natif, en préservant les ACL et les schémas de partage d'origine.