Backup fails despite enough free disk space

It appears your are using consolidation, although your description looks like you are using automatic cleanup.
I think that the lack of space if because of the consolidation operation. Consolidation takes a lot of space, essentially the same amount as the files being consolidated.
You should switch to automatic cleanup, keep only the 2 most recent chains.
No need for this automatic warning.

In general, ATI needs to create a new full backup before it deletes a previous chain, plus some overhead.

Hi Pat, thank you for your prompt reply.

The word "consolidation" in my posting was meant colloquially, not in terms of a ATIH feature. Sorry for any confusion. I'm using ATIH 2015 that does not include the feature "backup version consolidation" anymore. To be more precise:

• Selected backup method: "Incremental"; option "Create a full version after every [n] incremental versions"
• Selected automatic cleanup rule: "Store no more than [n] recent version chains"

So consolidation is definitely not the reason for the problem. And, as already mentioned, there was always enough free space on the disk to create at least one more full backup. I can't imagine that "some overhead" means "multiple of a full backup's size". This brings us back to my initial questions.

1. Since you are making changes to the original backup task, it is possible your current settings is confused and not making the changes you are expecting. If it were me, I would start over with a new task with whatever revised settings you have room for but understand how the space is being configured. A new task should have a new name or non-identical to prior names. I also prefer each task have its own individual storage folder so backup files from other tasks as not intermixed.

2. The program attempts to create the next backup and either succeeds or fails; but does not deleted the oldest chain until AFTER your scheme quota has been exceeded.
So, if your keeping 2 recent version chains (7 tib files per chain), means your scheme quota is 14 files. Your quota of 14 is not exceeded until FULL B3 is completed so you must have enough space for at least 3 full and 12 incremental's for the program to run without issues.
Auto deletion of oldest chain occurs seconds after Full Backup B3 is completed--provided enough free space exists for B3 to be completed.
Once automatic deletion of oldest chain begins, the next deletion of oldest chain will occur after each new FULL backup.

So, if your keeping 3 recent version chains (7 tib files per chain), means your scheme quota is 21 files. Your quota of 21 is not exceeded until FULL B4 is completed so you must have enough space for at least 4 full and 18 incremental's for the program to run without issues.
Auto deletion of oldest chain occurs seconds after Full Backup B4 is completed--provided enough free space exists for B4 to be completed.
Once automatic deletion of oldest chain begins, the next deletion of oldest chain will occur after each new FULL backup.

So, if your keeping 4 recent version chains (7 tib files per chain), means your scheme quota is 28 files. Your quota of 28 is not exceeded until FULL B5 is completed so you must have enough space for at least 5 full and 24 incremental's for the program to run without issues.
Auto deletion of oldest chain occurs seconds after Full Backup B5 is completed--provided enough free space exists for B5 to be completed.
Once automatic deletion of oldest chain begins, the next deletion of oldest chain will occur after each new FULL backup.

I avoid using the disk space limit and prefer to work the "Store no more than [n] recent version chains" to control spacing.

Unfortunately, there is no way to make the program perform the delete prior to the creation of the backup so the extra space must be provided for the one extra full backup and then any scheduled deletion will occur.

Hi Grover, thank you for your detailed explanation how the automatic cleanup works! This is how I expected it would work. In my case (4 recent version chains), I estimated 5 * (max.) 50 GB + 24 * (max.) 1 GB = (max.) 274 GB. This shouldn't be a problem with a 500 GB disk, should it?
Ok, for a certain period there were also boot partition backups on the same external disk (before I encountered the problems and cut that backups, too). But there was always significantly more free disk space than the ca. 40 GB ... 50 GB required for the next full backup of the data partition.

I never used the disk space limit, I just enabled the notification in case the free space falls below a threshold value.

Over several weeks of testing, it happened several times that ATIH stopped making backups and I couldn't force it to continue the version chain. In these cases, I deleted the old backup task plus corresponding backup files and created a new backup task. (Of course, I saved the recent full backup in a separate folder before.) For the new backup task, I used the same folder (what then was typically empty or almost empty).
This is not exactly the same procedure as what you suggested - but it's similar and I wonder how ATIH should get "confused" by it.

Are there any significant overheads I have to consider when calculating the required disk space?
Are there known bugs causing ATIH to miscalculate the free disk space?

In my opinion, task editing can cause free space miscalculation as you may never have enough free space for the program to self correct.

Alexander,
These are my suggestions and if implemented exactly as I suggest, these have worked for me without any issues and have worked for many other users.
I have created certain rules which I follow and I believe they would work for you but my suggested rules must be followed and are more specific than suggested by Acronis. You indicated your settings are similar but I am suggesting you match my all suggested rules.

My suggested rules:
1. Once a task is used, no edits or changes.
2. Each new task must have a new name and that name must be non-identical with any others so no duplication of task names or tib file names.
3. Each task has its own storage sub-folder. You can have one main folder but each task must have its own sub-folder within that main folder. In other words, no mixing of tib backup files.
4. The task must be a 'custom' task and have automatic cleanup set using the "store n' number of recent version chains."

IMHO, once a backup task is in use, ANY edit or changes of settings by the user will cause the task NOT TO WORK as expected and the edits will not fquickly ix the problem and the edits may just prolong the malfunction longer. IMHO, if a task has been changed and is not working, the quickest solution is to stop using it and start over with a new task and the new task must be correctly figured at the beginning. You indicated making edits so from my perspective, it is time for a new task configured correctly from the beginning. It would be nice if editing worked but they do not--or certainly not immediately and no indication from Acronis as to what or when the edits will succeed--so I avoid all edits to avoid the waste of time troubleshooting an unknown quantity.

For the backup scheme to work correctly, it must be configured with automatic cleanup and the type of scheme MUST READ CUSTOM.
You can choose whether full only, or full with incremental, or full with differential but the scheme MUST READ CUSTOM,
and the cleanup method to be "store n' number of recent version chains". Examples listed in GH11; GH12; GH13.

GH12. Create Custom Incremental Backup Scheme w/auto cleanup. ...Keep Full plus 6 Inc per chain. Store/Keep 4 chains. Use whatever number best fits your needs.

------------------------------------------------
GH64. 71342: 2015 How to save a non-scheduled task.

Depending upon the type of backup scheme you wish to create, here is an example of each type. These can be set up for Disk image, or Partition, or Files-folders backups but the type must read CUSTOM. These example show how to set up automatic cleanup so the program will do the deletion after it reaches your set goal of how many chains to retain.

Editing an existing task is not recommended. Rarely does an edited task perform to user expectations. It is usually better to start with a new task using a new non-identical task name and point to a new storage sub-folder so each task has it own storage folder/sub-folder. Old task can be stopped or deleted from the task listings.

GH11. Create Custom Full Backup Scheme w/auto cleanup....Store/Keep 4 versions (chains). Use whatever number best fits the individual needs..

GH13. Create Custom Differential Backup Scheme w/auto cleanup. ...Keep Full plus 2 Diff per chain. Store/Keep 2 chains. Use whatever number best fits your needs.

GH63. 75086: A discussion on how to configure backup schemes.

GH63. 64640: Hints to help prevent issues with your TIB backup files creation. Illustrations mostly for 2014 but suggested rules also applies to 2015.

GH62. 64634: Using 2 different target disks for TrueImage backup.

Hi Grover, thank you for your extensive response. I understand that wrong calculation of residual free space on the backup destination disk (and other undesired effects, as well) may result just from editing a backup task. And, vice versa, with a virgin backup task the calculation of residual free space on the backup destination disk is correct and according to the rule/algorithm described in your posting 2015-06-09.

Following you recommendation, I will not spend more time to find the root cause for the wasted disk space (or even to optimize it). I'll keep track of the current backup tasks. If automatic backup and cleanup work, I'll leave it as it is. If not, I'll delete the current tasks and create new ones according to your suggestions.