The backup server should not have to do any reading or writing as the Synthetic backup is created from the restore points on the current repository as per - How Synthetic Full Backup Works - User Guide for VMware vSphere (veeam.com)

So traffic should not traverse your WAN.

Hi @Mike Schlottman -

Welcome to the Community Hub. Chris shared how Synthetic works, (all the “work” is done on the Repository storage). As for your specific question about placing the Synthetic Full data on all your Linux servers….well, I assume all 3 at the remote location will be used as Performance Tier in your SOBR? A Full is just 1 file, a .vbk, so it will only be on 1 of your Perf Tier extents. In the User Guide, I didn’t see any limitations when using Immutability with SOBR that would dictate placing files across all extents or not. As such, how the remaining backup chain file placement is decided is based on your choice of Data Locality or Performance for backup file placement, which you can read more details on below:

https://helpcenter.veeam.com/docs/backup/vsphere/backup_repository_sobr_placement.html?ver=120 

I think that answers both your questions? Let us know if it’s not clear.

@Mike Schlottman -

I also highly recommend reading up on how retention works with immutability, if you haven’t already. Just as an example, say you set your backups retention to 14 days with immutability enabled and configured for 14 days (default and minimum I believe is 7 days). Then your actual retention on storage before stale restore points are removed is 28 days. Now, if you’re using Fast Clone tech (hope you would), this won’t be too bad as it would without using FC, but storage will still be affected. So just keep that in mind. In case you haven’t looked at how retention works with immutability, see below:

https://helpcenter.veeam.com/docs/backup/vsphere/hardened_repository_immutability.html?ver=120

And here’s another section on Immutability on Performance Tier:

https://helpcenter.veeam.com/docs/backup/vsphere/hardened_repository_sobr.html?ver=120

Hi, Chris.   Thanks for your response.  I’m pretty familiar with the workings of Veeam but the Linux Repositories are new to me, so it wasn’t clear that there was much intelligence to them.  If I have 3 Linux Repositories in a SOBR, the last VBK is on one repository and the VIBs get mixed across all 3 extents, when it comes time to create the new synthetic full, the traffic will have to traverse the network between the 3 Linux Repositories.   I had not taken this into account when I first thought of going this route so I thought gigabit ethernet would be fast enough for me.  Today the same is true for the extents in my direct attach storage, but that traffic is passing across high speed SAS interfaces.   I suspect I will need 10Gb ethernet between my Linux Repositories to avoid long delays in building synthetic fulls.

Hi Mike -

I’m actually Shane  So, if you’re using Performance placement policy for your SOBR, yep..you have it correct then. Traffic will traverse your LAN the Linux Repos are on to retrieve the blocks needed across all the extents to create your Synthetic Full. But even so, I don’t think there’s really much writing going on if you are using Fast Clone because that technology uses “pointers” to blocks of data needed to create your Synthetic Full. Did you configure your Hardened Repos with XFS file system, and when you added them to Veeam did you enable Fast Clone? Even so, I do recommend 10Gb at a minimum, as implementing multi-Gb networks isn’t really a great expense anymore these days.

Sorry, Shane.   Too many windows open today.  It sounds like I will be better off to disable performance placement to keep all backups on a single Linux Repo.  This is still in the planning and testing stage, but I plan on enabling Fast Clone.   Are you saying Fast Clone can utilize XFS on different servers to speed up network transfers?   I thought that was limited to block cloning on the file system.

Your explanations have been helpful and I think as long as I disable Performance placement, I should be fine.

If you do that might as well just use STD repo not a SOBR.  Just easier in this case.

Hi Mike - all good man. No….Fast Clone is basically Block Clone. So, you have it correct. But if you have that configured for your all your Repositories, even in a SOBR, it should still just use pointers to all the needed data. No data should traverse the LAN for the Synthetic. You can verify either with Support, or ask the PMs in the Forum.

Personally, I recommend using Data Locality. It’s just easier imo  I don’t use SOBRs anymore, but when I did, I used Data Locality policy. And if you do...as it appears you’re deciding to do, then that whole discussion above is moot 

Best.

And Chris has a point there too. One of the reasons I initially enabled SOBRs is for backup file movement in case I needed to do ‘maintenance’ on a Repo. I could just move them to a 2nd extent and do the maintenance I needed. But, the file movement is no faster than if I created a whole other Repo when I needed it and move files via Windows.

The real benefit of SOBR imo is for the 3-2-1-1-0 Rule and having copies of data copied or moved to Capacity Tier (or to Archive Tier). If you have an object appliance local to your DC, or if have in the Cloud, you could keep a copy of your data on your object storage.