Backup Copy to Object Storage vs. Scale-Out Backup Repository Copy Mode

[DVelez]

Can Object Storage replace Scale-Out Backup Repositories w/ Capacity Tiers for backup copies? Are there any advantages of one over the other?

Thanks!

[Gostev]

It can, but generally only for small deployments.

Disadvantages of Backup Copy vs. SOBR Capacity Tier:
1. Scalability limits of a single S3 bucket will require multiple Backup Copy jobs and manual workload balancing between them => higher TCO.
2. Multiple additional jobs to manage and monitor instead of fully automated SOBR tiering => higher TCO.
3. Archiving of GFS backups to cheap object storage tiers is not possible (available in AWS and Azure) => higher TCO.
4. No restore performance & restore costs optimizations (no reuse of matching blocks from on-prem repos of Performance Tier, everything has to be pulled from object storage) => RTO impact, higher TCO.

Advantages of Backup Copy:
1. You can potentially have a different retention policy for backup copies (longer or shorter than for primary backups) => enables small shops that are not a subject to off-site backup policies and regulations to save on cloud object storage costs. This means taking the risk of in-cloud retention being insufficient (for example, data loss or cyberattack spotted too late and all those few in-cloud copies are already useless).

[NightBird]

So it’s recommended to continue with SOBR with capacity tier ? And not use directly backup copy job to object storage ?

What do you mean for scalability of a single S3 bucket ? Number of object ? Capacity ?

Thanks

[Gostev]

You should decide based on your specific needs. If there was a universal "right" answer, we would not provide both options for example, we had a number of requests in this forum from small customers who only wanted to keep a few latest restore points in the cloud object storage to save costs, as sort of a "last resort" copy. For this particular scenario, and a small protected environment, most of the disadvantages mentioned above don't really matter all that much.

Most commonly it's the number of objects per bucket. Low bucket scalability limits is the usual problem for many on-prem object storage devices.

[NightBird]

In others terms what is a small deployement for Veeam ?

Let take an example
300VM (100TB) is a small deployement or not ?
BCJ to object storage or SOBR with capacity tier to offload to object storage ? (cloud object storage or Netapp StorageGrid/DELLEMC ECS for on-prem).

[Gostev]

Small is under 50 workloads. This is the actual license limit of Veeam Essentials, which is our offering for small businesses.

[cgsm]

With v12 supporting backing up directly to object storage, is it better to use SOBR to offload to an object storage repo or a Backup Copy job? Note: excluding any storage space constraints. Is either method better?

In v11, I set up a local repo (performance) and Wasabi (capacity) via SOBR. Now, with v12, I am investigating breaking apart the SOBR and treating the local repo and Wasabi object storage as more separate repos and job. Why would I break apart the SOBR and use a Backup Copy job instead...allowing for excluding come VMs from being copied to object storage, separate retention policies, and some other configuration settings.

[Mildur]

Hello cgsm

I moved your question to this topic. Please see the comment from Anton.
If you want to have more flexibility, using Direct Copy to object storage would make sense for your project.

Just as a note, Capacity tier and Object Storage repositories are not using the same format. Your backup copy jobs would require to start with a new bucket and active full uploads.

Best,
Fabian

[pirx]

As we still have quite some issues with SOBR offloading and we are moving to Wasabi, I'm also thinking about how to get our immutable copies to Wasabi in future.

I've understood most of the mentioned (dis)advantages, not sure about the space utilization in capacity bucket vs. copy bucket. One other thing that is not clear to me is how/if active/synFull backup will work for copy jobs direct to S3/Wasabi. Especially synFulls, will this be done as with any other performance tier? We have seen how bad this can be with our slow NAS devices on-prem. Note: I configured my first Wasabi bucket as performance tier in a SOBR to be able to add additional buckets for scale later. In this setup, if I choose the SOBR as destination in copy job, I have to usual options to either perform a synFull or the checkbox for "Read entire restore point...." which is active full.

[tyler.jurgens]

For Direct to Object:
Synthetic full backups are essentially just yet another incremental, but the objects that go into that synthetic full backup are just tagged to last for the duration of that retention policy.
Active Full backups will take a new full backup and store those objects in your object storage.

For SOBR offload:
Synthetic full backups are essentially just yet another incremental, but the objects that go into that synthetic full backup are just tagged to last for the duration of that retention policy.
Active Full backups are essentially just yet another incremental and tagged to last for the duration of its retention policy.

Whether these differences are important to you is up to you to decide!

With either method, there is no backup merging or anything of the sort. It's just objects. Objects as far as the eye can see. All of this is very different compared to the block-based storage from before.

[dhayes16]

Hello...Just to chime in here for some guidance...We have mostly smaller workloads...Max 10 VM's with maybe 2TB max of VM storage. We had fully planned to move from SOBR to direct to Wasabi on the copy jobs when V12 was released but we started to rethink our strategy. For most sites, we have Linux-hardened Repos with 8TB of storage and the ability to store TONS of GFS restore points for years via XFS block cloning. Our intent was to just use the Wasabi Object for maybe 30 restore points in the event of a disaster. But we started to think what happens if the Linux-hardened repo dies and we lose all those restore points so we started looking at the SOBR again. Sorry if this is a basic question but does Object via Wasabi have the same block cloning as XFS/ReFS (IE: Spaceless fulls)? We are thinking we might be penny-wise and pound-foolish to save a few $$ just to provide a 30-day-only retention.

Thanks for any feedback
Dave

[dhayes16]

I think I answered my own question...I checked one of our Repos with a Linux Hardened Repo and it shows 2.6TB storage used but via block cloning it is using about 780GB both on the Hardened Repo and in Wasabi.

So I am left wondering what the downsides are in this situation from a purely storage (usage/cost) standpoint of using an On-prem Linux Hardened Repo with a Wasabi Capacity tier via a SOBR if it does such a nice job of block cloning on both platforms aside from being able to define separate retention policies. Even for smaller workloads.

Again, sorry for the seemingly basic questions but I am just curious.
Dave

[tyler.jurgens]

Object storage has the same kind of block cloning as XFS, since Object Storage only stores new/changed blocks. From that perspective, its the same.

I personally find Backup Copy Jobs easier to understand than SOBR offloading. All the same kind of thing you know and love. Where SOBR offloading can be great is if you want to do something like an Archive tier on top of Capacity tier. With either method, you get essentially the same kind of block cloning/space savings, so the costs should be the same.

[danderson]

When we started using VBR back in v9 days we had to use SOBRs in order to offload copies of our backups to Azure blob storage

We currently have a SOBR which contains one NAS repository as the performance tier and one Azure repository as the capacity tier. The SOBR is set up in 'Copy' mode so that a copy of all backups which exist in the NAS repository are copied and also exist in the Azure repository - 2 copies of our data with 1 offsite (part of our 3-2-1-1-0 strategy).

We have recently upgraded to v12.1 and now with the advent of 'direct to object storage' capabilities, is there any reason why we need to continue using SOBRs with our backups (ie using SOBRs in the 'Copy' config) ?

Would separate NAS and Azure repositories together with multiple Backup Copy Jobs be a better way of storing multiple copies of backups in multiple locations taking into account the possible need to relocate / transfer backups in the future - either on-prem to a new, larger storage appliance, or transferring between cloud providers if the decision to switch is made ?

What are the pros and cons between 'Copy' mode SOBRs vs separate repositories and multiple Backup Copy Jobs ?

[Mildur]

Hello Dave

Welcome to the forum. I moved your question to the existing topic.

Please see the previous comment from Anton Gostev.

or transferring between cloud providers if the decision to switch is made ?

Migrating backups between object storage providers is easier with "direct to object storage jobs". You can use our Move backup feature. Just be aware of the costs when you use Azure now and you want to migrate all backups to another object storage service provider. You will have to pay for data egress and a huge amount of API calls to copy the backups from Azure.

Best,
Fabian

[sfirmes]

Advantages:
1. You can potentially have a different retention policy for backup copies (longer or shorter than for primary backups) => enables small shops that are not a subject to off-site backup policies and regulations to save on cloud object storage costs. This means taking the risk of in-cloud retention being insufficient (for example, data loss or cyberattack spotted too late and all those few in-cloud copies are already useless).

As Anton noted earlier, the only reason I see folks use backup copy jobs vs sobr offload is the ability to change the retention to be longer in the 2nd copy. And in the majority of those cases it was using on-prem storage object storage solutions and the customer wanted to keep their GFS backups for a longer duration than the performance tier.

Now with VBR v12.1 on-prem object solutions with a "cold storage/deep archive" capability can be used as an archive tier. With this new VBR capability, the reason(s) to use backup copies vs sobr offload are dwindling.

Hope this helps.

Steve

[jazzoberoi]

Hi Sfirmes,

We've got a situation where we're looking to achieve the following:

1. Primary Backup to LHR (7 Daily, 4 Weekly, 12 Monthly) all immutable
2. Secondary Backup to Wasabi S3 (7 Daily, 4 Weekly, 12 Monthly all immutable) but also 10x yearly (non-immutable)

How best do we go about this scenario?
- Utilise SOBR?
- Utilise 2 seperate repo (LHR+Wasabi) with Backup-Copy to Wasabi?
- Utilise 2 seperate repo (LHR+Wasabi) with 2 seperate backup jobs?

[jazzoberoi]

Just came across this post - https://community.veeam.com/blogs-and-p ... art-7-6757

Just to give some background on our topology:

Linux Hardened Repo:
- Location: Melbourne
- Inter-Site LAN Speed: 1gbps
- WAN speed: 10gbps

Primary Infra: (this is also where the VBR and Hyper-V cluster is located)
- Location: Sydney
- Inter-Site LAN Speed: 1gbps
- WAN Speed: 10gbps

Wasabi S3:
- Location: Sydney
- Accesible via WAN

========================================

Is there a scenario where the following can be done:
- Utilise 2 seperate repo (LHR+Wasabi) with Backup-Copy to Wasabi.
- Primary backup (sydney to melbourne) goes to LHR via 1gps, but the backup copy goes to wasabi via WAN from 'Linux Hardened Repo' over 10gbps?

Secondary Backup-Copy to Wasabi S3 (7 Daily, 4 Weekly, 12 Monthly, 10x yearly (all immutable but in Governance mode), so if we need to delete older backups we can do so as per the blog post from wasabi?

[sfirmes]

so if we need to delete older backups we can do so as per the blog post from wasabi?

Jazz, enabling governance mode is something that only service providers should do. In your case you want to delete "older backups", but by enabling governance mode a bad actor won't differentiate between "older" and "all" backups. For that reason alone, I would recommend you continue to use compliance mode.

As I noted in my blog that you referenced, the governance mode is applied to the entire VBR server. Any existing compliance mode repositories can no longer be backup targets, but you can restore from them. For that reason, I would recommend that anyone who enables governance mode create a new "governance mode" vbr server.

Good questions and thanks for contributing!

Steve

[kyahwilde]

I have yet to find a good explanation of which i should use. I maybe overlooked it. If i want to just make sure i archive data for 10 years am i better off using backup copy vs sobr? I am unsure with gfs functionality how they differ. I would want local immutable for 7 days and pass the rest to the sobr tier if i am thinking right.

[david.domask]

Hi Jeff, welcome to the forums.

This is largely a matter of preference -- with Scale-out Backup Repositories (SOBR) and tiering, the main advantage is that the tiering job can help you manage the local data, clearing out the local data as it's offloaded with the Move operation, as well as access to Archive Tier.

With Backup Copy jobs, a copy would be made instead and the original data will be managed by the job retention only.

With SOBR, Capacity Tier and Archive tier are an extension of the original backup, and based on what you're telling, I think a Backup Copy Job with GFS might meet your needs better to maintain a smaller amount of data on the local repositories; the Move operation can only reclaim space for inactive chains, so you may end up with more than your preferred amount of data on the local repositories this way.

With Backup Copy, you can set the primary job to the desired retention and have backups on your long term storage.

But there isn't really a right way to do it, it's mostly a matter of what works best for you.

[Mildur]

Hi @kyahwilde

I have moved your question to the existing discussion.
In addition to David's comments, please also check out Anton's earlier comment in this topic.

Best,
Fabian