Full and Incremental Archives are the same size
I'm wondering why full and subsequent incremental archives are coming up as same in size... We are using the Enterprise Server version and ftp-ing the backups to a SAN Drive. The server being backed up is a freshly installed Win Server 2008 and is strictly as a web server w/o any databases.
I set up serveral tasks - one weekly full and serveral incremental backups that run during that week. All backups go to the same ftp directory location. When I view the ftp directory (see attachmented jpeg), I see the full backup archives (split in 2.5 GB increments) and the daily incremental archives that are the same sizes of the full archive. There are no .pst files and no daily defragmenting going on the server.
I was expecting to see smaller incremental archive files...Do I have my set-up wrong?
Hello Augie,
I understand the question and will do everything possible from my side to give you a clear explanation.
There can be several reasons for the encountered issue:
- Defragmentation - An incremental or differential backup created after the disk is defragmented will be considerably larger than usual. This is because the defragmentation program changes file locations on the disk, and backups reflect these changes.
- Creating an incremental or differential backup after recovering the full one – An incremental or differential backup created after the full one was restored will be considerably larger than usual. This is because restoring a backup archive changes file locations on the disk, and backups reflect these changes.
(!) In Windows Vista disk defragmentation is enabled by default. For information how to reschedule or disable it, see Microsoft Windows help page: Start Disk Defragmenter.
- Using fast incremental backup method to back up partitions that have Microsoft Outlook .pst file – This issue is only with fast incremental backup. It does not occur when creating a regular incremental backup.
To solve the issue do the following:
After defragmenting a disk, create a new full backup of it.
After restoring, create a new full backup of what you restored.
In Acronis True Image Echo, do not use fast incremental backup method to back up partitions that have Microsoft Outlook .pst file.
Let me know if you need further assistance.
Thank you.
Interesting wrinkle, I thought that most backup programs used the A (Archive) flag to determine what to backup (incremental backups resetting the flag after the backup and differential ones not changing it). Since I'm also using Diskeeper (which de-fragments continuously in the background) I guess this is going to be an issue for making incremental/differential backups with TrueImage?
--
GregR
Yes, TrueImage bases its backup on changes on the disk. It will track every change that a defrag program makes. You have to make some changes ini one program or the other. Change defrag or change the incremental type backups.
I am sorry, but this does not seem helpful to me, it sounds like the incremental feature is broken. I can understand the requirement to not defragment between the incremental backups, but a large file right after restore is bogus. Acronis restores the disk state and knows where it puts the files. I do not understand how is it not possible to take a diff of what's there with what's new and only save the diff. This pretty much means that if I had to do a restore then I have to start over on my backups - that in my mind defeats the purpose of the feature.
After a restore, all the occupied sectors have been rewritten. ATI doesn't restore only the sectors that need an update. Hence, an incremental backup after a restore will see all the sectors updated.
Of course, a restore makes all backups done after the date chosen for the restore obsolete.
Are you preoccupied by space or duration of backup after a restore?
Pat, many thanks for the quick response. Yes, both the space and the backup/restore duration set me back in my work. I am doing a lot of experimenting with software builds and install/uninstall, and I need to be able to get back to a clean state. My goal is to keep my system growing while keeping it stable; any new experiment I do may corrupt the system and I have to do a restore, at which point I have to start over. You can say that I can use the last stable backup and not care about the previous ones, but the problem is that as I do lots of debugging/testing of my software, I often find that the problem got introdused earlier than my last backup was, so I need to keep them all. Therefore ideally I want to keep one full and a long series of the small incremental backups, regardles if I had to do some restores in the middle. Can you suggest how to achieve this? Will the consolidation of incremental backups get me to the smaller increments?
Thanks again for the help!
What you are trying to do makes total sense.
Let's make something clear for disk and partition backups: even if you have an incremental backup, when you restore that backup, the full and all the incrementals until and including the chosen one are restored. So restoring an incremental is exactly like restoring a full: you cannot do partial restores.
In theory, try&decide should accomplish what you are trying to do, but only partially because there is only 2 states known by T&D: the initial state and the state at the time you discard/keep the changes. In other words, there is no intermediary backups. In addition, T&D is iffy...
I am afraid there is no solution with Acronis to accomplish what you are trying to do. Acronis can only take full snapshots of a disk and restore them fully.
I don't know of any backup software that could isolate partial changes done to the system affecting specific programs, executable, or registry settings.
Yes, I agree, there is no time difference on restore; but restore is faster than backup anyway - so there is no issue here. I tried T&D - very iffy, I am not using this feature since.
Now that I understand the limitations of the ATI incremental backups, I'd have to change my backup strategy and live with it I guess, until Acronis or someone else figures out a better way. Thanks for your support though!