#Best Practice
1 messages · Page 1 of 1 (latest)
There is nothing specific for the SnapCenter server itself, but there are Best Practice Guides for a number of plug-ins.
MS-SQL: https://www.netapp.com/pdf.html?item=/media/12400-tr4714.pdf
Oracle: https://www.netapp.com/pdf.html?item=/media/12403-tr4700.pdf
SAP-HANA: https://docs.netapp.com/us-en/netapp-solutions-sap/backup/saphana-br-scs-snapcenter-concepts-and-best-practices.html
Thanks Scott... Are you an SC SME? I'm concerned about putting the SC VM on the same infrastructure it is protecting. Would it be better to separate it?
I am an SME for the SC product, but I'm not an architect to understand the nuances of whether the SC VM would be better located in one location vs. another. I'm sure there are pros and cons to putting it in the same hardware vs. putting it in a different datacenter. Honestly, even if I could list out the pros and cons for you it would still come down to a decision of which pros and which cons are most relevant to your own situation.
For anyone else reading this, what kind of installation are you using and what is the good, the bad, and the ugly about it?
Thank you. I think we will not worry about it. Our HA-Pair is very stable, and if it fails, well, so will everything else. However, I think I may create my C: drive in my standard DS, and create a separate DS for the repositories.
@kind hound Hope I'm not being a nuisance... But as regards back and DR of the SC server; If I've been reading docs and searching the site, it appears that MySQL dumps to the repo directory. But if I build SC as a VM, can I snap it and SnapMirror? If I do that, should I keep all of the SC server on its own NFS DataStore, or is it safe to place with other VMs? And can I use SC to back itself up and SnapMirror?
There is an automated backup process of the SnapCenter repository. See https://docs.netapp.com/us-en/snapcenter/admin/concept_manage_the_snapcenter_server_repository.html#prerequisites-for-protecting-the-snapcenter-repository for more details on how to set it up and what it does.
@visual bluff @kind hound Hey guys I'm back about SnapCenter for VMware (SCV) and SVM-DR. So here goes:
My guys don't use the DR arrays to recover with, they only use the primary (for now).
My thought is that if I were to create inconsistent VM snapshots throught the day, say three or four of them, and then create a consistent ESXi snapshot at 20:00, I could then use SVM-DR to transfer my snapshots to the DR arrays at 23:00.
-If I were to create a volume-vault relationship, SCV would kick it off after every snapshot, during prime time.
Continuing my previous diatribe, I would need to manually copy back the VMDK's from the DR datastores if I needed to recover a VM.
For applications, I would use a different SVM with volume-snapvaults, not SVM-DR. Those would not be backed up more than twice a day, with consistent snapshots.
Do you guys see an issue I am missing? BTW, I was SVM-DR'ing all my datastores previously, but trying to be a good citizen now... well, not really...
Thank you
Answering since I was tagged, but SVM-DR is newer than my time as an admin, so take it with a grain of salt.. I guess from my point of view, copying back from another array should be a last resort - so keeping local snapshots for a couple of days would be my preference.
Yes, of course. The idea is to keep two weeks on the primaries, 1 daily consistent, and 2 or 3 inconsistent. They will be vaulted to secondary for longer term retention and DR. I'm not looking for approval, more of a sanity check. My VM people do not want to touch the DR systems, nor do they care about application backups. So I am kind of trying to design my own blueprint. Thanks @visual bluff
I don't see any problems with your logic of how this should work.