Pause repository extend - Feature request

[olafurh]

Hi,

Little back story. When you grow, and may grow over few hundreds, event PB of backup data, the pressure of not putting a repository extend in maintenance mode and doing a evacuation gets more demanding, as just by putting a repository extend into maintenance mode - you are basically putting it offline and all backups that depend on a point in an incremental chain will fail. (or do a new full if you have configured it that way)

Doing an evacuation of a extend, with 10-20-30-40-50-60 TB of data takes time, even if you have multiple 10GB links between repositories and you will halt a lot of operation just by doing so.

So we need a new option, pause all new writings to a repository extend and let all incremental expire over time. (months-years), and in the end, the health check/defrag process could defrag the fulls to a new full in another repository extend.

Oli

[Gostev]

Hi Olaf, yes this feature is planned already (internally, we call it "SOBR extent sealing"). And thanks for explaining your use case in great details - it is always more convincing for developers when it comes directly from the customer, as opposed to myself

[jameskilbynet]

We also have some similar use cases. We have built a REPO that is 160TB that would be almost impossible to evacuate ( we have no plans to do this at the moment and its unlikely we would build anything this big in the future) We are tending to around 50-60TB. We are also a cloud connect provider and it would be difficult for us to remove an extent from CC when the hardware needs refreshing. We have built maintenance windows into our proposition but we wouldn't be able to evacuate an extent in this ( the window was sized around patching windows/veeam upgrades etc )

[LBegnaud]

Yes just adding my 2 cents to say that this is about the only pain point of B&R for us right now. We have the need to cycle hardware every now and then or juts OS issues causing us to need to rebuild the volume (thanks ReFS...). Evacuation is just too aggressive for what we need. being able to just tell Veeam that we'll eventually be retiring it, and to let things expire over time (basically maintenance mode but allowing retention and, in the case of data locality, existing chains to be processed)

[lemtargatwing]

I'm going to second (or is it fourth at this point?) this feature for the very same reasons everyone else is. I know you said it's planned, is it a long term goal or is it something planned for the near future?

[Gostev]

It's in the "short-term" bucket.

[garypigott]

+1 on the “SOBR extent sealing” feature! The evacuation procedure is unworkable for cloud connect service providers. Will we see it in the next update?

[Gostev]

No, likely in the following only.

[skf]

+1 on the “SOBR extent sealing” feature here as well. As a service provider we feel the pain on evacuating an extent, specially when we are having repositories 50 - 100TB.

[Gostev]

Definitely understandable... we're working on this feature now.

[mcz]

Anton, I'm running 9.5 Update 4b and I had to re-import a backup chain which also has some restore points on S3. A lot of madness happened during that time and finally I got the message that my S3 extents are "sealed". I didn't know what it mean and switched back to "online" and now it looks like that this option is gone (can't find it in the GUI).

Is this functionality already implemented? I also haven't found anything in the docs...

[foggy]

Hi Michael, Sealed Mode for SOBR is not available yet. What you've seen is most likely referring to the inactive ("sealed") part of the backup chain that is offloaded to Capacity Tier.

[Gostev]

This is a v10 feature.

[mcz]

I have to disagree... I know for 100 % that my extents were in "sealed" mode and I could disable it in the gui. Luckily the daily mail of the SOBR status confirms the situation:



Also, you see the Version 9.5 at the bottom - so somehow it is part of 9.5 but it is hidden. Because until today I have no idea why these extents got sealed, I didn't do anything except a rescan and an import of an existing chain (which I removed previously). Can you please shed some light on that?

[veremin]

You're talking about read-only mode (that can be found by ctrl+right clicking on capacity extent). Currently it has a wrong label in SOBR daily report. This is known issue that will be fixed soon. Thanks!

[mcz]

Vladimir, good to know, thanks! Could you explain which process this read-only mode could enable? Because I didn't even know that it existed so I didn't enable it...

[veremin]

Are you the only person that has access to backup console? There are no processes that can enable it automatically, so, someone must have done that either via UI or via PowerShell (maybe it's been done accidentally - misclick or something). Thanks!

[mcz]

yes, I'm the only one. I mean we could argue that I made a mistake and misclicked in the GUI (haven't done anything via PowerShell) - but not on both S3 extent and both of them were "sealed" allthough it's the wrong term So it must have been caused by a veeam process...

[veremin]

Looks strange, indeed. Can you ctrl+rightclick on the given extent and disable read-only mode?

And if the issue re-appears, we will need you to open a support ticket (so that we can find what process has caused the problem).

Thanks!