Experiences and suggestions

Tonikun
2009-11-17
2013-04-11
  • Tonikun
    Tonikun
    2009-11-17

    Hello,  I want to be grateful to the developers for this great program and I will talk about my experiences with the program as they suggest in the man page.

    1) The great things that make a great program:

    Reverse direction, Skip mode and Jump mode. With a mix of this modes I have elaborated a general recommended procedure that I'm applying successfully (see below).

    2) Some improvements:

    Default block size should be 512, as today's hard disks have usually this block size and most programs use this by default.

    You can stop and resume thanks to the bitmap file, but the counters of ok and bad blocks resets every time. It will be very useful that statistics are written to a file when the program exits, to know at least how many blocks you have processed in total (now I have to annotate by hand).

    3) My recommended procedure: The goal is to save the maximum good blocks with a minimum reading of bad blocks, that can cause the drive to die at any moment.

    First read from the beginning until a bad block is found:
    `myrescue -b 512 -A -B logfile.log /dev/sdx imagefile.img`
    Annotate the number of block where it has stopped (b1). Now read from the end:`myrescue -b 512 -A -R -B logfile.log /dev/sdb imagefile.img`
    Annotate the number of block where it has stopped (b2). We have readed only 2 bad blocks and in most cases saved a great number of good blocks. Now we have to deal with the "bad zone":`myrescue -b 512 -S -f 1 -s (b1) -e (b2) -J (b2-b1) -B logfile.log /dev/sdb imagefile.img`
    Normally compared with the number of total blocks the bad blocks are only a small percentage. With random jumping in most cases we have more possibilities to find a good block than a bad one, and with the jump-after-blocks we save most times a lot of good blocks at the expense of only one bad. This is very useful, but you have to be observing the number of good blocks because in this mode the program never stops, and when you don't see them grow for a reasonable time (at least 1 hour) it's time to go to next step. At this time in most cases we have saved almost all of the good blocks, but I add this step with skip mode in the case we have a disk with a lot of defects:`myrescue -b 512 -S -f 1 -s (b1) -e (b2) -B logfile.log /dev/sdb imagefile.img`
    And now start a normal run to copy the remaining skipped blocks:`myrescue -b 512 -f 1 -s (b1) -e (b2) -B logfile.log /dev/sdb imagefile.img`
    Optionally, if you have time and/or your data is very important you can retry bad blocks again (add -r 3 if you have few bad blocks):`myrescue -b 512 -s (b1) -e (b2) -B logfile.log /dev/sdb imagefile.img`
    And that's all. English is not my native language, so if I made any mistake excuse me and feel free to correct me.

     
  • Tonikun
    Tonikun
    2009-11-17

    Ops, forget about block size suggestion, I had not readed carefully that topic: http://sourceforge.net/projects/myrescue/forums/forum/235860/topic/3284820 where is explained about the block size.

    And another experience:

    Now I'm experimenting with myrescue as a hard disk diagnostic and repairing tool (reading and writing to the same device) and seems it works well, but I wonder if it actually writes anything to a block in the destination device that previously cannot be readed from the source device, or it simply skips that block in the destination device. Writing it will activate the internal sector remapping function and could "repair" the sector (if there is sufficient space at the reserved zone).