Differential Backups, defragmentation & documentation

The Archive Creation Mode page of the help file included with TI9 2032 includes a note which reads as follows:

"If you have defragmented your hard disk since the last full backup, an incremental backup could be as large as the full. . . ."​

It doesn't say anything about defragmentation affecting the size of differential backups. From what I'm reading on the forum, this is misleading and needs to be corrected.

You may also add me to the list of people who feel that incremental and differential backups are virtually useless if we cannot defragment.

-Jeremy

 

Any backup program that is dependent on the drive on which the backup files are recorded not being defragged is very poorly designed.

Does True Image really have this problem?

 

Indeed, it does. Not entirely dependent, but dependent on it not being defragged to avoid irrationally sized incremental and differential backups.

 

Does Ghost 10 suffer from the same affliction?

 

I found the following on page 8 of the version 9 manual.

"An incremental or differential backup created after a disk is defragmented might be
considerably larger than usual. This is because the defragmentation program changes file
locations on disk and the backups reflect these changes. Therefore, it is recommended that
you re-create a full backup after disk defragmentation."

1. This is the only mention of "defrag" in the manual.
2. Nothing states that backup files cannot be defragmented.
3, Stating that it is "recommended" to do a full backup after a defragmention is NOT a requirement. Perhaps, Acronis needs to update the manual?

 

Yes, Ghost will behave the same way. It is not an affliction. Rather it's the result of drive imaging software going places that it should never have gone to.

Leave the file backups to those programs that do it best. Imaging programs were never meant to do general file backups. Sector by sector copying of data was never meant for files. It was meant to backup/restore drives and partitions.

Since all imaging software pretty much do the same thing, companies felt they add to add all kinds of stuff to their imaging software to set it apart. File backups is just one of these things. I can name more but I won't.

 

Is there an echo in here ?

Hehe... just kidding, Howard. But I do see what you said and what plover said as being substantially equivalent.

Oh, BTW, Howard -- I thought I saw your name somewhere else ! Now I realize it was in "that other forum" where you're a guru. You may see more of me over there now that things work well with that and my other three PCs !

 

The problem is more evident when users refuse to join the XXI century and fail to understand that defragmenting NTFS volumes is useless. I've already posted several technical papers on the issue, and I am not the first nor the last one who will do so. Unless one is running a huge file server, defragmenting NTFS volumes serves no other purpose than a placebo effect at best.

 

One advertisement has been removed from this thread. The Acronis support forum is for just that - Acronis support - not for advertisements.

 

TI9 does now have file-based backup. But this a different feature from what we are discussing. The incremental and differential backups are still sector based, which is precisely why defragmenting has the effect that it does. TI doesn't know or care *what* is in a given sector. All it cares about is whether it changed from last time. And this is precisely why differential and incremental backups can be so large if you defragment. Now if Acronis could figure out a way around this, that would be something to write home about.

I was only pointing out that the manual is misleading if indeed differential backups suffer from the same limitation (albeit as designed -- I'm not calling it a bug or defect) as the incremental backups, in that defragmentation can nullify its benefits. The help file should be updated to read,

"If you have defragmented your hard disk since the last full backup, an incremental or differential backup could be as large as the full. . . ."

And I'm looking for confirmation that this is indeed the case also with differential backups.

-Jeremy

 

The backup program doesn't care one way or the other whether the files are fragmented or not. It doesn't look at files or any given file system. The limitation is that if you do a full backup, defragment and do an incremental (and probably a differential) backup, the benefits of the feature will be largely negated.

-Jeremy

 

I tend to agree with you. I used Powerquest Drive Image for years -- since version 3 maybe. Version 6 was the last version that was useful to me. Most of what they included with v7 was of no value to me. I just saw increased overhead with system services, etc. Give me a boot CD to get into a simple GUI for backups, and I'm happy. Personally, I don't trust all this "backup while running the OS stuff." I like the Acronis recovery manager, but for the life of me I can't understand why you can't configure your backup in the Windows GUI, reboot, have the Acronis Recovery Manager automatically load and execute your commands. To this day I consider going back to DI6 and calling it a day. What more do you need?

-Jeremy

 

Can't agree with you here. If you work with video, you Fat32's 4GB file size limit is a problem. Plus NTFS has additional security and data integrity features. Not that I understand them fully. But thinking about it, chkdisk only rarely has to "fix" data problems due to bad shutdowns etc (and with my standby issues, I've been putting it through its paces in this regard). I recall that in the Win9x days, chkdisk had was always "fixing" something. And it never really fixed anything. It just moved your data somewhere where you could take out a hex editor and say. Wow, look at that, unless you're a professional disaster recovery specialist.

-Jeremy

 

Are you seriously saying that random read is as fast as sequential? What drive did you test, I would like to have few of them

 

From what I've gathered over the years, NTFS greatly resists file fragmentation but doesn't totally eliminate it. Therefore it's probably worthwhile executing a defrag once in a while. Also worth bearing in mind that Windows XP users won't see the performance benefits of its prefetch/layout.ini feature (if enabled) until they carry out a defrag.

Regards

 

It doesn't even really resist fragmentation, it just is not affected by it. That is, there is no real problem with fragmentation for NTFS file system; NTFS will work efficiently with almost any degree fragmentation.
BUT, that doesn't mean that drive itself will work with same efficiency regardless of fragmentation. Sequential read is still much faster than random.

That is completely correct, and quite important.

 

"Also worth bearing in mind that Windows XP users won't see the performance benefits of its prefetch/layout.ini feature (if enabled) until **they carry out a defrag**."

Not to get picky, but I believe the prefetch defrag is done automatically, without user intervention (about every 3 days).

 

The day people start reading for comprehension will indeed be welcomed.

I don't have that problem because I joined the XXI century abd use NTFS exclusively. Why would anyone want to use a FS that totally lacks a recovery journal and that's exposed to instability is beyond me.

I am saying that regardless of whether the files are contiuous or not, that doesn't mean that the data contained therein belongs to the same chunk, therefore the heads will have to seek nevertheless for the next 64KB of sequencial data all over the place. Don't use the rolleyes emoticon, it's infantile, and only accentuates your ignorance on the topic at hand.

I did say that defragging NTFS volumes is useless, which doesn't imply that they do not get fragmented (at an extremely lower pace than FAT32 ones though), it's simply that they do NOT suffer from fragmentation as far as performance. A lot of people (newbies generally) feel that defragging gives their machines a boost, well, yeah, this is quite well known as the placebo effect. Some of them go as far as recommeding VoptXP, whose algorhymn is designed to simply consolidate space, without defragmenting abything at all.

Workstations running modern architecture OSs (FS NTFS) don't need defraggers at all. Huge file servers (notice the distinction), do benefit from it simply because of the small nature of the files they are serving.

 

mmm...are you sure? To assume that the only usage scenario that involves performance degradation from fragmentation is "Huge file servers" really seems to ignore the range of disk intensive operations that people may be doing in different situations. I`d certainly like to read your evidence that supports such a claim