Disk Images Not Contiguous

I find the disk images I make of my OS (XP-home) with Version 7 are not contiguous as shown by Defrag. May I assume the fragmentation was part of the image source and not how it was "created" when the image was made. However I assume that can happen also if the image was "created" on a badly fragmented drive?

Ed

 

Some here advocate always defraging a drive before making an Image Backup. I don't always do it and haven't had any problems restoring a backup.

 

Since TI creates a file when it makes an image archive it the problem is with how the archive file was written. The source disk info is just data in the file. If the image was created on a fragmented drive that could explain it. I don't know what algorithm Windows uses to decide where to start writing a file.

On the other hand, image files are usually several or gigabytes in size at least which means a lot of disk reading and processing. A few extra hops around the disk might add a few seconds onto the several minutes it takes to do the job but is it a real issue considering the few times one accesses these files if at all? This is not like some OS files that are accessed many times per day.

You can defrag the drive your images are stored on since they are just files with nothing special about them other than their size. I personally wouldn't do it because it isn't worth it and in the shuffle you might have a slight hiccup that will render the archive useless (shouldn't happen though).

 

Defragging the source drive (the one you are backing up) may make the backup a bit smaller and the backup may run a bit faster. That's the reason, but it's not a requirement.

Defragging the target disk is also a good idea if it doesn't have other backup images which are fragmented. Defragmenting the large image files takes a long, long time, and the benefit is trivial. I only do this when the drive has no images, so the defrag is quick. Then the new images will not be fragmented. However, deletine an image will ususally cause the next image to be fragmented, but so what.

 

My concern has not been the quality of the image (never had a problem restoring old images) but only that when I attempted to defrag this partition, or the same file copied to another networked computer, the file could not be defragmented. I keep other other archive information on this drive, routinely defragmented and just never paid attention to the "analysis" or even the defrag (just automated an ran weekly). From your comments I will not defrag this partition and the source partition before I create an image and suspect this will create a contiguous image. As indicated copying does not but I now realize we a copying a single file within its own wrapper (my analygy) and not recorded line by line where ever they lie on the disk.

Ed

 

Negative report - I defraged by OS on the C partition, defraged after deleting all images on my E partition, then made a new image of my C drive placing it on E. Hitting Analyze (XP-Home SP2) shows the image in red located near the end of this partition (well out from the blue "other files"). Any explanation?

Ed

 

To quick on the trigger - I didn't realize that defrag was still working, walked aways from the computers and on my return the large red area, the image, was moved close to the "permanent stuff" at the beginning of the display and now is blue or free of fragments. Don't understand why the original image was fragmented when taken from a freshly defraged drive but the product did defrag.

Ed

 

If the "from a freshly defraged drive" means the drive you were making an image of was freshly defragged, it has nothing to do with the fragmentation state of the output file. TI just gathers up the disk sector data, formats it in some what and writes out a big file or files. The fragmentation state of the destination drive or the way files get written by Windows is what will control the fragmentation level of the output tib file. Making an image puts the data in a file, if you were cloning then the defragmentation state of the source drive would be an issue.

I understand that if a disk does not have enough free space it the defrag process may not run. I could see this happening on a fairly full disk with images on it since the image files are large. FWIW.

 

The "defrag was still working" You mean you wrote the new image of C to E while E was being defragged? That's impressive. With the reports here of people saying that defragging messed up an image so it wouldn't verify, none wrote it in the middle of a defrag.

 

Sorry, not quite. I defraged C, then E then made the image. The surprise was that the image was indicated to be one large red fragmented area. However as I did note I then defragged again and the area and the entire file moved closer to the existing files and was now fragment free.

Ed

 

Oh, that's comforting.

Windows has rules for when deleted file space can be re-used. Ideally, after a defrag, all the empty file space would be usable immediately starting with the space right after the last file in the first group. However, it's not that simple, unfortunately.