Forum Linux.débutant Vérification des données

Posté par  . Licence CC By‑SA.
Étiquettes : aucune
2
13
sept.
2017

Bonjour à tous,

Il y a t-il un moyen de vérifier si toutes mes données n'ont pas perdu de leur contenu ?

Je m'explique, si un jour un disque dur a eu des secteurs défectueux et que j'ai fait une copie des données présente sur le disque dur, alors j'aurais sur un disque propre et fonctionnel des données erronées.

Est-ce que ceci est transparant à nos yeux ? Il y a t-il un moyen de vérifier les données que l'on maintient depuis 10 ans à travers divers support amovible ou non ?

Fsck ?

Merci d'avance.

  • # afick ?

    Posté par  (site web personnel) . Évalué à 4.

    N'importe quel outil de type HIDS, qui fabrique une somme de contrôle sur une liste de fichier, et qui permet de vérifier que les checksum sont inchangés : tripwire, aide, afick ….

    • [^] # Re: afick ?

      Posté par  . Évalué à 2.

      Il y a aussi rhash qui supporte plein de formats de hachage dont CRC32 pour un simple controle d'intégrité sans volonté sécuritaire.

      Pour faire un fichier qui contient les sommes de controle MD5 de mon disque, je vais à sa racine et je fais :

      rhash -rMv --percents ./ > disque.sfv

      Puis pour vérifier je lance (toujours à la racine de la partition) :

      rhash -rcv disque.sfv

      Ensuite je regarde les erreurs avec une recherche du mot ERROR dans la sortie du terminal. Normalement il y en a une, c'est le fichier disque.sfv

      Le fait que ce soit dans un fichier permet de vérifier plusieurs sauvegardes en simultané sans refaire à chaque fois les calculs de somme de controle. Ça permet aussi de vérifier l'intégrité d'un archivage sans source de comparaison.
      On peut aussi ne vouloir vérifier qu'un dossier important de la partition, ça fonctionne de la même manière.

  • # facile pour les archives

    Posté par  . Évalué à 1.

    En l'absence de checksums, les fichiers d'archives (.zip, .tgz, .rar, bz2, …) peuvent être vérifiés avec l'archiveur correspondant.

  • # Bonjour

    Posté par  . Évalué à 2.

    Je m'explique, si un jour un disque dur a eu des secteurs défectueux et que j'ai fait une copie des données présente sur le disque dur, alors j'aurais sur un disque propre et fonctionnel des données erronées.

    Je peux me tromper mais je pense que ta copie aurait planté avec un message d’erreur. Sauf à avoir copié avec un dd conv=noerror …

    Cela dit un fichier corrompu ça peut exister (corrompu pendant le transfert via le réseau par exemple…) et la solution est effectivement de sauvegarder une « somme de contrôle » (checksum) de chaque fichier, ce qui permet de vérifier plus tard que les fichiers sont bien toujours les mêmes.

    $ md5sum /etc/hosts
a5b042f3cd2d60f7532ba967a7aeb054  /etc/hosts

    Si le fichier /etc/hosts était modifié, la commande md5sum renverrait une autre empreinte.

    • [^] # Re: Bonjour

      Posté par  . Évalué à 1.

      Okey merci pour vos réponses.

      • [^] # Re: Bonjour

        Posté par  . Évalué à 3.

        voir réponse ci dessous. Ta réponse n'est pas la bonne. Des octets peuvent se perdre soit sur les pistes magnétiques, soit sur l'interface SATA et dans une moindre mesure la mémoire, CPU.

        certains FS gèrent des checksums par fichier ou par block.

        • [^] # Re: Bonjour

          Posté par  . Évalué à 3.

          Je pensais que des systèmes de fichiers tels qu’Ext4 ou NTFS avait ce genre de protection. Ou, du moins, que le noyaux, via un firmware, était en mesure de détecter si un octet se « perdait » lors d’un transfert SATA ou d’une écriture sur disque…

          Merci d’avoir éclairé ma lanterne. Je suppose qu’un champ magnétique quelconque peut aussi éventuellement changer quelques octets et corrompre un fichier ?

          • [^] # Re: Bonjour

            Posté par  . Évalué à 2.

            Les corruptions sur la surface magnétique du disque même sont très rares car il y a un code correcteur d'erreur pour chaque secteur. Lorsqu'un secteur erroné est lu, il est corrigé et réécrit. Si l'erreur est trop grosse, le code correcteur d'erreur ne peut pas corriger, et la lecture retourne une erreur. Il reste le cas où l'erreur tombe pile de manière à ne pas être détectée.

            Le protocole SATA en relativement bien protégé par un code de détection d'erreur 32 bits, donc le trajet entre la mémoire (je suppose que c'est fait via DMA) et le disque est ok.
            On reste à exposé aux habituels problèmes dans le processeur, ou la mémoire de l'ordinateur, ou le processeur du disque-dur, ou sa mémoire.

  • # Système de fichier moderne

    Posté par  . Évalué à 4.

    Le mieux est d'utiliser un système de fichiers moderne comme ZFS ou Btrfs.
    Ces système de fichiers sauvegardent pour chaque fichier, une somme de contrôle pour vérifier l'intégrité du fichier. Cela permet donc de détecter des données corrompues et d'éventuellement de les corriger automatiquement.

    C'est bien expliqué ici :
    Bitrot and atomic COWs: Inside “next-gen” filesystems

    Attention, utiliser ces systèmes de fichiers est un peu plus délicat qu'utiliser un système de fichier classique.

  • # À tout hasard

    Posté par  . Évalué à 1.

    Essaies de jeter un œil à dmesg -w durant la simple lecture des fichiers (pour aller vite avec un truc du genre dd if=fichier of=/dev/null ou cat fichier>/dev/null).

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.