Feature Request - Ability to Seal individual VM/Server backup chains

[forums101]

Hi,

We have a reasonably large Veeam environment and we have had it for a significant time, during this period grown a lot and had to expand SOBR's with additional repositories.

I find managing capacity within a SOBR very difficult as the only option is to seal entire repositories. Making VMs create new chains on a new repository is very difficult as only newly added VMs will go to the repositories with the most free space.

What I have found is that if we wait until we have say 90TB left on a repo as the trigger for us to add another one (which of a 280TB repo is a fairly generous percentage), even by the time we add another on over reasonable time the original one getting low on capacity can still run out of space and synthetic fulls start to fail. Which if you depend on cold cloning on XFS or REFs for significant data reduction it becomes a very bad situation to be in.

Adding to this problem we have very large VMs eg 20-30TB which you never want to have to move somewhere else unless you are completely retiring a repository.

What would make things much easier is having the ability to seal individual VMs backup chains so they start their backup chains on a new repo in the SOBR with the most capacity, which Veeam now does most of the time.

As we have many small and test VMs etc with a small retention period it is, making them move to another repo makes it easily to manage space within a SOBR within a reasonable time.

It also means not having to go through the difficult process of trying to manually do this process, especially on hardened repositories as this makes life much harder.

Regards,

Paul

[bcravn]

Hi Paul,

I don't have any good solution, but we have the same issues. I tried asking support for their recommendation, but the approach was to wait until perhaps 10TB left (our extents are about 800TB) and then seal it.
Then new chains was made on other extents, and we could wait until the sealed extent had regained free space, and then unseal it again.
Ours struggle is also caused by perhaps a few very large VMs and a pretty long day-to-day retention of 180 days.

So +1 from my side, on somehow a way of manage the SOBR better

[vnikiforov]

Hello, gentlemen,

Thank you for all the details provided - you request has been acknowledged.
We plan to improve that feature in future versions, but I can't provide you with any ETAs at this time.

One more point: we also have plans for the new feature: moving backups between SOBR extents. Do you think that could help you with your scenarios? I mean, it's not really sealing a backup chain...

[bcravn]

Hi Vladimir

That sounds great -to be able to move a single chain/vm.
I guess it would still require the backup job of the vm to be disabled ?
But at least it would allow us to move smaller vms around, to reduce any "downtime" of the scheduled backup jobs

[vnikiforov]

Hello, Bjarke,

Thank you for the input. For the specific implementations, it is too early to discuss, but as I said, we are working on improving a few points there.