2017-04-24 02:47 AM
I am struggling to confirm what backup's are required to backup an entire cluster so it maybe restored from bare metal.
My environment wil be 2 Node cluster with 5-10 SVM (LDAP / AD) user data backed up direct to tape via NDMP.
Is there a KB on this ?
No snapmirroring currrently to remotes sites. This is a standalone cluster.
My aim is to do a bare metal restore test restoring all the configuraiton minus the user data which can be restored via NDMP after.
I know I can use 'system configuration backup' to a remote ftp or HTTP host but is that enough ? I suspect it may not be.
For example does system configuration backup contain:
- Aggr, Vol + Qtree data structures
- SVM information such as junctions, assigned volumes and configuration with regard to AD and LDAP.
Do I need to do:
- system configuration backup
- Backup SVM root volumes (These are LS mirrored as per good practices)
Solved! SEE THE SOLUTION
2017-04-24 05:43 AM
I'm going to dig into this some more, but did find the following with a rather vague description of what configuration backup files are:
I've got to figure there's a TR/white-paper out there that describes what "comes back" after performing a system configuration backup restore and/or what other information you need to get your cluster back online (excluding user data).
I'll try to post an update soon - I've got a similar use case that I'm interested in so this is pretty relevant to our operation.
2017-04-26 01:51 PM
So I pulled the thread with our account engineer and researched some of this further. In the end, it sounds like some combination of backups is in order. The summary breakdown of protection methodologies (per our engineer) is:
SVM DR (protects config and user data)
This is for DR. It replicates the everything contained by and in the SVM, including user data. Exception is SAN configuration data.
LS mirrors (protects GNS, not configuration, not user data (assuming only writing to joined volumes))
This protects the GNS becoming unavailable.
System configuration commands (protects config, not user data)
This protects a situation where you lose an SVM. An example would be a deleted SVM.
Another benefit is if you want to recreate or copy a configuration on a new node or cluster.
It could also be used in conjunction with SM/SV to bring a backup/mirror online.
Since this is a stand-alone cluster, SVM DR is out for you unless you wanted to try to protect against a single aggregate failure by mirroring within the same cluster.
In the end, if you're looking to get this set up so that it can be "restored from bare metal", you're going to need to perform the system configuration backup and "somehow" get your SVM root volumes backed up. Step one (after a disaster and rebuild of the cluster) would be performing the configuration backup recovery procedure:
Quick blurb on the configuration backup content:
Cluster configuration backup file
These files include an archive of all of the node configuration backup files in the cluster, plus the replicated cluster configuration information (the replicated database, or RDB file). Cluster configuration backup files enable you to restore the configuration of the entire cluster, or of any node in the cluster. The cluster configuration backup schedules create these files automatically and store them on several nodes in the cluster.
What I'm still noodling on is once you have a "restored" cluster, how do you rebuild the data SVMs from a backed-up SVM root volume. The closest I could find was "Promoting a data-protection mirror copy" (vs LS mirrored):
Ignore the mirror quiesce/break since you'd be recoverying from another source - so then you'd just be issuing the following:
volume make-vsroot -volume vol_dstdp -vserver vs1.example.com
Then you could restore user data from ??? and hopefully be underway.
We've got a similar use case in one environment where we don't have another NetApp cluster to mirror to. If we figure out a solution I'll try to double-back with what we sleuthed out...
Hope that helps,
2017-04-27 03:01 AM
I believe we are both on similar pages on this one. I see the NETAPP recovery options as:
1) I mostly care about my user data - So snapmirror to another site or NDMP to tape and store off site
2) I also care about my SVM's so SVM DR to another site
3) I needs near zero recovery time so metrocluster
Most of NETAPP offerings assume customers have another site for snapmirrors and multiple
NETAPP FAS server + adequate disk space available.
With RAID-DP and above the data in situ is well protected for disk failure. With planning and mirroriing you can protect
against disk draw failures as well. With 'LS' mirrors you can address SVM Root volume issues within the cluster.
The 'system configuration backup / recovery' commands tackles pretty much all node or cluster failure or corruption
I keep coming back to the same question how are SVM's backed up or recovered fully after a 'system configuration recovery'
on a new enviroment, so that I end up with my cluster + LIFS + Aggr + VOLs + SVM as before but with no user data.
For now I suspect my DR will need to be:
1) Source platform ( new or hired FAS or ONTAP Select perhaps)
2) Setup Cluster
3) Using our local documentation + Auto Support data rebuild enough SVM + Config to provide urgent operations
4) Restore only the data that is needed for critical systems operations to the DR ONTAP Cluster.
5) Restore less urgent SVM and data as needed as and when the situation allows.
A bare metal KB or formal process would be cool, however its probably only going to be of use in restoring a
like -4- like FAS / environment.
I remain very interested in getting a bare metal backup in place for my piece of mind, however I accept that if
companies are truely commited to DR and recovery a certain amount of investment is needed to do a diligent
Thanks for a good response Andy P