![]() Whatever you do, please don’t use DOMAIN\Administrator for everything! Additionally, other security contexts shouldn’t be able to access the backup storage other than the account(s) needed for the actual backup operations. The username context that is used to access the backup storage should be very closely kept and used exclusively for that purpose. This is a generic best practice and in the ransomware era it’s more important than ever. Use different credentials for backup storage The goal here is to provide options which you can implement as you see fit. Not using Veeam yet? No worries, you can take this advice and implement it accordingly.Īdditionally, it’s important to note that there is no one-size-fits-all strategy to protect your backup infrastructure from ransomware. Here are a number of tips I’ve prepared to incorporate into your designs, both new designs and existing designs using Veeam. That’s the Availability you want when things don’t go as planned, should ransomware become an issue in your data center. One important part of being resilient to ransomware is being able to recover from backups. Here at Veeam, we see customers and partners encounter ransomware in a number of situations including the data center. ![]() I would also suggest reaching out to your preferred Veeam certified partner and/or Veeam presales (SE / SA) for design guidance of your environment.The ransomware threat is real and it’s much more than just a PC problem. Shouldn’t be much of a problem if the network is good between sites. ![]() This would mean provisioning them in the “DRC” site, where the DD also is. Virtual is of course easier to manage, but physical usually gives you the best performance (by leveraging DDBoost over FC protocol).Ī 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). Gateway Servers can be physical or virtual, at the moment only Windows machines are supported as Gateways for deduplication appliances. 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. Looking at your diagram, I would second 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). 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. ![]() ![]() 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.Īnd as previously, noted, Enterprise Manager will make this easier and may be required depending on how your servers are licensed.Īs 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). 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. 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 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. 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. 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. My recommendation would be that you create 3 separate folders on your backing storage, one for each repo, one repo for each server. But a very slight change might work for you. ![]()
0 Comments
Leave a Reply. |