Can I defrag a tib file?
I have just mirrored my data partition of 44GB.
The tib file uses 39GB on another HD.
However looking at it with O&O defrag cluster view shows all squares are red. Should I defragment it?
thanks for any insight.
Richard
Thanks Colin
I looked in Acronis help but could not find any warning which should perhaps be prominent for non-techies like me.
Just bought a new computer for FlightSim FSX so only one full image backup in Archive so far. I have 3 custom backups; for Windows7, FSX, and my data. Win7 up to 2 sets of differential, FSX up to 2 full snapshots etc.
The time I have spent with this new Chillblast is daunting and I practiced many backups to external discs and BluRay etc. But I have little experience of restoring anything.
Richard
Richard,
The image size you mention is very large compared to the source drive size.
Is the 44GB used data size of the drive?
Are you sure you only images a single partition and not the complete disk, which wiould include all the hidden utility partitions that might be on your system?
Did you alter the default compression setting?
I would expect 44GB used sector partition image with standard compression to be around the 10-15GB mark.
The tib size 39GB comes from 44GB of data on a 500GB partition. Music and picture files, documents and films which do not compress much. Transferred laboriously from my old Dell via USB stick. I use normal compression.
Richard
To Colin B:
> No! :) That is the short and definitive answer.
OK. But why?
I am not questioning your statement, but I do wonder why defragging a file will destroy its usefulness.
I assumed an Acronis backup file is just a file in a normal format and defragging it would leave it as valid as before. If defragging a file will destroy its usefulness then will copying it from one disc to another also destroy it?
OK. But why?
>
I assumed an Acronis backup file is just a file in a normal format and defragging it would leave it as valid as before. If defragging a file will destroy its usefulness then will copying it from one disc to another also destroy it?
A number of reasons.
1. The tib file is compressed - defragging it can alter the compressed bits causing the decompression to fail on restore and TI will report the image as invalid.
2. The internal checksum will be incorrect if the file is defragged as at a byte level things will not be in the same position depending on the type of defrag algorithm used.
3. Defragging the file doesn't update the partition or file record chain that are part of the sector imaging, it would only alter the sector records for the actual drive the image is on. This would mean on restore the file headers and indicators of which sector to read next (for non contiguous files) would be incorrect.
4. I defragged a tib file once in error, the defragging program took 5 hours to play with a 25GB tib file and hadn't finished when I manually stopped the process. I deleted the file.
Copying a file is different as the information in the image is not altered, it is just copied byte for byte. There is of course an inherent failure if there is a glitch that causes a bit to be altered when copying, but the likelihood is low, but can happen just as copying any file has an increased but low possibility of corruption.
Colon B:
Again, I am not questioning your statement about defragmenting a tib file. However:
> The tib file is compressed - defragging it can alter the compressed bits causing the decompression to fail on restore and TI will report the image as invalid.
Compressing a file only alters the bit stream by replacing a section of data with a smaller, and reversible, set of data. All of the new data in the revised bit stream is contained in the data blocks on the file and these are not changed when a file is decompressed. That is, the actual compressed data remains unchanged after the defragmentation. Only the physical location of the data block and the associated links in the FAT are changed so I don't see why defragmenting a file would have any affect on the compression of the data.
I have frequently defragmented zip files without any issue and they, of course, are compressed.
> The internal checksum will be incorrect if the file is defragged as at a byte level things will not be in the same position depending on the type of defrag algorithm used.
I don't see why this should be so. All of the checksum algorithms I am familiar with compute the checksum based on the content of the file, not the location of the data blocks. Defragmenting a file changes the location of the data blocks on the disc but does not change the content of the data blocks themselves so I don't see why defragmenting a file will change the checksum.
Moving a file, even on the same disc, will change the physical location of the data blocks and that does not change the checksum so I fail to see why defragmenting a file would do so. Downloading an application such as Photoshop can well cause a change in the level of fragmentation of a file since the location the file is copied to may well require fragmenting a previously unfragmented file. However this does not change the checksum of the file.
> Defragging the file doesn't update the partition or file record chain that are part of the sector imaging, it would only alter the sector records for the actual drive the image is on. This would mean on restore the file headers and indicators of which sector to read next (for non contiguous files) would be incorrect.
I am not sure exactly what you are referring to when you mention the "partition or file record chain". Are you talking about the information in the FAT? Or information in the Acronis internal database concerning the file?
If you are referring to the information in the FAT, then I would respond that defragmenting a file does update the FAT information. If it did not do so Windows would no longer be able to access the data in the file since defragmenting a file changes the location of the information in the file.
If you are referring to information in an internal Acronis file database, then I would respond that adding the defragmented file to the list of backups would rebuild all of that internal information.
> I defragged a tib file once in error, the defragging program took 5 hours to play with a 25GB tib file and hadn't finished when I manually stopped the process. I deleted the file.
OK. But did you try to use the partially defragmented file?
> Copying a file is different as the information in the image is not altered, it is just copied byte for byte. There is of course an inherent failure if there is a glitch that causes a bit to be altered when copying, but the likelihood is low, but can happen just as copying any file has an increased but low possibility of corruption.
A file, at least as I understand it, is nothing but a linked list of data. Each sector is part of what becomes the file stream when it is accessed and the sectors are ordered and retrieved by the information in the FAT. Copying a file may well change the size of the individual sectors since, when a file is copied, the new disc area may be more or less fragmented and the sector sizes and relative locations may well change. That is, I have copied highly fragmented files to new discs where the result has been a defragmented file and I have copied files that were unfragmented to locations that required that the file be fragmented since the new location did not have sufficient unfragmented space. I guess I don't see why explicit defragmenting of a file would be any different from implicit defragmenting caused by copying.
I need to stress that I know nothing of the internal workings of Acronis and, as far as I know, you are correct about defragmenting an Acronis file. I am not questioning your basic statement as I have never explicitly defragmented an Acronis file. However I have certainly copied files from one disc to another where the level of fragmentation is not the same. And I have certainly explicitly defragmented compressed files and folders without the defragmentation causing any problems.
Further I have frequently had to add existing Acronis backup files to the list of backups and then had no problems when those backups were validated or used by Acronis. I assume that adding those tib files to the backup list rebuilds any internal Acronis links that need to be created. Otherwise I assume the backups would no longer work.
As I said before you may well be right about defragmenting a tib file. I have never actually done that. I just don't understand why. Perhaps there is some basic misunderstanding in the way I view the Windows file system and I am missing something basic here.
My personal opinion is that defragmenting a .tib file is not itself the problem. The problem arises when there are hardware / environmental issues during the defragmentation process. As .tib files are sometimes very large, the amount of time spent by the defrag program of choice actually manipulating the data is much longer than with smaller files. During this extended time frame, data errors "could" occur because of environmental issues (power outages, spilled cup of coffee, etc.) or hardware issues (component failures, undiagnosed/intermittent problems).
Because the .tib image files are so important as a restore/recovery resource, special handling of these files is necessary and prudent.
I have many times defragged drives that contain .tib files with no problems (verified by validating the .tib files afterwards).
If defragmentation of a hard disk is performed on a properly functioning system, there is no reason that the process should damage ANY data on the disk.
The benefit of defragmenting a large .tib file is of little to no value, that I can see, as it would be rarely accessed once written to the disk.
I think that makes much more sense. I can see no technical reason that defragmenting a tib file should be a problem. In fact, Windows automatically defragments the file system as part of normal maintenance (from the Windows help file - "Windows automatically defragments and optimizes drives as part of regular maintenance.") and, if defragmenting a file would cause the backup to no longer work, I would think we would have heard about that long before now.
But I also agree that backup files should be used so rarely that explicitly defragmenting one is a waste of time. I keep my backup files on a special backup usb drive and only use it when I need to restore something. Hopefully that is a very rare occurance.
We have seen several times TIB files being "corrupted" simply by copying or moving the file. Of course, you'd think that the OS APIs provide the utmost reliability but the fact is bytes in a file can change during operations. This is not systematic, of course.
When it happens, the validation of the file might fail, but it might succeed as well. When the validation fails, the recovery might fail as well, but it might succeed. If the recovery fails, you might still be able to extract valuable of content, or you might be stuck.
Since defragging a backup disk doesn't improve the backup performance in any measure worth the trouble, I'd save the risk.
I personally avoid tinkering with backup files at all. I validate my backups manually on a regular basis, and some times, the validation fails. Go figure. When it happens, I mark the backup, but I keep it.
If you can't exclude the disk, or if the performance you gain are worth a marginal risk.
If you copy a TIB file, use verification software to verify the copy, or validate the copy.
I was referring to the FAT/MFT chain records inside the tib file, the defragger has no way of updating the disk information that is inside the tib file, it does of course update the records that refer to the tib file itself on the physicial disk level.
Any manipulation of bits increases the risk of corruption to varying degrees, it doesn't take much for electrical noise to cause bit corruption, one reason why there are different algorithms employed to correct or as in video and sound ignore certain bit misrepresentations. There are vagaries to be taken into account, not everyone has a PC in tip top condition from an electronics point of view, not all peripherals or the physical layer they use are up to scratch, power supply and EMI locally may make a system more prone to problems, running a defrag generally speaking on something that is very important (having a reliable restorable image, for most people) is in my opinion to be avoided when, in my judgement the risks, are increased and running a defragger increase that risk, it increases it when defragmenting a physical drive (though yes, I do defragment my Windows drives occasionally), I still stand by what I said in my post above.
YMMV, of course.
We have seen several times TIB files being "corrupted" simply by copying or moving the file. Of course, you'd think that the OS APIs provide the utmost reliability but the fact is bytes in a file can change during operations. This is not systematic, of course.
When it happens, the validation of the file might fail, but it might succeed as well. When the validation fails, the recovery might fail as well, but it might succeed. If the recovery fails, you might still be able to extract valuable of content, or you might be stuck.
Since defragging a backup disk doesn't improve the backup performance in any measure worth the trouble, I'd save the risk.
I personally avoid tinkering with backup files at all. I validate my backups manually on a regular basis, and some times, the validation fails. Go figure. When it happens, I mark the backup, but I keep it.
If you can't exclude the disk, or if the performance you gain are worth a marginal risk.
If you copy a TIB file, use verification software to verify the copy, or validate the copy.
> We have seen several times TIB files being "corrupted" simply by copying or moving the file.
I have been working with computers for far too long to suggest that accidents don't happen. Of course, when working with a computer, pretty much anything can happen. However the OS is supposed to insure that copied files are identical and that means verifying blocks when they are copied. Except for cases when the target sectors are bad I have never seen a copied file differ from the original and, in those cases when I have seen it, I have been notified by the OS that the copy is no good.
I have, of course, seen disc sectors go bad but that is a different story.
> I personally avoid tinkering with backup files at all.
As do I. My backups are on a separate external disc and that disc is only used to either make a new backup, restore an existing backup or validate a backup. When I start running out of space on a backup disc I either delete some older backup or copy all of the backups to a new disc and make that disc my new backup disc. I never manually defragment a backup system because I don't see any reward for taking such a chance.
My assumption was the the OP did not want to explicitly defragment his tib file but rather wanted to defragment a disc that contained, among other items, his backup file. I can see his point but I avoid using the discs that contain my backups (and my wife's) unless I need to do some backup/restore operation.
> Any manipulation of bits increases the risk of corruption to varying degrees
Agreed.
> running a defrag generally speaking on something that is very important (having a reliable restorable image, for most people) is in my opinion to be avoided
Agreed.
But it is worth mentioning that Windows, by itself, automatically defragments the file system as part of its normal maintenance. Thus, if a backup file is fragmented and is on a disc that is normally accessed by Windows (as compared to on a separate external disc) it will eventually be defragmented by the OS. If defragmenting is going to cause a problem I would think that we would be hearing of people's pain due to the normal Windows defragmentation process.
Of course discs can become corrupt and sectors can fail. Backup files that were good one day can be bad the next due to a disc failure, static electricity, bad equipment and so on. That is the reason that I keep the copies of my digital photos on two separate external discs. If one fails I have the other.
And, as I said before, I have no certain knowledge of the effect defragmentation would have on a tib file, but I have been using Acronis since True Image 10 and that included heavy usage as I restored systems regularly. Those backups were copied from external disc to external disc and I never had a restore failure unless the original backup had some glitch or the disc itself was damaged due to some external reason. I never manually defragmented those discs but I am sure from time to time Windows probably did.
I certainly agree that there is no benefit to manually defragmenting a tib file. I am just not sure that the process itself, as compared to bad equipment/mishandling/external reasons will cause a restore failure.
Here's why defragging a tib, or almost any file, for that matter, is ill advised. If you do the math, you will see that even a tremendously fragmented file will add a small amount of time to a file read-- a few milliseconds per gigabyte if tremendously fragmented. With a TIB, you will probably only read the file during a restore, which occurs very infrequently. So the savings in milliseconds over the entire time it takes to read the file (done rarely) is but a pittance especially compared to the time spent defragging. To gain this rarely realized pittance you defrag, which thrashes your disk for hours. It's like walking the long way all the way around the barn just to get in the front door.
If you computer is working properly no bytes should be changed during any file operations, not even if compression is involved. But no system is perfect so there's a small risk of corruption performing a file operation on a tib (defrag or whatever), although I've never seen this happen on a properly working machine-- only on bad drives.
Defragging is unnecessary, uneconomical, impractical, and generally a waste of resources unless you enjoy watching the defrag display.
I agree with almost everything you wrote but the OP did not ask if defragmenting a tib file was wise, he asked if it could be done without destorying the usability of the file.
I have written that I do not know, for a fact, if defragmenting a tib file will destroy it but, the more I think about it, the more I think that the process of defragmentation itself would have no ill effects on the file. Can the file be damaged by the defragmentation process? Probably, but only by faulty hardware or stray environmental effects such as disk movement during the process or some external electrical shock. The same thing is probably true of copying the file.
But can it be safely defragmented (where safely means the file will still work)? Almost certainly. Remember, Windows is constantly defragmenting the file system without being asked to do so and we do not hear of problems from that process.
Right. If the machine is working, file ops should maintain the data integrity. Computer would be pretty much useless without that feature. In fact , about as useless as defraggers,especially post-write defraggers.
If the drive operates properly, there should be no problem defragging a drive containing .tib archives. It might take a long time, though.
[quote=Scott Hieber]
> It's like walking the long way all the way around the barn just to get in the front door.
I love your analogy! As a total non techy in order to use a computer with windows I have to do that all the time, sometimes walking backwards twice round.
>Defragging is unnecessary, uneconomical, impractical, and generally a waste of resources unless you enjoy watching the defrag display.
I have to admit I like watching those nasty red squares turning first yellow and finally all blue. It gives me a sense of health and wellbeing. And it does help reduce stutters when flying with FSX.
Richard