Journal Au secours !!! Perte de données !

Posté par  .
Étiquettes : aucune
0
8
fév.
2004
Après un redimensionnement avec l'outil mandrake,j'ai une partition ext3 qui a de gros problèmes.
fschk ne veut pas me la réparer, il me dit qu'il y a un problème de superblock.
Y'a mes tps sur cette partition, s'il vous plait filez moi un coup de pouce :-)
  • # Re: Au secours !!! Perte de données !

    Posté par  . Évalué à 0.

    Je ne pense que ca soit récupérable, vaut que tu sauvegardes tes données sur un autre disque dur, et formater dsl
    • [^] # Re: Au secours !!! Perte de données !

      Posté par  . Évalué à -2.

      T'as joué avec les partitions sans avoir sauvegardé ? mouhahaha !!!

      Sans rire, t'avais vraiment que ça à faire en sachant qu'il y avait des données importantes ?
      • [^] # Re: Au secours !!! Perte de données !

        Posté par  . Évalué à 3.

        On est d'accord sur un point, ce n'est pas malin (pour ne pas dire que c'est une connerie) de faire des changements sur la structure des disques / partitions sans faire de sauvegarde. Je crois que Ludovic s'en souviendra.

        Par contre, je trouve dommage que des gens puissent se moquer comme tu le fais en sachant qu'il a certainement perdu plusieurs heures/journées de travail.

        Par ailleurs, il serait plus intérressant de savoir quel outil mandrake a été utilisé, quelle opération a été effectuée, quels sont les erreurs actuelles, ... afin de faire un bug report à Mandrake et corriger le problème.

        Enfin, c'est mon avis, qui ne regarde que moi, et j'espère que tu ne perdes jamais des données de première importance, même si c'est en faisant une connerie.
        • [^] # Re: Au secours !!! Perte de données !

          Posté par  . Évalué à -4.

          La plus grosse connerie qui a failli me coûter mes données, c'est d'avoir utilisé ReiserFS.
          • [^] # Re: Au secours !!! Perte de données !

            Posté par  . Évalué à 1.

            J'adooooooooooooooore les gens à qui il arrive une merde, et qui la repande bien largement tout autour d'eux, histoire que la bonne odeur se propage :p

            Je suis sur qu'il y a des gens pour qui la plus grosse connerie a été d'utiliser XFS, d'autre JFS, d'autre VFAT, d'autre ext2, d'autre ext3, d'autre win.
            Si ca se trouve, il existe un type dans le monde qui a perdu un mois de travail apres un kernel panic.

            Comme on dit dans ces cas là : http://www.chezmoicamarche.org/(...)
        • [^] # Commentaire supprimé

          Posté par  . Évalué à -6.

          Ce commentaire a été supprimé par l’équipe de modération.

          • [^] # Re: Au secours !!! Perte de données !

            Posté par  . Évalué à 1.

            Plus sérieusement, on n'est pas chez Bisounours Land : il a fait une connerie, qu'il assume et qu'il en tire partie pour la prochaine fois.

            Exactement, sans avoir besoin de se moquer de lui !
  • # Re: Au secours !!! Perte de données !

    Posté par  . Évalué à 3.

    tu peux etre plus precis sur le message d'erreur ?
    les partitions ext{2,3} ont des superblock redondant (c'est utile si t'explose le premier), donc en essayant un autre (option -b) ça marche pas ?

    Tu peux aussi essayer parted (mais la c'est plutot pour des modification de la table des partition qui ont merdé)

    PS : ne jamais faire confiance a mandrake pour des operations aussi dangereuse (j'ai eu le droit a des partitions qui se chevauchait avec les outils mandrake....)
    • [^] # Re: Au secours !!! Perte de données !

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

      cela dit je n'ai pas encore vu pire qu'avec partition Magic ...
      • [^] # Re: Au secours !!! Perte de données !

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

        houuu le méchant FUD... Je l'ai utilisé pendant des années, PM, jusqu'à la dernière version, et j'ai fait des trucs de ouf avec, sans JAMAIS avoir un pépin... C'est bien simple, à un moment, même pour faire les pires manip, je lui faisait tellement confiance que je sauvais même plus mes données avant de commencer à jouer avec.
    • [^] # Re: Au secours !!! Perte de données !

      Posté par  . Évalué à 1.

      PS : ne jamais faire confiance a mandrake pour des operations aussi dangereuse (j'ai eu le droit a des partitions qui se chevauchait avec les outils mandrake....)

      Je confirme... j'avais une partition à redimentionner, et surtout, la flemme de le faire avec parted... alors j'ai mis le cd d'installation Mandrake et j'ai utiliser l'outil de redimentionnement... il a coupé les partitions, bien nettes. Ensuite en utilisant fdisk de dos (oui bon après y avoir réfléchit je pense aussi que c'était pas vraiment une bonne idée !) j'ai eu des partitions se chevauchant...

      Résultat ? J'ai pas cherché à comprendre (j'avais fait des sauvegardes) j'ai formatté le disque en entier.

      Par contre, dans ton cas, il doit être possible de repartitionner comme c'était au départ... de récupérer les donner (faire une sauvegarde) et ensuite de tenter de refaire une table des partitions, valide.
      • [^] # Re: Au secours !!! Perte de données !

        Posté par  . Évalué à 2.

        Par contre, dans ton cas, il doit être possible de repartitionner comme c'était au départ... de récupérer les donner (faire une sauvegarde) et ensuite de tenter de refaire une table des partitions, valide.

        non, parce que l'outil de redimensionnement aura vraiment redimensionné, c'est à dire restructuré le système de fichiers (sinon ça fonctionnerait probablement toujours).
        • [^] # Re: Au secours !!! Perte de données !

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

          si, je pense que ca se tente de refaire l'ancienne table de partition, si aucune donnée a été deplacé lors du redimensionnement, je pense que c'est la meilleure solution pour tout retrouver!
          • [^] # Re: Au secours !!! Perte de données !

            Posté par  . Évalué à 1.

            Mais les données (et méta-données) doivent forcément avoir été déplacées lors du redimensionnement, sinon ça n'en serait pas un. Si tu change la taille d'une partition dans la table de partitions sans toucher au système de fichiers dedans ce dernier aura toujours la taille d'avant.
  • # Commentaire supprimé

    Posté par  . Évalué à 1.

    Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: Au secours !!! Perte de données !

      Posté par  . Évalué à 1.

      je sais pas si ca va beaucoup lui servir de se foutre de sa gueule comme ça...
      • [^] # Commentaire supprimé

        Posté par  . Évalué à -2.

        Ce commentaire a été supprimé par l’équipe de modération.

        • [^] # Et les chevilles ?

          Posté par  . Évalué à -2.

          Bien sûr les mecs qui écrivent les docs et les pros qui en tiennent compte ne font jamais de connerie, c'est évident
          • [^] # Re: Et les chevilles ?

            Posté par  . Évalué à 2.

            le rapport avec la choucroute?

            LiNuCe ne dit pas que ces messieurs sont infaillibles, mais que la moindre des choses à faire est de suivre leurs conseils les plus évidents.

            Faire une copie de ses données avant un partitionnement, même un windowsien pur sauce XP peut le comprendre. Bon maintenant l'auteur du journal a sans doute compris. non?

            Sinon, d'après ce que l'on peut lire via notre bien aimé google, refaire la table des partitions telle qu'elle était avant le michoui, c'est jouable si rien n'a été déplacé comme c'est dit + haut par temsa.

            plagiats
        • [^] # Re: Au secours !!! Perte de données !

          Posté par  . Évalué à -1.

          "Il y a deux sortes d'admins Unix: ceux qui ont fait une grosse connerie en tant que root, et ceux qui vont bientot en faire une"
  • # Re: Au secours !!! Perte de données !

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

    http://www.cgsecurity.org/testdisk.html(...)

    marche trés bien, j'ai vu une demo à la linux expo
  • # Re: Au secours !!! Perte de données !

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

    si tu as des données importantes, je peux peut etre t'aider(en effet un de mes ami qui avait perdu ses .avi sur une partoche a fait un petit programme pas con du tout et me l'a envoyé cet aprem):

    il te faut connaître (approximativement au moins) la taille de tes fichiers à récupérer, ainsi que les headers de ces fichiers.

    ensuite, tu vas légèrement modifier le programme suivant:



    #include <stdio.h>
    #include <stdlib.h>
    #include <sys/types.h>
    #include <sys/stat.h>
    #include <unistd.h>
    #include <fcntl.h>
    #include <errno.h>

    #define FILE_SIZE (800*1024*1024)
    #define PATTERN "RIFF....AVI "
    #define BLOCK 4096

    int main( int argc, char **argv )
    {
    long offset;
    off_t off;
    int in, out;
    char *buffer;
    long i, len, pos;
    char pattern[] = PATTERN;
    long pattern_len = strlen(PATTERN);
    int count;


    in = open64( argv[1], O_LARGEFILE|O_RDONLY );
    if( in == -1 )
    {
    perror( "in:" );
    exit(1);
    }

    if( argc == 4 )
    offset = atoi( argv[3] );
    else
    offset = 0;

    buffer = malloc( BLOCK );
    count = 0;
    while( read( in, buffer, BLOCK ) == BLOCK )
    {
    for( i = 0 ; i < pattern_len ; i++ )
    if( (pattern[i] != '.') && (buffer[i] != pattern[i]) )
    break;
    if( i == pattern_len )
    {
    // OK on copie le fichier :p
    char filename[256];
    long size = *(long*)(buffer+4);

    count++;

    off = lseek64( in, 0, SEEK_CUR );

    sprintf( filename, "%s/%d", argv[2], count );
    printf( "%s (%d Mo) ", filename, size/1024/1024 );
    fflush(stdout);

    if( count < offset )
    {
    printf( "skipped\n" );
    } else {

    out = open( filename, O_WRONLY|O_CREAT );
    if( in < 0 )
    {
    perror( "open:" );
    exit( 1 );
    }
    i = 0;
    do
    {
    if( write( out, buffer, BLOCK ) != BLOCK )
    {
    perror( "write:" );
    exit(1);
    }
    if( read( in, buffer, BLOCK ) != BLOCK )
    break;
    i += BLOCK;
    if( (i % (100*1024*1024)) == 0 )
    {
    printf( "#" );
    fflush(stdout);
    }
    } while( i < size );
    close(out);
    printf( " done\n" );
    if( ((off=lseek64( in, off, SEEK_SET )) < 0) && (off != -EOVERFLOW) )
    {
    perror( "lseek:" );
    exit(1);
    }
    }
    }
    }
    close(in);
    printf( "END OF FILE\n" );



    les modifs à faire, sont:

    - editer le #define PATTERN correspondant au header du fichier et mettre des '.' à la place des caractères variables d'un header à l'autre.

    - modifier la ligne "long size = *(long*)(buffer+4);" pour mettre dans size la taille de ton fichier (mieu vaut surevaluer, apres tu pourras toujours couper dedans avec head par exemple) en octet.

    puis il te faut:

    - compiler ca avec:
    "gcc aa.c -o aa -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE"

    - prier pour que ton fichier ne soit pas fragmenté

    pour les arguments:
    "./aa /dev/partoche /rep/de/sauvegarde [nombre de fichiers à sauter (en cas d'interruption)]"
  • # Re: Au secours !!! Perte de données !

    Posté par  . Évalué à 2.

    salut,
    comme dit plus haut le superblock est backupe tout le long du syteme de fichier.
    pour avoir les infos du syteme de fichier faire :

    dumpe2fs /dev/hdaX

    ca sort en autres choses des trucs du style :

    Group 0: (Blocks 0-32767)
    Primary superblock at 0, Group descriptors at 1-1
    Block bitmap at 2 (+2), Inode bitmap at 3 (+3)
    Inode table at 4-512 (+4)
    58 free blocks, 16205 free inodes, 1 directories
    Free blocks: 16932-16937, 16962-17013
    Free inodes: 84-16288
    Group 1: (Blocks 32768-65535)
    Backup superblock at 32768, Group descriptors at 32769-32769
    Block bitmap at 32770 (+2), Inode bitmap at 32771 (+3)
    Inode table at 32772-33280 (+4)
    0 free blocks, 15874 free inodes, 3 directories

    etc ...

    dans mon cas le superblock est au block 0 (normal) et le premier backup au block 32768

    donc tu n'as plus qu'a le dire a fsck.ext2 :
    fsck.ext2 -b 32768.

    et ca repare tout ... normalement :-)


    A+ !

Suivre le flux des commentaires

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