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:
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 (applicable to AWS/Azure only) => 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:
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.

[tjurgens-s2d]

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

[tjurgens-s2d]

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.