Is there any "benefit" to incremental imaging?

Discussion in 'Acronis True Image Product Line' started by timmy, Apr 1, 2005.

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

    timmy Registered Member

    Joined:
    Mar 24, 2005
    Posts:
    113
    We are unable to find any, since the incremental files are invariably the same size as the full original files. Would it no be better just to make original files?
     
  2. pvsurfer

    pvsurfer Registered Member

    Joined:
    Sep 1, 2004
    Posts:
    1,400
    Location:
    California - USA
    timmy~ I sure don't understand why your incremental images are the same size as your original (full) image! o_O

    I use my system every day and create an image once a week. At most, my incremental images are about 1/3 the size of their associated full image. ~pv
     
  3. PatG

    PatG Registered Member

    Joined:
    Apr 30, 2004
    Posts:
    579
    Location:
    South Alabama
    If you've defragged and moved data on the hdd, then this is the "why" the size is about the same. If you haven't defragged, size should be significantly smaller.
     
  4. Brian K

    Brian K Imaging Specialist

    Joined:
    Jan 28, 2005
    Posts:
    8,634
    Location:
    NSW, Australia
    My incremental images are around 3% of the full image. If I've defragged, the incremental images are up to 12% of the full image. Never any bigger.

    I'm not using True Image however. I'll try it with TI.

    Brian
     
  5. timmy

    timmy Registered Member

    Joined:
    Mar 24, 2005
    Posts:
    113
    Yes I have a program that defrag's once a day. I thought this was good? Did not know that defragmenting would harmfully effect the working of the True Image. This not so good, and not sure what to do about it. I don't understand also what the other fellow meant when he said his incremental images were not that large, and then he said he was "not" using the True Image. Then what was he using? And if he wasn't using the program, then how could his incrmental images exist at all, in any size?
     
  6. FTJoe

    FTJoe Registered Member

    Joined:
    Mar 25, 2005
    Posts:
    20
    I posted a similar question two days ago but got no response. When testing, I took a full image of a 11G drive, and the image was 4+G. I added a line to a one line text file in a folder on the desktop and took another image, that was also 4+G. Best I've seen is a 1+G image. No defragging going on and I suspected the 1+G image was the swap file or whatever it's caled these days. I would love to use incremental imaging but can't see how I could do it with the files this big, at least not to the hard drive.

    To answer the question though, the benefit would be to have several scheduled images over a week's span in case the last one taken is no good.
     
  7. Menorcaman

    Menorcaman Retired Moderator

    Joined:
    Aug 19, 2004
    Posts:
    4,661
    Location:
    Menorca (Balearic Islands) Spain
  8. sandokan

    sandokan Registered Member

    Joined:
    May 14, 2004
    Posts:
    112
    Are your volumes NTFS?

    If they are NTFS and you are NOT running a huge file server with 100s of 1000s of tiny files, defragmenting a HDD is useless (perhaps once a year would be OK). Read up on file system and LCN to find out why NTFS on a "normal" workstation makes defragmenting a thing of the past.
     
  9. FTJoe

    FTJoe Registered Member

    Joined:
    Mar 25, 2005
    Posts:
    20
    I decided to try using the secure zone to make my incrementals. Looks like the incremental is very small (based on the free space still remaining according to XP). So I'll keep playing with it. I have another question but will update the thread I started to ask it again...

    https://www.wilderssecurity.com/showthread.php?t=73406
     
  10. Brian K

    Brian K Imaging Specialist

    Joined:
    Jan 28, 2005
    Posts:
    8,634
    Location:
    NSW, Australia
    Using TI my first incremental image was 8% of the full image size.

    Brian
     
Thread Status:
Not open for further replies.