Skip to main content

ATI 2013 Incremental backups unacceptably large

Thread needs solution

I am trying to set up a backup scheme whereby I am doing daily incremental backups, keeping 6 incremental backups after the full backup and then keeping two version chains. I assume this should give me 14 days on incremental backups.

I ran the backup which produced a full backup of 106GB and then immediately ran it again which resulted in an incremental backup of 2.5GB. What could have possibly changed to cause this size incremental ? The external disk just keeps running out of space to the point that a 1TB drive is only giving me 14 days incremental backup before reporting as full (old backups were not being removed but that is another issue altogether).

I am very close to ditching ATI for all my clients and going back to OEM Windows backup.

Attachment Size
ati2013_large_inc.png 35.18 KB
0 Users found this helpful

Also, I tried changing to a differential backup and now I get a 4GB differential file !!! See the timestamps ? This machine has been sitting idle since the full backup.

Attachment Size
140814-109843.png 23.31 KB

TrueImage records sectors which are used. The inc or diff file is a backup of disk sectors which have changed since the last backup. Perhaps you have an auto-defrag program running or Windows system checkpoints being created.

The switch from inc to diff has already confused the normal numbering and this change is reflected in the numbering. Frankly, if I were you, I would cease to use the existing task and settle for either inc or diff.

Be aware of that the program will NOT delete the oldest until AFTER it creates the replacement. This means you must allow room for an extra 106GB and this could be the part of your space issues.

Backup 1 will have 7 slices (1 full +6 inc=112GB)
Backup 2 will have 7 slices (1 full +6 inc=112GB
Backup 3 will need a short term temporary need for 106GB of storage space before backup 1 will be deleted.
Total storage to keep 2 full backup and be able to create a replacement full will require at least 330-350GB of storage space.
Before backup 3 runs, if it does not have at least 106GB of free space, it will fail before it starts.

There have been a few reports of the program seems to look at how much disk space is used on the source and if the storage location does not have the equivalent amount of storage space, it gives off the disk full error. This has not been confirmed. In your case, I am not sure of what is happening based on your other disk full issues.

Here is one example of how you might configure a custom incremental backup scheme based on your comments.
The example matches your 6 inc but change the example of 4 chains to 2 based on your desire to keep 2 Chains of 7
This will require free storage space of at least 330-350GB.

This is an extract from link 2 below and not all the info is specifc to you.

Figure 11-Inc: Example of custom/incremental backup method settings
If using incremental type backups (which is full + X Inc), the 11-Inc is my recommended method. Change the 6 or 4 to fit your available storage.
These automatic cleanup settings will provide for automatic deletion of the oldest backups after the "Store no more than X number of chains" quota has been reached.
In this example, deletion of oldest backup will occur immediately following creation of backup #29.

Allow space for 1 more full backup in addition to "Store no more than X number of chains" as the program will NOT delete the oldest full until its replacement has been successfully created.

In this example, one chain or one recent version chain =1 full plus 6 inc or 7 files per chain.
If keeping 4 recent version chains (4 chains of 7 each) retention would be 28 files. Deletion of oldest chain will occur after backup 29 (full).

Also understand the limitations/risk factor of incremental backups.
If one inc backups gets corrupt or accidentally deleted, all newer inc are worthless so avoid excessive number of incremental backups. Always maintain a full backup set which are current This explains why keeping a reasonable number of x "recent version chains" can be very important. Keeping a high number of incremental is a high risk factor to your backup data and should be avoided.
For a better understanding of the differences between Inc and Dif as it relates to the safety factor, review this link.
http://forum.acronis.com/forum/40810

When restoring an Incremental backup, select the specific Inc file to be restored and all preceding Incremental files plus the full backup base must be present and will be restored (multiple files required).

Thank you for your very detailed reply. I will put this to use tonight and report back on how I go. I have had an issue with a corrupt Acronis INC backup before so only do DIFF's now as a result. More disk space but less chance of problems.

ilium007 wrote:
I have had an issue with a corrupt Acronis INC backup before so only do DIFF's now as a result. More disk space but less chance of problems.

Indeed. It's for that reason that I make only full disk mode backups. They are the simplest and safest backups, but as you note they do require more disk space.

A corrupt issue with any backup is cause for concern. Perhaps a check for file or disk errors might be in order. Check all disks involved. Disk or file errors can prevent a success restore.