Two suggestions regarding the retention job and immutability logic

[DanielJ]

Last night I waited for a backup move job to finish, which it did some time after 00:30. I then started the backup manually since it had been missed due to the move going on. But before the backup could start, the retention job (starting at 00:30) had locked some of the files, so around 10% of the vms failed. When the backup had finished, I retried it, but all the failed vms failed again with the message "A backup file is immutable". So I would like to put forth these suggestions:

1. Let backup jobs wait for the retention job to finish, instead of failing the locked vms immediately.
2. Set the immutability flag after a vm backup has been finished successfully, not as soon as it has been started. There seems to be little value in applying immutability to a failed backup.

[Mildur]

Hello Daniel

Have you considered to move the retention job to another timeslot when no backup jobs are running?

Code: Select all

HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup and Replication\
"RetentionJobStartTimeHours" DWORD, 0-23
"RetentionJobStartTimeMinutes" DWORD, 0-59

Immutability flag is set when the current backup session has completed. Setting immutability at the beginning of a backup job before would make the file unwritable by the backup job. If you see something else, please investigate it with our customer support team.

Best,
Fabian

[DanielJ]

I have considered that, but the need to start a manual backup can happen at any time. I should of course remember to check if the retention job is running first, but letting the backup job wait for the retention job seems simple and logical. Or indeed wait for any type of file lock (for some reasonable time).

I forgot to mention this is a vCD backup. I have only seen this "A backup file is immutable" error with vCD backups, so it would seem they are creating some file first (maybe the backup of the vApp itself) which then cannot be written to/removed if the backup has to be retried. I can even reproduce it by stopping a running vCD backup job and then retrying it. If this is actually some unknown and unexpected behaviour, then I can send in a ticket. Wouldn't be the first time vCD backups behave in surprising ways compared to ordinary vm backups.