Feature Request -parallel Full and incremental Backup-

[ralfl]

During a synthetic Full backup there is no further job processing possible until this task has finished. Normally a synthetic full is done in a short time.

But if there is a problem
- with a Storage System and performance is degraded or
- when a Scaleout Repository is in use and one extend has low disk space and the new full is automatically created on a different extent
very long runtime can be seen.

If we're using a Scaleout Repo and only one of the storage system holding one extend has the degraded performance problem the complete job processing has a problem.

Putting the extend to sealed status is not a solution because a new full cannot be created in one day. We're offen dealing with hundreds of large VM's.

Parallel processing of incremental and full backups could be a solution? Make always an incremental backup and add an additional job creating the full and afterwards merging the increments? This could be schedule outside the normal backup window in normal operation?

If a full runs a longer time there will be no problem with missing backups.

In addition, it will be fine if VBR will create internal measurement of storage performance to predict job runtime. If a daily job takes more than X hours send an alert or if a defined backup windows cannot be reached.
Similar to CDP alerts.....

[Mildur]

Hi Ralf

- when a Scaleout Repository is in use and one extend has low disk space and the new full is automatically created on a different extent

This can be controlled starting in v12. You can enable the Strict placement policy enforcement option. The backup job will fail instead of creating a new backup on another extend. This gives you time to add new storage to the extend.

Parallel processing of incremental and full backups could be a solution? Make always an incremental backup and add an additional job creating the full and afterwards merging the increments? This could be schedule outside the normal backup window in normal operation?

Incremental backups from foreign chain cannot be merged with the original backup chain. And running two backup sessions the same time is not possible because of Windows VSS limitations. Two backup processes asking for a VSS snapshot the same time will lead to a failed job.
Even if it would be doable somehow, I think it would still not solve the main issue that your full backups would run longer than one day. Running a active full backup (reading all data blocks) in your production hours may also affect the performance of the production server.

If a daily job takes more than X hours send an alert or if a defined backup windows cannot be reached.
Similar to CDP alerts.....

VeeamOne has such an alarm. It's called "Maximum allowed job duration".