Hi Dika

I don’t think so as you would have multiple DB’s controlling it. You could have one VBR server and then leverage Enterprise Manager so you can access from other sites, then just install proxies, mount servers etc in all the individual sites.

While you can do this yes, it is not recommended as a best practice to share a repository server.  If you need to do this, you can but ensure that all the VBR servers are on the same version of Veeam otherwise if you have a newer release then it will update the Repository server and make it inaccessible to the other older VBR servers.  That is the only caveat.

Take a look at this thread too.

https://forums.veeam.com/veeam-backup-replication-f2/two-backup-servers-with-the-same-repository-t63954.html

Chris is right it seems you can do this, but I would not do it Life is too short.

You can do it as I am in my homelab but again not a recommended best practice.  If you have to do this, I suggest a separate drive in the repo server for each VBR or at least a different folder structure to tell them apart instead of one directory.

Yes, it can be done.  No it is not recommended. But a very slight change might work for you.

My recommendation would be that you create 3 separate folders on your backing storage, one for each repo, one repo for each server. 

If you use the same repo for all servers, note that all servers will see each others backups as imported/foreign objects (or encrypted objects if your backups are encrypted) because it has no information about those restore points in it’s own database but it will see those restore points in the repo.  While that might be handy for restoring a VM from a different VBR server at one location to a different location (strange use case, but the only advantage I can come up with) and it can be confusing for sure.  I can’t speak for what Chris is talking about regarding repo’s being upgraded and inaccessible to not-yet-upgraded VBR server’s, but it generally seems like a bad idea.  I can’t imagine if the entire repo is encrypted what kind of havoc that could create - might be okay, might not be, but I wouldn’t want to find out in production. 

I did have an environment where I had two different versions of VBR going to the same repo for a bit, the older VBR existed because an older version of Veeam Agent for Windows was using the repo and we couldn’t easily upgrade at the time.  This is why, if you need to use the same storage, I’d at least have a separate folder for each repo and have three separate repo’s independently of each other. 

And as previously, noted, Enterprise Manager will make this easier and may be required depending on how your servers are licensed.

at first, I also think about putting backup repo (data domain) on each site and using data domain replication from dc to dr but it will cause extra budget to make it.

actually I will use enterprise manager on DR to manage licensed and also backup tasks

at first, I also think about putting backup repo (data domain) on each site and using data domain replication from dc to dr but it will cause extra budget to make it.

actually I will use enterprise manager on DR to manage licensed and also backup tasks

You could do DD in each office and then replication between them yes.  But again, it depends on your requirements and budget.  Let us know how things go.

I may be misinterpreting what you’re asking, so forgive me if I am. But, it appears, at least based off your diagram, you may be asking if your whole storage array can be used by multiple VBR servers. Is this correct? You can use a whole array with multiple VBR servers with no issues, *if* you use your storage like I do. I’m not familiar with DD, but I assume it’s fairly similar to any storage array, & what I use → Nimble storage. You can create chunks of storage (Volumes) and point them to whatever Repo with a given iSCSI IQN or FC WWNN, which is then assigned to a given VBR; then create other Volumes pointed to other Repos which are apart of another VBR server. And again, using whatever connection protocol - IQN or WWNN. With this, you have isolation & no possibility of overlap of differing VBR servers/Repos. There is isolation by connection protocol.

As already mentioned by basically everyone on this thread  I definitely would not recommend having multiple VBR servers share an infrastructure component (in this case, a repository). Not only for potential version mismatch issues… but for concurrency and resource management as well! Every VBR server will set their own number of concurrent tasks for the repo… but of course it will not be “aware” of other tasks assigned to the repo by the other VBR servers! You could easily end up overloading the shared repo.

Looking at your diagram, I would second @coolsport00’s suggestion: you can create different Storage Units / Mtrees (exposed via different interfaces / on different networks) and assign them to different Gateway Servers, each of them managed by a different VBR server. Starting from VBR v12, you can even pool them for added resiliency and performance (they are leveraged in a round-robin fashion). So for example you could have 2 pooled Gateway Servers for each VBR server, for access to the DD Storage Unit dedicated to that VBR server.

Gateway Servers can be physical or virtual, at the moment only Windows machines are supported as Gateways for deduplication appliances. Virtual is of course easier to manage, but physical usually gives you the best performance (by leveraging DDBoost over FC protocol).

A possible caveat is that in general, it is advised to have the Gateway Servers “as close as possible” to the actual storage target (the DD in this case). This would mean provisioning them in the “DRC” site, where the DD also is. Shouldn’t be much of a problem if the network is good between sites.

I would also suggest reaching out to your preferred Veeam certified partner and/or Veeam presales (SE / SA) for design guidance of your environment.

Also keep in mind a DD is a deduplication appliance so any restores will be slower than regular repo servers or other storage. Something else to consider in the design.

exactly i’m not familiar with DD too but as you mentioned before, with nimble storage we can make some volumes on it and assign those volumes as backup repository ? 

Yes you can do that via iSCSI or whichever fabric you have.

Why not just have a proxy at each DC and use 1 repo at the DR site? You only need 1 veeam server in that case to manage it.

If you want all your data on one repo, security isn’t the reason so this makes the most sense. If you want 3 veeam servers, you want 3 repos. You can use enterprise manager to manage the veeam servers if you want.

In this situation I’d recommend a single Veeam server and 3 proxies.

If you use a SAN, you could carve out multiple areas and potentially use 1 SAN as 3 repos, but it’s not as good of use of space.

I have multiple sites and a repo at each site, if all sites went to a single site i’d still only have 1 Veeam server and proxies everywhere.