The only way to do this is using two jobs where one is local storage and the other is direct to object. As you noted the way around this would be to target a SOBR where you can have Capacity Tier enabled that goes to Object as the other method, but it seems like that is trickier. Another option would be to have local backup and then the second backup comes to your VCC server where you have a SOBR that is comprised of Object storage only, but again might be trickier for your scenario.
My apologies if this response seems scattered, but I was writing my response as I was reading it, and your last sentence is where I truly understood what you were trying to do.
I have the veeam service provider console and associated cloud connect server, and several single physical servers at different customer sites that I would like have a local backup + direct to object storage backup strategy for. I was hoping to use veeam agents on the physical servers and just use my console + cloud connect server to manage / monitor the backups. Ideally backup data would just go to the local storage at the same physical site as the server (NAS/external USB), and be uploaded directly to object storage without going through the cloud connect server.
This is how most of my clients are setup. They are running on either a physical server with local storage (my most recent and preferred method), or a VM that is attached to a NAS via ISCSI to the host as a RDM or direct to the NAS with the Windows ISCSI initiator (how we used to do it, and occasionally it still happens). I’m using the VSPC/VCC only for management/reporting of the backup jobs running on the local VBR servers.
I considered using a scale-out backup repository for this, but trying to configure a scale out backup repository on my cloud connect server, but I can’t have an extent be local storage.
In my case, each client has it’s only object bucket in Wasabi. Most are using a SOBR, but again on their local VBR server. In most cases there are copy jobs to a NAS at a second site as the performance tier, and the Wasabi object storage for the capacity tier, usually using the Copy type in the SOBR unless there’s not enough space on the remote NAS in which case it’s using Copy and Move. I do have one client with no remote site but wanted to utilize Wasabi before Direct-to-Object was an option, and wanted immutability, so they are using a SOBR as their local repo, again with the local disks for performance, and Wasabi for capacity. Their configuration backups go to a separate repo on the same server since config backups could not go to a SOBR. It sounds like you’re trying to to setup a SOBR on your VCC server to have your clients backup to your VCC and have it scale out to the object storage through your server.
I considered installing a backup server on the physical server but this seems like a bad idea given the backup server would be installed on the same device as the protected environment.
I’m afraid you’ve lost me here….I think...maybe not. For my clients using virtual VBR servers, yes, the VM resides on the same environment as the VM’s being protected. The backup data/repo resides on a separate storage array. It’s important, or at least helpful to keep the configuration backup somewhere else. For clients with remote sites, I keep the configuration database backup on that remote repo. For my clients using VCC via Iland/11:11 Systems, I keep it there. For those that don’t have a remote site/VCC, I use my VSPC/VCC deployment as they are allocated a 1GB VCC repo where they can keep the configuration database.
I considered a backup copy job but this also requires VBR.
I think I can just create two backup jobs with separate destinations - one local storage, one direct-to-object storage, but this is two separate backups.
What is the best way to accomplish a local backup + direct-to-object storage backup of a single physical server located at a remote customer site?
Okay, I’m pretty sure I’m following now with your last sentence. Apologies as I was working down your post and missed that.
Personally, I’d probably have a VBR server on-site. Doesn’t have to be much - could be an old workstation running a supported OS and connected to your NAS and object storage. Or as you noted, you could maybe run two backup jobs. Or, based on what I found when I was researching this, would be to backup to a VCC repo that is backed by a SOBR that is using object storage. I’ve never tried this, but I came across it here (not exactly what you’re talking about, buy you get the idea). If you want to use the existing NAS and don’t mind relocating it to where your VCC server is, maybe you could move the NAS into your datacenter and implement it into the SOBR.
However, I suspect you want to use the NAS on-premise so that you have a local backup for faster restores, etc. And in that case, I think Option 1 on having a VBR server on-site would be the best bet. I’d be curious to see if we can come up with any other/better options.
Thanks for the great responses, this is very helpful. Would it work if I installed VBR and an Agent on the same OS environment and tried to use VBR to back up its own physical server?
Thanks for the great responses, this is very helpful. Would it work if I installed VBR and an Agent on the same OS environment and tried to use VBR to back up its own physical server?
I hadn’t thought of that. I don’t see why it wouldn’t work. A little wonky, but I don’t think there’s anything that would technically prevent this from working.
Thanks for the great responses, this is very helpful. Would it work if I installed VBR and an Agent on the same OS environment and tried to use VBR to back up its own physical server?
Yes, that will work. I was testing something similar out and it worked like a charm.
