Forum Linux.général Récupérer un fichier en mode (deleted) sur un instantané ZFS

Posté par  . Licence CC By‑SA.
Étiquettes : aucune
5
7
juin
2017

Bonjour,

J'ai une colle dont je n'arrive pas à trouver la réponse.
Google ne me donne rien. J'ai posé la question sur un des sites StackExchange, sans réponse utile pour l'instant.

J'ai un volume ZFS monté dans le dossier /srv/chemin/
Un instantané ZFS est conservé chaque jour.
Il y a plusieurs jours, un gros fichier du volume ZFS (disque virtuel) a été effacé pour je ne sais quelle raison. Il est toujours en cours d'utilisation, visible via lsof et marqué (deleted).
Je peux facilement récupérer ce fichier en mettant la machine virtuelle en pause puis en faisant cp /proc/<pid>/fd/21 monfichier.bak.

Mais je n'ai pas besoin de la version actuelle, c'était trop facile. J'ai besoin d'une version qui date d'il y a 2 jours.
Comme le fichier a été effacé, il n'est pas dans les sauvegardes récentes.
Mais comme il n'est pas « vraiment effacé » je me dis qu'il est quelque part sur les instantanés car les blocs de données sont toujours sur le disque, les instantanés sont sensés tenir compte de cela. Ça reste une supposition, car rien ne me prouve pour l'instant que les instantanés fonctionnent bien comme je l'imagine dans ce cas précis.
En tous cas je n'ai rien dans /srv/chemin/.zfs/snapshot/xxxx

Quelqu'un a une idée sur la possibilité de récupération, et la manière de faire ?

  • # mount !

    Posté par  . Évalué à 2.

    Suffit de monter ton snapshot…
    Pour la liste
    zfs list -t snapshot

    Après à voir si tu préfères pas directement un rollback ou le cloner

    • [^] # Re: mount !

      Posté par  . Évalué à 2.

      Tu as lu trop vite :

      je n'ai rien dans /srv/chemin/.zfs/snapshot/xxxx

      • [^] # Re: mount !

        Posté par  . Évalué à 2.

        lsof DELETED => fichier plus present
        mais inode toujours utilisé

        sauf si le filesystem propose une fonction undelete, tu ne pourras pas le ressortir.

        tu pourras le restaurer à partir d'un snapshot precedent

        En tous cas je n'ai rien dans /srv/chemin/.zfs/snapshot/xxxx

        alors essaie dans le snapshot d'avant, et encore avant
        c'est normalement le but du snapshot, c'est de revenir voir en arriere ce qu'il y avait à l'epoque.

        il te faudra eteindre la VM, puis copier le fichier du snapshot/zzzz ou snapshot/tttt dans le snapshot/current
        et relancer la VM

        • [^] # Re: mount !

          Posté par  . Évalué à 3.

          Comme je l'imaginais, les données sont récupérables.
          Et récupérées, ce qui m'importe.

          J'ai trouvé des informations utile ici : http://cuddletech.com/?p=407
          Ensuite j'ai fait des tests avec des fichiers de taille raisonnable.

          • [^] # Re: mount !

            Posté par  . Évalué à 2.

            sympa mais attention

            Also, notice that the original file was 21 bytes, but the “recovered” file is 512… its been padded, so if you recovered a file and tried using an MD5 hash or something to verify the content it wouldn’t match, even though the data was valid. In other words, the best “undelete” option is snapshots.. they are quick, easy, use them.
            Using zdb for file recovery isn’t practical.

            • [^] # Re: mount !

              Posté par  . Évalué à 4.

              In other words, the best “undelete” option is snapshots.. they are quick, easy, use them. Using zdb for file recovery isn’t practical.

              Tu remarque que c'est justement parce que le fichier n'était pas visible dans le snapshot (bien que présent) qu'il a utilisé cette technique.

              « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

            • [^] # Re: mount !

              Posté par  . Évalué à 2.

              sympa mais attention

              Les données ont été récupérées. Donc attention à rien du tout :-)

Suivre le flux des commentaires

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