Ad-hoc backup only and retention behavior, feature requests

[daphnis]

Been using this product since beta and it is terrific. I've used this to restore several of my endpoints, each time simple, straightforward, and without any issues whatsoever.

I'm looking to understand how retention behavior works for ad-hoc only backups. For example, I use this to protect one of my HTPCs where content rarely changes and so it is only necessary to ever perform ad-hoc backups for things like OS patches, application upgrades, driver updates, etc. Let's say the retention is set to "last 14 days when computer was used" and the target is a locally-attached USB disk. Backups are done irregularly, perhaps once a week, another two weeks from that point, and another maybe as much as a month later. Let's also say that the target disk is dedicated solely to storage of the retention points. What happens in the synthetic merge logic when there are 10 restore points, a job is triggered, and the disk is out of space to accept a further retention point? Those 10 restore points stretch back to a period of 3 months ago and are distributed amongst that time. Will this next run fail, or will it attempt to perform a synthetic roll-up typical to the forever forward strategy before executing the next backup? And a separate but related question: When disk digests are being calculated, does VEB have enough information to approximate the next restore point size before proceeding to move data to the repository? In general, I'd like to know more about the VEB logic when faced with an out-of-disk-space scenario at the repository.

This then brings the following feature requests to mind:

1.) Can the backup console have an option to perform an ad-hoc synthetic merge of the full with the oldest restore point if the answer to my question above is "VEB will fail the job"?
2.) Would you consider an option to not specify any period of time that the computer was used and instead attempt to keep as many restore points as the backup target has space available?
3.) Will more backup chain logic be implemented similar to B&R, for example reverse incremental, forward incremental with periodic synthetic?
4.) Will VEB be enhanced in the future to make use of the scale-out backup repository in B&R v9?

[lxk3il]

Just leaving a quick info here:
https://www.veeam.com/blog/ad-hoc-versus-scheduled.html

[Dima P.]

Hi daphnis,
Thanks for the feedback – glad to hear you like our product! To start with - incremental ad-hoc backup is affected by retention, so should be merged on the regular basis and now to your questions.

hat happens in the synthetic merge logic when there are 10 restore points, a job is triggered, and the disk is out of space to accept a further retention point?

The backup job should fail and should not start merging process unless new incremental backup is created.

does VEB have enough information to approximate the next restore point size before proceeding to move data to the repository?

Data can be deduplicated and compressed during the job run, thus backups size cannot be estimated.

Can the backup console have an option to perform an ad-hoc synthetic merge of the full with the oldest restore point if the answer to my question above is "VEB will fail the job"?

You can merge the restore points for “one day” even now. Just reduce the retention and run a backup job – old restore points should be merged into full backup.

attempt to keep as many restore points as the backup target has space available?

We keep tracking this request, so your vote is counted.

Will more backup chain logic be implemented similar to B&R, for example reverse incremental, forward incremental with periodic synthetic?

Yup, it’s planned for the next versions.

Will VEB be enhanced in the future to make use of the scale-out backup repository in B&R v9?

Definitely! Coming soon.

[daphnis]

Thanks for your responses, Dima P.