V12: sealing extent in capacity tier

[mcz]

One question guys: Currently I'm using a SOBR with an object storage as capacity tier. Now that bucket is quite far away and I'd love to use a new one which is closer to our location. Now that I can add multiple buckets to that SOBR, can I seal the old extent in v12 and start using the new one? does that work or is that scenario not possible? Thanks! PS: If needed, please split this post into a new thread (not sure about it).

[HannesK]

Hello,
as the question had nothing to do with Linux repositories vs. object storage, I split the topic, yes

Yes, sealing extents with object storage works the same as for classic repositories in V12. For performance tier and for capacity tier.

Best regards,
Hannes

[jshapiro]

This question caught my eye, because I have a dilemma in Veeam B&R v11. I have a SOBR. My object storage didn't provide object lock, but now the provider introduced object lock buckets, and I want to transition. In v11, the only supported method to transition would be to import the contents of the first buck back to the performance tier and then push it to the new object locked bucket. I don't have the bandwidth to do that and I don't have the local storage, but I'd sure like to take advantage of the new immutability option.

If I wait for v12, would I be able to seal the old non-immutable bucket and introduce a new bucket supporting object lock to the SOBR? This would let me easily transition to immutability. My old repository would stay sealed and drain over time as the GFS retention limits for the oldest backups are reached. Eventually I could remove the old storage bucket altogether. Meantime, while I have both buckets, I could restore from even the old, sealed extent. This would be a huge help.

Also, how many object storage buckets in the capacity tier will be supported in v12?

[veremin]

Also, how many object storage buckets in the capacity tier will be supported in v12?

No artificial limit.

If I wait for v12, would I be able to seal the old non-immutable bucket and introduce a new bucket supporting object lock to the SOBR?

Most likely, not, as Scale-Out Backup Repository would require the same immutability settings for all extents added.

Thanks!

[jshapiro]

Even if the one is sealed and no longer being written to?

Any other way for me to transition to an object lock bucket then?

[veremin]

Even if the one is sealed and no longer being written to? ?

Correct.

Any other way for me to transition to an object lock bucket then?

Create a new Scale-Out Backup Repository with immutable extents.

Either way, let's postpone the discussion about the yet-to-be-released product version (and migration options it will have) until it goes GA.

Thanks!

[jshapiro]

Hoping for the necessary functionality when v12 releases. Otherwise, I'm looking at doubling my storage both on prem and in cloud to start with a fresh SOBR. Probably not worth moving to immutability for me otherwise.

Thanks.

[veremin]

The space increase will be only a temporary issue, meaning once the new chains land and reach the specified retention on the new repository, the old one can be decommissioned. Plus, I'm not sure how transitory storage consumption growth affects the data protection requirements (either backup should be immutable or not). Thanks!

[Dream_On]

Is it OK now to ask technical questions about V12?

[HannesK]

Hello,
yes, one can always ask about V12.

Please ask them in a new topic if it's not about the current topic in this thread.

Best regards,
Hannes

[veremin]

Is it OK now to ask technical questions about V12?

It's always OK to ask a question here, but we might not necessarily provide detailed responses for inquiries related to unreleased products.

Also, if you want to play with the particular feature of v12, you might want to reach your local system engineers and see whether they have open slots for third beta testing (that has started recently).

Thanks!

[jshapiro]

With V12 now out, I thought I'd revisit a question I posed in November when not everything was known. I have a Wasabi storage bucket in my SOBR that was built before Wasabi supported object lock and Veeam immutability. V12 introduces the ability to have more than one storage bucket in the capacity tier. I would like to know if I can transition to immutability by adding a Wasabi object lock bucket into my SOBR and sealing the original non-object lock extent. I would keep the existing sealed extent until the GFS retention drained the last jobs out of this extent. Is this feasible?

[mcz]

Jonathan, not sure about the option to seal the original object storage, but I know for sure that there's a need for a "full" on the immutable object storage. So at least that has to be taken into consideration.

[HannesK]

Hello,
no, it gives you the following error:

Code: Select all

Specify capacity tier extents with the same immutability settings.

Best regards,
Hannes

[jshapiro]

That is unfortunate. I'm still looking for a way to transition to immutability.

[mcz]

Hannes, what about the VeeaMover? Is it possible to move backups to immutable storage? If so, it should work in this case as well, right?

[jshapiro]

I just read a quick blurb on what VeeaMover is, and this sounds very interesting. While I don't know if this could be used to move from a non-object lock bucket to an object-lock bucket (I'll let someone else chime in on that), my concern is that it would be costly bandwidth-wise. I'm assuming that VeeaMover would have to download the object data to push it back to another bucket. If there was only 1 or 2 TB of data in the bucket, it might not be so bad, but with 120 TB of backup data, this would take far too long.

[HannesK]

I recommend reading the What's New document: https://www.veeam.com/veeam_backup_12_0 ... new_wn.pdf

While I don't know if this could be used to move from a non-object lock bucket to an object-lock bucket

it just works

VeeaMover moves between repositories and is also leveraged in evacuation / rebalance of scale out repositories.

In the situation of switching from mutable to immutable capacity tier: download everything and upload everything is the way to go. Immutability cannot be enabled on existing buckets. Even if the service provider could do it, that would be unsupported (documented in the user guide)

[jshapiro]

Thanks for the link to the What's New guide. I'm sure the mover is a good tool, but I can't possibly pull 120 TB back and push it to another bucket. Not enough bandwidth to spare. I was really hoping that I could seal the old bucket and swap in an object lock bucket. Even if I start with a new full backup chain, it appears that can't be done either.

Short of discarding my original bucket and starting over, it appears there is still no easy solution for me to transition to immutability.

[mcz]

But you can remove the existing object storage from your SOBR, so you could start with the new immutable there, so one box ticket. For the "old" object storage, just import the backups - by doing so, you'd reach the goal you've described in your latest post...

[jshapiro]

This sounds like a possibility. If I seal and remove the old non-object lock bucket and swap in the new object lock/immutable bucket, what will happen when Veeam rescans my SOBR? I presume It will see the capacity content as missing. Will it mark those restore points as gone? Will it offload new chains as part of the GFS retention scheme? Do I have to force a new full backup to ensure a new and complete chain starts and offloads into the new bucket?

As you said, the old bucket is also importable, and I presume I can use that as recovery points if needed. Will the GFS retention scheme slowly drain the content of the old sealed bucket, or would the GFS tags no longer be applicable since it isn't part of my SOBR?

[mcz]

I'm not having an answer to all of your questions, but I did exactly your scenario 2 years ago. When you remove the existing object storage, veeam would either remove the backups from the config or show them as unavailable - not sure about the outcome here, but I think the first one would happen. After that, it should offload/copy the existing backups in that SOBR to the object storage.

If the retention is applied to the old backup depends on where that backup would be visible - if you see it under "orphaned", retention should be applied, but not if it's under "imported".
Maybe you can clone your backup server (vm) and do that test in a lab (without network connections), or maybe just import the config on a new vm...

[jshapiro]

I swapped in my new object lock bucket, and I removed the non-object lock bucket. Latest backup chains offloaded to the object lock capacity tier. It took about a week to catch up. Meantime, I imported my old bucket so it would be available for doing restores. The GFS retention tags are there, but because this repository is not part of the SOBR, Veeam won't do any automated pruning of older backups. It is up to me to manually delete select servers. Unfortunately, there is no way to prune select restore points for a server. You must either keep or prune all restore points for the server at once. This is a tedious and slow process. I will keep this imported repository for some months until my new bucket accumulates more restore points. There is one other thing I can do with this imported repository. I can export select restore points for any server to the other bucket. This is kind of cool, but it is slow. You can only select one restore point at a time to export. This is probably not practical for salvaging key restore points in most cases, but it is useful to pull a handful.

In any case, I have achieved my goal of transitioning to immutability (currently set at 30 days).

[mcz]

In v12 you should be able to export more than one backup in parallel...