Exploring Trident Protect: Application Mirror Relationship (AMR) for High Availability and Disaster Recovery In today's fast-paced digital landscape, businesses rely heavily on applications to drive innovation, growth, and customer engagement. However, application downtime or data loss can have devastating consequences, including lost revenue, damaged reputation, and compromised customer trust. To mitigate these risks, organizations need a robust disaster recovery strategy.   In this blog, we'll delve into the concepts of failover/failback and explore how NetApp Trident Protect Application Mirror built on top of NetApp ONTAP SnapMirror can help businesses ensure seamless application mobility and disaster recovery.   Benefits of Application Protection with Trident Protect Application Mirror   Minimized Downtime: Failover and Failback capabilities minimize downtime, ensuring that applications remain accessible and operational. Improved Business Continuity: AppMirror ensures business continuity by providing failover and failback capabilities, reducing the risk of data loss and downtime. Reduced Costs: The solution reduces costs associated with disaster recovery and application mobility, including infrastructure, personnel, and downtime costs. Simplified Disaster Recovery: Trident Protect Application Mirror simplifies disaster recovery by providing failover and failback capabilities, reducing complexity and minimizing downtime. Automated Replication: Snapshots are automatically replicated to a target environment, ensuring data consistency and minimizing downtime. Reduced RTO and RPO: Reduce your RPO to as low as 5 minutes.   Steps to configure and use Trident Protect Appmirror:   Prerequisites for AMR - Trident Protect setup configurations for AMR ONTAP - Storage backend should be peered as mentioned in our documentation. AppVault - AppVault is used to store metadata (k8s resources) for the application used during failover operations. . We recommend creating two separate AppVault configurations for your source and destination sites.   Source Cluster Requirements Source Cluster AppVault: Ensure AppVault(bucket) CR common between source and destination has been created. Source Application CR: A Custom Resource (CR) for your source application. Source Snapshot CR: A Custom Resource (CR) for your source snapshot. Source Snapshot Schedule: A schedule for snapshots (CR). Destination Cluster Requirements Destination Cluster AppVault: Ensure AppVault(bucket) CR common between source and destination has been created. AppMirrorRelationship CR: A Custom Resource (CR) defining the application mirror relationshipincluding a replication schedule.   AMR is established and ready to protect your K8s applications.     Primary Site Outage - Execute Failover to Restore Application Operations   Failover is the process of switching to a standby system or environment when the primary system or environment fails or becomes unavailable. In a failover scenario, the standby system or environment takes over the responsibilities of the primary system or environment, ensuring business continuity. Failover needs to be triggered by the user in case of various events, including hardware failures, software crashes, network outages, or natural disasters.   Failover the AppMirrorRelationship to bring up your application in Region B.     Recovery scenarios - Restoring Replication Relationships   From the failed over state you can select one of the three scenarios based on your needs: 1. Resync - Conduct disaster recovery (DR) testing by disregarding changes on the destination site while resynchronizing. 2. Reverse resync - Swap the roles of the source and destination sites.  3. Failback - In this scenario we restore the initial replication direction, we first reverse resynchronize any application changes back to the original source application before switching the replication direction.   Resync a failed over replication relationship Goal: The original source application becomes the running application, and any changes made to the running application on the destination cluster are discarded.   Create a source snapshot: Establish a new snapshot on the source. Re-establish AppMirrorRelationship - On the destination cluster, update the AppMirrorRelationship desired state from "Promoted" to "Established". Remove Schedules on Destination - Delete any schedules that were copied to the destination volume during the failover process. Reverse resync a failed over replication relationship Goal: Destination application becomes the source application, and the source becomes the destination. Changes made to the destination application during failover are kept.   Syncing the changes back from Region B to Region A     Delete existing AMR CR: Remove the AppMirrorRelationship CR on Region B. Capture changes since failover: Create a new base snapshot on Region B. Create snapshot schedule: Create a new snapshot schedule CR on Region B. Create new AMR CR: Establish a new AppMirrorRelationship CR on Region A. Ensure namespace mapping is accurate Ensure AppVaults have been swapped if using a source and destination app vault (destination will become source and source will become destination) Ensure srcApplicationName matches the name of the Application CR created on secondary instance Ensure srcApplicationUID matches the .metadata.uid from the Application CR created on the secondary instance Wait for AMR establishment: Wait for the AppMirrorRelationship to reach the "Established" state in Region A. Note: If you want to keep things in this current state where replication direction swapped then you can stop here. Another option would be to continue to the next section of failing back application to the original source cluster.   Failback applications to the original source cluster Goal: Revert to the original replication direction and state, we first replicate (resynchronize) any application changes to the original source application prior to reversing the replication direction.   Syncing changes back to original Region A and bringing the App down on Region B       Reversing the replication direction back from Region B to Region A     Prerequisite to this section would be Reverse resync a failed over replication relationship as outlined above. Disable Schedules on Region A - Delete any snapshot schedules in Region A. ShutdownSnapshot CR: Create a ShutdownSnapshot CR on Region B to take a final snapshot and gracefully shutdown your application. After the ShutdownSnapshot has completed, get the name of the snapshot from the CR status as mentioned in our documention. Perform a Failover using the snapshot basename in apparchive path retrieved from previous step. Follow Reverse Resync steps from Region A to Region B. Enable schedules on your original site Region A.   Note: This workflow is expected to incur application downtime.    Conclusion In conclusion, failback and failover are critical components of a disaster recovery strategy, ensuring business continuity and minimizing downtime. NetApp Trident Protect Application Mirror provides failover and failback capabilities, supporting seamless application mobility and disaster recovery. By leveraging Trident Protect Application Mirror, businesses can ensure minimal downtime, improved business continuity, and reduced costs.   ... View more

How Google Cloud NetApp Volumes meets the scale, performance, and complexity demands of modern electronic design automation pipelines ... View more

SVM Migrate is a powerful tool to have in your data management arsenal. It provides an easy way to move SVMs between clusters based on your unique requirements without incurring any downtime for application that are dependent on the migrating data.  ... View more

As organizations look to simplify day to day operations, there are numerous tools available in the market . Modern tools provide a simplified way to manage data but they are limited to specific tasks.  There is no single tool that can assist in the provisioning of storage, discovery and protection of a database. Plus there are licensing charges for each tool. If there are multiple services then managing the contract for each feature is complicated work and requires a lot of coordination. Additionally, with increasing workloads and tasks, it is tedious work for the team to move between the software's to get the work done in a given business time. NetApp helps to solve this problem with NetApp BlueXP. It is a control plane that helps to manage storage centrally and securely.    Figure 1: BlueXP manage NetApp storages across on-premise and on cloud   Provisioning storage for database:   You can provision storage on the AFF/FAS/ASA platforms from BlueXP. This can be done directly from the BlueXP provisioning wizard under Storage-> My working environment->cluster->volumes or System Manager to add storage units (LUNS or NVMe namespace)             Figure 2: volume creation for hosting database on SMB and system manager for LUN creation   Map the storage to SQL Server host with iSCSI, FC based protocol or add virtual disk if it is running on VMware platform.   Discovery & backup of databases:   Once storage is mapped to the SQL Server host and the database is deployed, the next step is to backup the databases. As database size is increasing, completing a backup in specific time window may not be possible, and data archival is also a key requirement . Balancing the need of achieving low RTO and  simplifying data retention policy challenge, BlueXP backup & recovery now introduces support for Microsoft SQL Server database(preview release) which helps to take an application consistent snapshot leveraging ONTAP snapshot capability.  NetApp Snapshot copy takes only few seconds to create. Irrespective of database size  in terabytes, application consistent snapshot is completed immediately. Instead of following traditional approach of taking full backup once a week and differential backup everyday, you could take full backup daily.  Snapshot copy consumes minimal space and snapshot restore is extremely fast. In the case of recovery, you need to restore the latest full backup and apply the transaction logs. Your business RTO can be met efficiently with this approach.  In BlueXP backup and recovery service, snapshot can be copied to secondary storage on ONTAP or to an object storage to achieve 3-2-1 backup strategy. Third copy of backup can be stored offsite on different media for long term.    The workflow is user-friendly, efficient and easy to setup Go to BlueXP backup & recovery for applications Add the host to protect databases with appropriate credentials Add vCenter details if database files are hosted on virtual disks. Instances and databases are discovered automatically Create policy where you define the type of backup, retention period, frequency, locking and scheduling Apply policy and protect databases or the complete instance Note: While creating policy, you may get multiple options to select different policy type based on business needs like 3-2-1 backup, disk to disk backup, disk to object storage or fan-out setup .  Based on the selected policy type, BlueXP will orchestrate the creation of replication without the need to go to an ONTAP system and configure replication.   Figure 3: BlueXP backup and recovery for database different policy type   After the replication is configured, you can view the status in BlueXP canvas. If the relationship already exists then BlueXP backup and restore will use the existing one .   Database management:   Often DBA's need to create copies of databases in development, or other, non-production, environment.  This is so that developers can perform code testing, business users can run some highly selective queries to generate reports, or business operation teams can run batch process to offload activities from production environment. BlueXP backup and recovery for databases allows you to create copies of databases and the workflow is intuitive. BlueXP backup & recovery gives you flexibility to recover from any storage wherever snapshot copy is stored, primary secondary or object storage. Select snapshot Choose snapshot location         Select destination server & path Figure 4: Database recovery to alternate host process DBA's don’t have to write any complicated scripts to perform such repetitive tasks. With restore wizard, copies of databases can be created on the same or alternate host.  Database restores may be performed from tertiary copies saved on object storage for compliance purposes.  Customers don’t have to rely on a tape-based backup which can have a very long recovery time. The complete database restore process can be managed from a single control pane . Figure 5: Database restore job status and database restored in SQL Server Database restore is not limited to full restore, if transaction log backup is configured then point-in-time recovery is also possible. Point in time recovery is critical when complete databases need to be recovered on the production server.   Security:   Database storage management does not end here. As announced in this blog of  February 2025, the Autonomous Ransomware Protection with AI for block storage is planned to ship this calendar year with ONTAP updates. Please note plans are subject to change.  With BlueXP you not only get visibility to storage but you also get to protect the databases.   Get started: NetApp BlueXP helps you to manage end-to-end storage for database. Reach out to your NetApp representative to know more about the BlueXP services and solution and, if you are interested, sign up today to gain early access and be part of shaping the BlueXP backup and recovery solution. Fill out the form here to join the preview program today     Check out more about BlueXP backup and recovery here - https://community.netapp.com/t5/Tech-ONTAP-Blogs/Introducing-the-Preview-for-NetApp-BlueXP-backup-and-recovery-for-Microsoft-SQL/ba-p/459491.   To learn about Microsoft SQL Server on ONTAP, click https://docs.netapp.com/us-en/ontap-apps-dbs/mssql/mssql-overview.html ... View more

April is here, and it’s time for another roundup of recent updates to BlueXP™ workload factory on AWS. This time we’ve got brand new features that support all of the major workloads. ... View more