Defragment and compress backup fails

[Epaminaidos]

Hi,

I discovered the new option to defragment and compress the backup every once in a while and activated it.

This option seems to create a second full backup. Is this correct?

The first time it ran, it created a 100 GB tmp-file and failed (I guess, the server rebooted due to windows-updates or I shutdown my notebook). The 100 GB-file remained on the drive until I deleted it a few minutes ago.
The second time, it has been running for 60 hours straight while writing a second 1TB-full-backup-file on my backup-drive. It failed shortly before being finished since it ran out of space.

Is this really how this option should work? Do I need to provide twice the space in order to have the backups reorganized?

I was expecting something like a database-compression:
The backup-file is reorganized in place to get all the data to the file's beginning. In the end, the empty space at the end of the file is just truncated.

Isn't this how it should work?

[PetrM]

Hi Otto,

Yes, you need to have enough free space for a full backup on the repository because compact creates an auxiliary file which exists in the target location until the completion of compact job. Please refer to this page for the full list of considerations and limitations.

Thanks!

[Epaminaidos]

Thank you! That clarifies things.

At least I am sure now, that I do not like this feature

[PetrM]

The main benefit of the feature is that it decreases the fragmentation level of full, thus allows us to achieve better RTO. Basically, I'd recommend to plan the repository capacity for having enough space for at least one full anyway regardless of compact.

Thanks!