Module 2: DR Soluitons Flashcards
SnapMirror
Ideal for DR.
The software provides constant updates.
Asynchronous replication
Point-in-time reference
Minimum RPO approximately 5 minutes
Snapmirror relationship
Creates a secondary copy of your software in secondary storage.
A mirror relationship allows you to copy snapshot copies form the source to the target.
Provides asynchronous DR
Replicated snapshot copies contain the same data integrity information as the source.
SnapMirror for volumes
Data protection mirror relationships provide asynchronous disaster recovery
You can use data protection mirror relationships to protect volumes such as the following:
* within a SVM
* for another SVM in the cluster
* for a SVM in another cluster
SnapMirror Configuration (Policies and schedules)
Source Volume
The snapshot policy defines how snapshot copies are created. Schedules, number of copies and label.
The default daily and weekly snapshot policies are configured with Snapmirror labels.
Secondary volume
The snapmirror policy defines how snapshot copies are replicated. Has a label, specifies the number of copy’s in the target
to retain.
The schedule defines when replication updates occur
DR - activitation of a destination volume
The destination volumes in a snap mirror relationship or read, only until failover to make the destination, volume rideable perform the snap mirror operation separately for each volume if the source volume becomes unable to serve data, such as due to corruption or deletion act the destination, volume by stopping snap, mirror transfers and breaking the relationship Before activation verify the source volumes, off-line status and qui and break the relationship from the destination cluster verify that the destination volume has read. Wright permission confirm that the settings match the source volume and configure the destination volume for data access. Clients and host can access data from the destination volume until the source volume is reactivated.
- Verify the status of the source volume
- Quiesce and break the relationship
- Verify the status of the destination volume
- Configure the destination volume for data access
DR - Reactiviation of a source volume
When a source volume is available again, verify that the source volume is online from the source cluster before you reactivate the source, volume re synchronise the data between the destination and source volumes from the destination cluster when complete resume the original relationship if resynchronisation takes more time than expected, verify all the latest changes on the source volume before activating it After resynchronisation, configure the source volume for data access, enabling NA clients in Sanos to access the data
- Resynchronize the data between the destination volume and the source volume, with a baseline.
- If necessary update the source volume
- Configure the source volume for data access
Using Flex Clone with SnapMirror
And the flex clone volume is a rideable point in time clone of a flex volume a flex clone, volume shares data blocks with the parrot and the flex clone, volume consumes. No storage except what is required for metadata until changes are written to the copy.
FlexClone copies share data blocks with their parents, and these copies consume no storage except what is required for metadata.
Using FlexClone with SnapMirror
This slideshows how you use flex clone technology to create a clone of the snap near destination volume for disaster recovery testing using a snapshot copy that is created for the flex clone volume in this manner, prevents the snap mirror update from failing due to an automatically created snapshot copy that is being removed from the source system Flex clone technology also enables you to create a rideable volume from a read, only snap, mirror destination, without interrupting the snap, mirror, replication process or production operations
- Create an unscheduled snapshot copy at the source
- Perform a snapmirror update to replicate the unscheduled snapshot copy to the destination
- Use the unscheduled snapshot copy as the base for the FlexClone volume.
SnapMirror and FlexGroup Volumes
Snap mirror technology supports the net app on tap flex group feature. All member volumes must have a successful snapshot copy and all member volumes are currently replicated to the disaster recovery site. You can use the mirror copies of the flex group to recover data when a disaster occurs all members transferred at the same time. There is no way to mirror individual member volumes with snap mirror software. If any component of this operation fails, snap, mirror mirroring fails as well.
Netapp ONTAP FlexGroup volumes that are also snapmirror volumes are replicated at the FlexGroup level. (The same snapshot rules apply, all member snapshots must succeed for snapshot copies to be considered successful)>
All FlexGroup members are replicated concurrently across the entire WAN (snapmirror concurrent transfer limits apply).
S3 SnapMirror
You can protect buckets in on tap S3 object stores by using the familiar snap mirror, mirroring and backup functionality unlike standard snap, mirror software, S3, snap mirror technology supports active mirrors and backup tears from on tap three buckets to the following destinations on tap three storage grid, Amazon, simple storage, service, or Amazon, S3 and cloud volumes on tap for Microsoft Azure
S3 SnapMirror has the following capabilities.
* enable DR, Provides backups
Create backups from Netapp ONTAP3 buckets to the following
* ONTAP S3, StorageGRID, Amazon S3, Cloud volumes Ontap for azure
S3 Snapmirror does not use point-in-time snapshot copies
S3 Snap Mirrors P2
Using S3 snap mirror software you can replicate S3 buckets to buckets that are within the same SVM. You can mirror data from three buckets to buckets that are in different SVM on the same cluster and buckets that are in SVM on different clusters.
Create active mirrors from ONTAP S3 Buckets to the following
* buckets in the same SVM
* buckets in different SVM on the same cluster
* Buckets in SVMs on different clusters
Snapmirror for SVM DR
Net snap mirror software provides a solution for various use cases including replication to 2 sides a local site and a remote site. It offers automatic protection for newly added data containers which provides continuous data availability in the event of a site failure snap mirror technology enables data access from the replicated site providing business continuity, it also facilitates upgrades and technology refreshes with minimal disruption, snap mirror software uses asynchronous backup, providing a RPO, so that data is protected and up-to-date
Asynchronous backup
RPO approximately 15 minutes
Snapmirror for SVM overview
Storage BM disaster recovery or SV MDR replicates configurations and data in SVM volumes automatically protecting newly added volumes. If the Primary site fails requests are redirected to a secondary site, VMD are Support flex group volumes, fabric, volumes, and SVM with large volumes, files and lens with SMDR you also protect the SVM identity and name space not only volumes after the relationship is established intervention is only required for failover, you can use snap mirror CI commands or app on tap system manager to manage VMD relationships with multiple configuration options on tap 9.7 and later versions include rest API for configuring SVM relationships
Benefits
Protects namespaces not only volumes
Provides automated setup and provisioning
Offers familiar Netapp SnapMirror commands on the CLI
Uses REST API to configure relationships
Automated for Ease
Disaster recovery management is simplified with SMDR’s automation, especially when clusters are in the same subnet and the SVM retains lip IP addresses for setting up an SMDR relationship cluster and SVM hearing is required. Initial the relationship creates the baseline for all volumes and configurations protecting them with the same RPO Changes to the SVM like creating volumes are automatically protected. If the source VM is unavailable, the destination VM can be activated without changing settings however, there will be disruption because this solution does not offer zero RPO or RTO and host cashing logs are not maintained in case of corruption or accidental deletion, or if the source goes off-line.
Disaster Scenario (activation of the destination SVM)
In case of data corruption or accidental deletion, or if the source says the M goes off-line, you must activate the destination SBM to provide data access activation involves stopping future, snap, mirror data transfers and breaking the relationship. Reactivating the source. SVM follows the similar process as reactivating a source, volume for synchronisation Stop the source SVM before activating the destination to avoid potential conflicts with IP addresses that are used by both SVM
- Verify the source SVM status
- Quiesce and break the snapmirror relationship
- Stop the source SVM
- Verify the destination SVM status
- Configure the destination SVM for data access