Backup image size before and after HDD optimisation

Discussion in 'Paragon Drive Backup Product Line' started by Grasmith, Mar 29, 2010.

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

    Grasmith Registered Member

    Joined:
    Oct 13, 2009
    Posts:
    6
    Hi folks

    The following is a bit long-winded I'm afraid.

    I have been using Drive Backup 9 Pro for approx 2 yrs to image my HDD on a weekly schedule.

    Over the weekend, I decided to do a complete "spring clean" of the drive:- remove temp files, cull the registry and consolidate free space/defrag.
    It is the first time that I have done this in the 2.5 yrs of ownership of my notebook.

    "CCleaner" presented me with 200 lines of redundant registry entries, and approx 6GB of temp files!

    So, backed up Hdd (image file size 62GB) and "killed" the lot.
    Rebooted to make sure I still had a viable m/c. Everything o.k

    Used "MyDefrag" to optimise the drive then another backup to preserve it all.

    It was the image size of this last b/up that caused the alarm bells to ring, it being reduced from the above mentioned 62GB to just 38GB.

    Is there anybody out-there who can can either reassure me that the reduced image size is to be expected or that I do, in-fact, have a problem.

    Thanks in advance.
     
  2. Paragon_Tommy

    Paragon_Tommy Paragon Moderator

    Joined:
    Aug 10, 2009
    Posts:
    918
    Hello Grasmith,

    Might be a good idea to do the full backup after accomplishing your "spring cleanup".

    As a note, typically when you backup, the archive should only be the size of your data, not the partition size or its capacity. If you still think the report is in error, I would recommend running a check disk of the hard drive with /r parameter. With normal compression, archives should be around 80% of its original data size.

    Finally, you can use the File Transfer Wizard under Tools to browse into your archive and sample the data. Double click the archive file and move any files you want to sample to the clipboard.
     
  3. Grasmith

    Grasmith Registered Member

    Joined:
    Oct 13, 2009
    Posts:
    6
    Thankyou for your reply, Paragon Tommy.

    I am sorry to appear just a little bit obtuse, but all b/ups were full HDD images and over the last 6 months were approx 62GB in size.

    What I am trying to do, is assess that a significant reduction in HDD image size(to 38GB) can be an expectation after fully optimising the drive, given that fragmentation of drive data has been an ongoing process for the last 2.5 years, during which time defragmentation of any sort has not taken place.
     
  4. Paragon_MattK

    Paragon_MattK Paragon Moderator

    Joined:
    Jan 14, 2010
    Posts:
    176
    Location:
    Irvine, CA
    If your file system was extremely fragmented, it is possible that the defragmentation process could cause such a dramatic size difference in your archives, simply because highly fragmented files can take up more space on the disk then unfragmented files, while this large of a reduction in archive size is not typical, it is also possible that by defragmenting the files, they are more easily compressed.

    What are your compression settings? (have they changed?)

    How much data was being backed up before optimization? (how much did you delete?)

    How much data is being backed up after optimization?
     
  5. Grasmith

    Grasmith Registered Member

    Joined:
    Oct 13, 2009
    Posts:
    6
    Hi Paragon Matt

    Your comments have kicked my brain? into gear!

    Obviously, image size is directly proportional to "used disk space".

    Prior to culling and defragging, used disk space approximated to 60GB.

    Now, properties shows 39GB.

    Compression is Fast Compression.

    "Killed" 6GB of Temp files and 170 redundant registry entries.

    The net reduction of used disk space is surely an indicator of how badly the drive was fragmented. Getting rid of 6GB of temp files and the reg entries alone, noway accounts for this very considerable reduction!

    Grasmith
     
Loading...
Thread Status:
Not open for further replies.