#SVM root volume data protection

1 messages · Page 1 of 1 (latest)

ripe shadow
#

Currently looking into how to properly protect SVM root volume data, more specifically recovery for a disaster scenario.
It is my understanding that information such as shares and junction paths are stored in the SVM root volumes as well as network information for the SVM, is this correct?

Previously the Best practise said that setting up Load-sharing mirrors is the preferred way of protecting the data but in a disaster case I don't think that would help much.
What is the Best practise for protecting SVM root volume data for disaster scenarios?

obtuse panther
#

AFAIK - On the same cluster - load sharing for SVMs that run NAS is still best practice. But you don't need to create an LS mirror on every node/aggr anymore that is in the cluster (with the exception of a 2node).
You could also do SVM DR to another for remote DR. which I think is where you're going with this?

ripe shadow
#

Is SVM DR available for just the root volume?
I already have Snapvault backups set up for the regular volume data, I think different retentions make SVM DR a bad choice if it applies to everything.

obtuse panther
#

SVMDR is the whole SVM.

#

let me take a step back. what senario are you trying to get DR for?

#

or Senarios rather

ripe shadow
#

Let's say the primary data center burns to the ground, I'm concerned we will have a hard time coming back online for the shares if that information is lost.

obtuse panther
#

otherwise, you'd have to break/export each share at the secondary site.
pre-svm dr being a thing, folks would script out creating the shares on the DR side.

ripe shadow
#

Hmm.. neither seem like a very efficient solution

obtuse panther
#

why not on the SVMDR side? cause of the existing Vaults?

#

are you trying to find a middle ground between SVMDR and manually doing the failover?

wispy bloom
#

SMBC is block storage only not file shares. There really is only 2 options, you have the DR SVM setup with all the DP vols mounted and shares created etc. then in a DR you break all the mirrors and make a DNS change or use LB/other methods to point the clients to the new location/IP address of the DR SVM. SVM-DR really only reduces the effort breaking the mirrors and removes the need to keep the DR SVM setup correctly which could also just be done using automation

ripe shadow