![]() ![]() ![]() Officially we support this scenario only in sitautions where each Nimble get an own B&R Server and you decide what is processed on what side. If you can live with the mentioned side effects and that we can not guarantee on which storage we process snapshot and their deletes then there is no risk other than this. ![]() As we can not guarantee the outcome it is "unsupported" to add both storage management endpoints to the same Veeam server. As you said it worked 95% of the time for you. If you add both system to the same Veeam Backup Server, then it is "random" on what entry in our list we find first and create the snapshot on this management entity. Veeam is not aware of this situation (we do not correlate that this volume is served by 2 different storages). Instead of having as well one storage management endpoint, Nimble has 2 management endpoint for this volume. Nimble Syncronous Replication serves the same volume (with same volume ID) from two different systems. Last question, is this officially going to be in v12?įor the "Volume only" setting needed for VMware (as outlined in the Nimble best practices guide for VMware): I would find it as well better if Nimble would switch the standard to "Volume only" when new volumes are created to follow their own best practices (has nothing to do with Veeam, we are just affected by the default setting not being the best practices for VMware). What else am I missing besides an occasional snapshot left open, which seems mostly harmless as long as they are cleaned up? I also don't understand why one array pair never has a problem while one does but I suppose i can file that under "not supported". Is there any 'danger' in continuing to run like this? Veeam can only access snapshots, and the esx hosts can only see Volume Only, so I would think not. So I guess my question is, I have Veeam and synchronously replicated volumes that I need to back up. Per my support case "There is an issue with Veeam indexing the arrays and often sends the offline request to the wrong array, causing the snapshot to be left online and undeleted" They are easy enough to clean up, just annoying. We have another replicated setup (two different arrays at a different site) that works 95%, but will frequently leave behind online snapshots. We have a synchronously replicated setup that has been running for ~2 years without a problem being backed up with Veeam. The workaround is easy provided you remember to do this at volume creation. Yes, we found this out the hard way too. Per the prior comment in this thread: "The solution for us was to change the volume presentation on the Nimble systems from "Volume and Snapshots" to "Volume only". I'd like to understand what specifically is not supported as it generally works great for us. I was brought to this thread by a support case after finding out after 2 years of successfully backing up synchronously replicated volumes from storage snapshots that its "not supported". ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |