Incremental BU takes just as long as Full BU

Discussion in 'Acronis True Image Product Line' started by flyer1, Aug 22, 2005.

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

    flyer1 Registered Member

    Joined:
    Aug 22, 2005
    Posts:
    3
    Hi...
    Just started using True Image. The hard drive I'm imaging is around 31gb. When I do a full BU it takes about 20 minutes or so and is compressed to about 20gb.

    When I append an incremental BU to it a week later, it still takes about 20 minutes to accomplish, though the size is much smaller.

    I thought the incremental BU's were supposed to be much faster than the full. And if they're not any faster, I'm wondering why I don't just do a Full BU once a week.

    Any suggestions regarding this would be much appreciated.

    Thanks!
     
  2. SSK

    SSK Registered Member

    Joined:
    Nov 28, 2004
    Posts:
    976
    Location:
    Amsterdam
    Did you defragment your drive between images? If so, that is probably causing the bigger incremental images. :)
     
  3. flyer1

    flyer1 Registered Member

    Joined:
    Aug 22, 2005
    Posts:
    3
    No...I don't defrag.

    The "size" of the incremental is much smaller as expected.

    What confuses me is that it takes just as long as the Full Back. Acording to all I've read, one of the main reasons to do an incremental is that it should be able to be done in much less time.

    Don't know what I'm doing wrong.

    Thanks
     
  4. Acronis Support

    Acronis Support Acronis Support Staff

    Joined:
    Apr 28, 2004
    Posts:
    25,885
    Hello flyer1,

    Thank you for choosing Acronis Disk Backup Software.

    The incremental image is made by comparing used sectors content checksum. This makes the creation procedure almost as long as the one for the full image. However, the main goal of incremental images is that they are usually much smaller than the full one.

    Thank you.
    --
    Ilya Toytman
     
  5. Menorcaman

    Menorcaman Retired Moderator

    Joined:
    Aug 19, 2004
    Posts:
    4,661
    Location:
    Menorca (Balearic Islands) Spain
    Hello flyer1,

    My thoughts on this are as follows:

    Creating a TI image is highly processor intensive. The time taken depends on a combination of processor speed and disk sub-system data transfer rate.

    There is an additional processor overhead when creating an incremental image. Namely, the CPU has to also compare the "thumbprint" of the in-use sectors for the previous image with the "thumbprint" of the in-use sectors of the image you now wish to produce before writing the differences to disk.

    Therefore the time saved by creating an incremental image will be less noticeable (if at all!!) on systems with limited spare CPU capacity (i.e. slower processor).

    The larger the original full image, the greater the potential for time saving by creating an incremental image (unless of course a defrag took place in between).

    Regards
     
  6. howie123

    howie123 Registered Member

    Joined:
    Dec 1, 2004
    Posts:
    48
    Kind of off-topic but I have found the processor speed make a profound difference in imaging times. On my old PIII 450, a 12 GB image took about 25 minutes (about 500MB/min) when imaging from a 7200RPM ATA133 drive to another drive of exactly the same specifications. I recently upgraded to a P4 3.0Ghz and imaging the same amount of data (12GB) takes under 6 minutes. That's over 2GB/minute. I did try Ghost 9.0 for fun but that took twice as long to image the same amount. Nothing tops TI when it comes to speed... :)
     
  7. Brian K

    Brian K Imaging Specialist

    Joined:
    Jan 28, 2005
    Posts:
    12,176
    Location:
    NSW, Australia
    Using a non TI application, incremental backups take about 15 seconds, including verify.

    For example, my C: drive image (normal compression with verify) takes 2 1/2 minutes and is 2.3 GB. The average incremental size is 80 MB (some bigger, some smaller). Interestingly, defragging makes no significant difference to the incremental size which is the opposite of what we are told.

    Just a comment as my experience is different from that described above.
     
  8. THoff

    THoff Guest

    The backup program you are referring to probably uses the Archive bit in the file system. The bit gets set anytime a file is created or changed, and gets reset when a file is backed up.

    As such, finding files that need to be backed up is very fast because the files themselves don't need to be examined. On the downsize, if you have a large database and are adding records, the entire file gets backed up, rather than just the changes.
     
  9. Brian K

    Brian K Imaging Specialist

    Joined:
    Jan 28, 2005
    Posts:
    12,176
    Location:
    NSW, Australia
    No, I'm using Gh... 9
     
  10. Brian K

    Brian K Imaging Specialist

    Joined:
    Jan 28, 2005
    Posts:
    12,176
    Location:
    NSW, Australia
    Howie123,

    I used to have a P3 450 and my backup rate was 250 MB/min using High Compression. Do you use compression for your images?


    A friend had a P3 1000 and his rate was 100 MB/min. We couldn't determine why his imaging was slow.
     
  11. flyer1

    flyer1 Registered Member

    Joined:
    Aug 22, 2005
    Posts:
    3
    Thanks to all for weighing in.

    Since space isn't really a concern for me, I'll probably just do full BU's once a week since the time to do them is the same.
     
  12. Brian K

    Brian K Imaging Specialist

    Joined:
    Jan 28, 2005
    Posts:
    12,176
    Location:
    NSW, Australia
    Flyer1,

    I just did a test on a friend's computer. It took 3 mins to write a 1.1 GB image and another 2 mins to verify. I immediately did an incremental image which took 2 mins to write and 1 min to verify. The incremental image was only 11 MB.

    This is in keeping with your observations.
     
Thread Status:
Not open for further replies.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.