Skip to main content
  • EN

I’m going to be likely setting up a new client on a VBR VM with a local NAS as their primary repository (I know...I’d rather do a purpose-built physical server but cost is an issue) and Wasabi object storage for an off-site copy (and likely replication to 11:11 Systems VCC for DR).  I’m curious now that we have backup to object and copy to object capabilities, what you folks are doing for that second copy?  Traditionally I obviously have used a SOBR using Wasabi as the capacity tier in Copy mode (move mode disabled *usually*, but I just noted that I’m performing copy and move for my internal server) so that I had the data in both locations. 

However, now that we can backup and copy direct to object, curious if anyone has abandoned the SOBR and are instead using a copy job to send data to the object storage and are keeping the data there with the traditional copy job managing things.  @Nico Losschaert posted a debate about the pro’s and con’s of this a couple years ago at the below link, but that was copying to VCC storage vs a SOBR capacity tier, and was before we could copy direct to object.  Some of his points still stand (monitoring, cost, licensing, WAN Accelerator) after a cursory review of his post, but I’m curious what you are doing and why or why not go another route?

 

Depends on the use case. When using Backup Copy jobs, running an active full on direct to object will push all blocks. SOBR offloading it only pushes changed blocks still, so you do save size with SOBR offload, but you don’t get a brand new active full in your object storage. Whether that is an issue is up to you. SOBR offloading also gives you that benefit of the archive tier.

 

I personally find running backup copies easier to manage because its the same thing you’ve been using for years with Veeam. SOBR offloading is a different, so its takes adjustment to understand what storage exists where and for with many restore points. Also might be easier to prune as well - just adjust the retention on the BCJ and away you go (accounting for immutability of course).

With direct to object now we are slowly moving away from having capacity tier from SOBR and using backup copy direct to object.  So much easier for management and getting things set up.  Also more control as well and we are now using Immutability so need better way to control retention for clients.

Personally, I also prefer Copy Jobs to Object Storage. I like to use SOBRs as primary repository but without object storage tiering.
I always felt that SOBR was unnecessarily complicated. For me, two separate backup paths are always better.
First Production VM Backup to SOBR Repo, second Backup copy to S3 with immutability.

The masses have spoken….down with SOBR.  But it still holds a special place in my heart…..

I missed this post. Thx for mentioning my post @dloseke 😁.

It all depends on the case in my opinion. All solutions have their pro’s and cons.

 

I missed this post too, be interested to hear how you’re getting on.

 

Some of the things to highlight are that backup copy vs SOBR tier gives you independent retention policies, you can also be more granular at a per job syncing to object storage instead of permitted copy periods.

 

On the flip side you can still create a SOBR for your backup copy to offload to archive (not with wasabi of course unless you add a capacity tier or AWS S3 or Azure blob but you get the idea)

On the flip side you can still create a SOBR for your backup copy to offload to archive (not with wasabi of course unless you add a capacity tier or AWS S3 or Azure blob but you get the idea)

 

I appreciate this insight.  Alas, we don’t use an archive tier, so not an issue, but good to note for anyone who may find this post in the future.  We went with a copy job and haven’t looked back.

Since this post has a bit to do with BCJs, thought I’d piggy-back on here (hopefully ok Derek). What is the difference of using Immediate vs Periodic mode? What I mean by that specifically, aside from being able to transfer Logs with Immediate and not Periodic, why would one choose one mode over the other? Immediate isn’t really on a schedule, so I get that. Is that the only reason? Periodic is more flexible to schedule, whereas Immediate is solely dependend upon the Backup Job(s) it sources? Thoughts?

Since this post has a bit to do with BCJs, thought I’d piggy-back on here (hopefully ok Derek). What is the difference of using Immediate vs Periodic mode? What I mean by that specifically, aside from being able to transfer Logs with Immediate and not Periodic, why would one choose one mode over the other? Immediate isn’t really on a schedule, so I get that. Is that the only reason? Periodic is more flexible to schedule, whereas Immediate is solely dependend upon the Backup Job(s) it sources? Thoughts?

Remember Periodic copies only the latest restore point and not all like Immediate does too. 😉

Another reason to choose Periodic vs Immediate.

Ah yes...so space saver for Periodic.

Comment


Terms & Conditions