In this video demonstration, we'll walk through SnapCenter data protection using FSx for NetApp, ONTAP, and SnapMirror replication capabilities. We begin by reviewing the environmental setup in the active region. Oregon. We have two SQL server nodes located in different subnets in the Disaster Recovery region, Virginia we have two additional nodes. There are two FSx file system with different volume types. The data protection volumes reside in the DR region for our DR node, while the read write volumes are located in the active region for the active node. Next, we move over to the jump hose with all four SQL server nodes in the cluster are connected. We walk through the cluster setup and configuration, noting that each cluster IP address is assigned to a different availability zone and subnet. The SQL server role is up and running with AWS resources online or FSX share volume participating in the cluster and the SQL Server Cluster IP which is properly configured. We also verify that all the nodes in the cluster are present and no node is offline. Now connecting to a SQL server, we can see the databases and the table present in the server. As our SnapCenter environment, we log in using sysadmin credentials. The dashboard provides a clear overview of the SnapCenter application displaying the replication status. Is the total snapshot, the number of hosts present, the backups, and the total file system. The resources tab shows all the SQL server resources present in the SnapCenter server, and selecting a specific database shows the total number of the SnapMirror backup copies. For SQL server demonstration, we'll focus on the storage system, which is FSx volumes and the host for all the SQL server plugins. Now we'll demonstrate the failover process by performing a manual failover between the active node and the doctor node. When we attempt to trigger a manual failover, we discover that this is not possible because the node win SQL ver and zero one only contains data protection volume. As a result, the cluster Automatically fills back to win Circle or zero two, which contains the red white volume. This demonstrates that SQL server is not supported on data protection volumes only read write volumes. But on a SQL server. Let's drop a table from the database and use SnapCenter to perform a point in time restore. After dropping the table and verifying the table is not present. We'll initiate a disaster by passing the SQL Server active node at the cluster level, or at the console level by stopping the active node. As the notes not enter a failed state. We need to break the SnapMirror relationship in order to bring the DR node online. We start by copying the script provided to any CLI of our choice and run the script. Next we verify that the volumes are offline. And we show that the relationship, the SnapMirror relationship has been broken. With this action, it automatically converts the data protection volumes into read write volumes. Which is suitable for SQL server databases. We then move over to the cluster manager and bring up the DR node online, because right now the cluster is in a failed state. To proceed. We have to perform a failover at a cluster level and a row level to transfer the SQL server resources to the DR node. In order to bring the cluster and the databases online. When that process is completed, you sign in to any SQL server node of choice. And verify that the table that was deleted is not present, so we can see that the table is not present. Next, we look back into our SnapCenter to restore the database table to a point in time. To proceed, we need to enable disaster recovery mode. After this process, we move to the resource tab. Select the most recent SnapMirror backup copy. And initiate the restore process. The SnapMirror volumes are automatically populated. SnapMirror provides four methods to restore the transaction log backup. We select the most appropriate option based on a company or your company RPO, and choose to overwrite any database with the same name during the restore process. We then continue with the restore process and click on finish. And allow the process to run to completion. And this can be done by bringing up the monitor tab. We can see that the database table and the restore process was fully completed. Back into SQL server. We verify that the database table is present in the database. SnapCenter provides a quick and efficient restore time regardless of the database size, typically completing restore in under two minutes. Thanks for watching this demo. To learn more, please contact NetApp.