Image and bad blocks

Discussion in 'Acronis True Image Product Line' started by enonod, May 20, 2009.

Thread Status:
Not open for further replies.
  1. enonod

    enonod Registered Member

    Joined:
    Mar 21, 2008
    Posts:
    109
    Location:
    UK
    If an image is made of a partition containing NTFS bad blocks, does that image contain duff data such that when restored, it continues with bad blocks?
    If it doesn't, and is then restored to the same disk area after reformatting does the disk/partition still contain bad blocks?

    I understand that writing to a disk with bad blocks will map them out and re-address the chain to other sectors. However, when an image is replaced it is written sector by sector and I am assuming?? that this will overwrite bad sectors and leave the same problem.

    Can anyone enlighten me please?
     
  2. seekforever

    seekforever Registered Member

    Joined:
    Oct 31, 2005
    Posts:
    4,751
    Good question. I'll give you my understanding of at least some of it.

    First there are 2 bad block mechanisms on a HD. One is the low-level one first created at the factory which allows a new disk to appear perfect by a hardware remapping of sectors. The second is a file, $badclus or something like that, maintained by NTFS. It is possible to update the hardware bad block table with some special programs.

    If your NTFS system appears perfect because you ran chkdsk on it and it has fixed any bad sectors, then when you make an image the image will only contain the good sectors. A normal image does not contain any sectors that are not in-use by the file system. If you make a sector-by-sector image which includes every sector, used or not, in the partition then it probably will contain the bad sectors as seen by NTFS but not the hardware table. I suspect a clone would be the same as the sector-by-sector image but I'm not clear on what happens to un-used sectors in a clone although I suspect they are copied.

    Note that when TI restores an image it does not necessarily put the data back into the same sector which it came from. That is, data in sector ABCD could be restored to sector ABXY unless it is a sector-by-sector image of the whole partition. The filesystem is adjusted to account for such changes so the restored disk looks the same to the user.

    If you restore a normal image containing NTFS marked bad blocks to a new HD then good sectors would be marked as bad. However, Acronis has said that if you resize the partition (can be a very small resize), this will cause the NTFS bad block table to be ignored. This does make me wonder that if you resized the partition similarly on the original disk that you should be running chkdsk as your top priority!

    I try to run chkdsk /f or /r at some interval to avoid possible image problems. TI is quite good at dealing with less than perfect file systems but it isn't infallable.

    The above is my understanding of how things work but I am not an expert so it is open to correction.
     
  3. enonod

    enonod Registered Member

    Joined:
    Mar 21, 2008
    Posts:
    109
    Location:
    UK
    Thank you seekforever, That has answered my question enough but has produced another. I thought that TI might replace sector for sector at all times. It had not occurred to me that the process could mark good sectors bad, which is interesting because DD will not permit resizing with bad blocks.

    When I copy the resultant file to a USB drive it is almost always corrupted even though the size is correct most times (so I never Move files only Copy then delete if verified). Perhaps there is a program that will copy while live checking CRC and ask for a re-send of the last packet if in error.

    Is there a solution to this copy problem, which does not manifest itself for small files?
     
  4. seekforever

    seekforever Registered Member

    Joined:
    Oct 31, 2005
    Posts:
    4,751
    You'll probably see my answer in your other thread nearer the top.

    Doesn't mean they don't exist but I don't know of any programs off-hand that do a on-the-fly data check - the ones I know of just do a verify after copying which is essentially what the TI Validate does although the TI one is much more stringent since it uses 4000 checksums/GB of archive.
     
  5. enonod

    enonod Registered Member

    Joined:
    Mar 21, 2008
    Posts:
    109
    Location:
    UK
    Thank you seekforever
     
  6. jmk94903

    jmk94903 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    3,329
    Location:
    San Rafael, CA
    If this only occurrs with very large files, it's probably a hardware limitation of the motherboard and BIOS.

    This was fairly common five or more years ago and often occurred with errors on copying files as small as 800Mb -1.3GB. Most new motherboards seem to handle even extremely large files (10Gb and larger) without errors.
     
  7. enonod

    enonod Registered Member

    Joined:
    Mar 21, 2008
    Posts:
    109
    Location:
    UK
    Thanks jmk94903. Since my conclusion that it is the drive, I have tested the disk elsewhere with the same file and no problem, under Vista 64. This suggests you may be right. However...
    I have an old 40GB Firelight drive. I can copy the file to that all day and it is never corrupt. On the original system. Weird!
     
Thread Status:
Not open for further replies.