I didn’t envision this to be a replacement for datacenter migrations… however with some more testing it may actually be a decent option. I should mention that the only reason that you would want to use the Read only copy to do a restore is if your primary site if offline and you need your data back. Lastly is a dashed directional line showing that “if” a restore of data needs to be done at the opposite site, the local Veeam server has a read only copy from the replicated DD MTree. You will notice a line with arrows at each end between the local Veeam master server and its DDBoost repository, meaning primary backup and restore data flows between them, then a directional arrow between the primary MTree and the replicated MTree showing the direction of DD replication. So here is what things look like: (click for pdf version)īasically what I have tried to do here is show the backup data path. (However this can be automated with this powershell script ). So you do have to preform a manual “Re-Scan” of the CIFS repo so that it pulls in the latest restore points. Because Veeam is not actively writing backup data to the CIFS read only share, it does not automatically import new backups that have been replicated. one CIFS mounted repo called “Veeam-east-replica”.one DDBoost integrated share called “Veeam-midwest”.The midwest Veeam “master” has the mirror of this: one mounted via CIFS called “Veeam-Midwest-Replica”.one mounted via DDBoost integration called “Veeam-east”.So the east coast Veeam “master” server has three backup repositories: Sooo I thought why not just share out the replicated MTree’s via CIFS and have the Veeam “master” mount that share. However! the Data Domain box WILL still let you share that read only folder via CIFS or NFS. The replicated MTree’s are placed into a read only mode by default. So that takes care of backing up locally, and getting offsite replication… but the cool part is how we can do restores of data from the opposite datacenter… Then that MTree is cross replicated to the east coast DD MTree called “veeam-midwest-replica”. Local Veeam “master” server does backups via DDBoost to its local Data Domain in an MTree called “veeam-midwest”. That MTree then uses native Data Domain replication to the Mid-West Data Domain to an MTree called “veeam-east-replica”. Local Veeam “master” server does backups via DDBoost to its local Data Domain in an MTree called “veeam-east”. The idea is pretty simple… Use a Veeam “master” server at each site for local backup and restore as well as ALWAYS have restore’s pulling data from their local site’s data domain regardless of where the VM was originally backed up. The solutionīecause we had Data Domain replication in place I decided to see if there would be a way to mount the replicated copy in read only mode to the local Veeam “master” server. Now for full VM restores I don’t think it would be quite as bad because we can specify a proxy at the remote site to do the full vmdk restore in hotadd mode… that will keep all the data local and it. We were getting about 50Mbps on the wire while the mount operation happened… but from the local data domain we were getting almost 300Mbps. What we found is that because the file level restore happen on the “master” Veeam server it took incredibly long to mount backup images from the east coast Data Domain to our midwest Veeam Server. The disadvantages were much more obvious. The only real advantage to having a single veeam server is that all jobs were in one pane of glass and all restores could be started from one area. There are advantages and disadvantages to each setup.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |