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.
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:
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):
I wonder if you got anywhere with Netapp bare Metal restore from config backup? We have a kind of similar scenario where we want to restore Netapp base config (no user data) and then restore user data from tapes using ndmp.