| Author |
 Topic  |
|
|
Marcel
Starting Member
Spain
3 Posts |
 Posted - July 01 2012 : 14:42:02
|
I see that every time I carry out an imaging operation (a daily differential, a full one every month), I always see the image as completely (99%) fragmented, even if -for a full image- I do defrag C first (after having thoroughly cleaned).
That, of course, gets worse as I get the daily differential image and afterwards delete the previous one ("yesterday's).
Why fragmentation is so extreme?. Also: I suppose that hitting "restore" will, of course, restore, but if fragmentation is so extreme, that means that it will take longer for the image to get restored than would otherwise?
Marcel |
|
|
Drac144
Advanced Member
USA
647 Posts |
Posted - July 01 2012 : 20:10:17
|
What software are you using that tells you the image is fragmented? Is the image on its own drive (external) or are you storing it in a partition of the main drive? Is the image the ONLY file on that drive?
Fragmentation is more of an issue if you need to access a file frequently. Image files that are highly fragmented may not be a problem since you are not accessing them (I assume) very often. However a 99% fregmentation does seem excessive. |
 |
|
|
Marcel
Starting Member
Spain
3 Posts |
Posted - July 01 2012 : 20:53:02
|
TuneUp Drive Defrag (TuneUp 2011).
The image is in an external (USB) drive, used exclusively as a backup (that is, for imaging once a month and making differential images daily).
Once I have the latest differential, I delete the former (the one from the day before).
I would understand that the differential images get fragmented (even quite fragmented), precisely due to the procedure I use. What I cannot understand is that the main one is also that fragmented. As I said, I do clean (let's say, streamline) C and then defrag it before imaging.
The backup drive is 149GB: The full initial image (medium compression) is 36.838.480KB and today's differential is 4.126.366 Kb, also at medium compression, and that is all in the drive.
The analysis for fragmentation in this drive (TuneUp 2011, and also AVG PC Tuneup, though I use this one quite rarely) gives always a 99% fragmentation figure
I use XPSP3, fully patched and updated. |
|
|
|
john.p
Moderator
887 Posts |
Posted - July 02 2012 : 14:07:03
|
Hi,
The comments from Drac144 are valid, fragmentation should not an issue for a backup image.
If you wish to reduce the fragmentation of your backup images, you need to de-fragment your target (not your source drive) viz your usb attached backup drive before taking an image.
If your backup disk is FAT formatted, then your can expect a high level of fragmentation, especially when the disk contains a number of large files and / or the used space is a significant proportion of its capacity. The NTFS filesystem is designed to minimise fragmentation; though it cannot be eliminated if your disk is significantly utilised and you are writing large files such as backup images.
Kind Regards
John - Macrium Support |
|
|
|
Marcel
Starting Member
Spain
3 Posts |
Posted - July 02 2012 : 14:53:31
|
Hi, John.
I am getting more and more puzzled. All my disks (USB backup included) are NTFS-formatted.
Will try a trick to find out from square one:
1) Streamline C:, then defrag it
2) Reformat the backup disk
3) Image C: anew.
4) Check what the fragmentation in the backup (image) is after it all
Will report accordingly.
By the way: I could include a screenshot of the fragmentation analysis... if I knew how to append a file here. Is that possible?
Best regards
Marcel |
|
|
|
john.p
Moderator
887 Posts |
Posted - July 02 2012 : 15:31:44
|
Hi,
To be be clear.
1) We store a snapshot of your source disk. This is a pure read only process and will only reflect, not change the state of the fragmentation of your source disk.
2) We write to your target disk using the Windows filesystem drivers. This, necessarily, is entirely responsible for how the file is arranged on the disk. We have no control over its resultant fragmentation.
Your suggested strategy will ensure that your source and target filesystems are minimally fragmented. However, you may still find your subsequent image file is fragmented as your target is a live filesystem; open/locked files will never be de-fragmented and files may be created / extended by other processes post de-frag and before the imaging process is complete.
Kind Regards
John - Macrium Support |
|
|
|
scottls
New Member
USA
13 Posts |
Posted - November 20 2012 : 04:51:31
|
Re:
john.p Reply?-
Your suggested strategy will ensure that your source and target filesystems are minimally fragmented. However, you may still find your subsequent image file is fragmented as your target is a live filesystem; open/locked files will never be de-fragmented and files may be created / extended by other processes post de-frag and before the imaging process is complete.
~~~~~~~~~~~~~~~~~~
I do weekly full C: image backups to my F: partition on my slave HD, that is reserved for image backups Only (after a full defrag (the day before- keep last 5 images/delete before).
My O&O Pro Defrag Always Reports these images are Badly fragmented.
I almost never have to access these images, so I'm not overly concerned.
I do notice that image backups take about 15sec longer every backup-
I assume they are writing into 1st free space...
I tried an F: defrag- it took 1hr 45min, and lowered my next image backup by 30sec (Not a good trade-off!).
Q?-
If I Show Hidden Files just prior to backup (Hide after), will it significantly reduce fragmentation? 
BTW- O&O Defrags Hidden/Index files, without having to Show Hidden, and it quickly Defrags MFT/System Every boot.
Win 7 Pro (32), Kaspersky Internet Security 2013, and no other active anti-malware. O&O Defrag.
Free on-demand- MBAM (No Pro!).
i5-2500 CPU @ 3.67GHz, WD Raptor Sata6 10k rpm HD (WOW!). |
|
|
|
Antony
Moderator
United Kingdom
212 Posts |
Posted - November 20 2012 : 10:21:27
|
Hi scottls,
No, showing or hiding hidden files won't improve or worsen fragmentation. The files are still there on the system and applications can still see them regardless of whether the option is on. The hidden files option basically affects the user interface only - so the files are invisible in Windows Explorer and the Open/Save dialogs you see many applications using.
So applications still use hidden files, and hidden files may therefore become fragmented as the NTFS driver moves them around.
There are a number of factors which may account for/contribute to differing imaging times - increased disk usage, whether you're taking a differential/incremental, antivirus and numerous other possibilities. If you're keeping your disks regularly defragmented as you describe, this will ensure you are as optimized as you can be from a disk standpoint.
Kind Regards,
Antony
Macrium Support |
|
|
|
alan9182
Advanced Member
United Kingdom
527 Posts |
Posted - November 20 2012 : 20:42:34
|
I believe that when the image file is written to the disc it is guaranteed to be horribly fragmented if it is placed in horribly fragmented free space.
Perhaps you need to defrag free space before creating a backup if you are concerned.
Personally I see no point in the religion of some who defrag System Volume Information.
You never ever use more than 1% of it,
apart from when you need to use System Restore to "go back in time".
I expect to create between 10 and 200 partition image backups before I ever need to restore one.
I really see no point in worrying about 99% fragmentation - I do not see its relevance.
I thought that this would mean that 99 files out of 100 were fragmented,
but you are talking about a single image file.
If you are concerned about an image file with 100 fragments,
then each fragment might require the disk head to move from one track to another and then to wait for the disk to rotate to the relevant sector. I would guess perhaps 20 mSec per fragment or 2 seconds for 100 fragments
I have a 7 GB full image with 20 fragments.
It takes about 4 minutes to restore my system partition.
Perhaps it might be 0.4 seconds faster if there were no fragments.
I might be a little annoyed that I failed to block a back action and needed to spend 4 minutes of my life waiting for an image restore,
but 0.4 seconds extra is not worth thinking about.
|
|
|
| |
Topic |
|
RSS Feed
KB
Fragmentation - Images
