Update azacsnap-introduction.md for AzAcSnap 10 Release

Phil-Jensen · web-flow · commit 0045225ad48b · 2024-06-21T16:39:15.000+12:00
diff --git a/articles/azure-netapp-files/azacsnap-introduction.md b/articles/azure-netapp-files/azacsnap-introduction.md
@@ -5,133 +5,112 @@ services: azure-netapp-files
 author: Phil-Jensen
 ms.service: azure-netapp-files
 ms.topic: conceptual
-ms.date: 08/21/2023
+ms.date: 05/15/2024
 ms.author: phjensen
 ---
 
 # What is the Azure Application Consistent Snapshot tool?
 
 The Azure Application Consistent Snapshot tool (AzAcSnap) is a command-line tool that enables data protection for third-party databases. It handles all the orchestration required to put those databases into an application-consistent state before taking a storage snapshot. After the snapshot, the tool returns the databases to an operational state.
 
-## Supported databases, operating systems, and Azure platforms
-
-- **Databases**
-  - SAP HANA (see the [support matrix](azacsnap-get-started.md#snapshot-support-matrix-from-sap) for details)
-  - Oracle Database release 12 or later (see [Oracle VM images and their deployment on Microsoft Azure](../virtual-machines/workloads/oracle/oracle-vm-solutions.md) for details)
-  - IBM Db2 for LUW on Linux-only version 10.5 or later (see [IBM Db2 Azure Virtual Machines DBMS deployment for SAP workload](../virtual-machines/workloads/sap/dbms_guide_ibm.md) for details)
+Check out the steps to [get started with the Azure Application Consistent Snapshot tool](azacsnap-get-started.md).
 
-- **Operating systems**
-  - SUSE Linux Enterprise Server 12+
-  - Red Hat Enterprise Linux 7+
-  - Oracle Linux 7+
+## Architecture overview
 
-- **Azure platforms**
-  - Azure Virtual Machines with Azure NetApp Files storage
-  - Azure Large Instances (on bare-metal infrastructure)
+You can install AzAcSnap on the same host as the database, or you can install it on a centralized system. But, you must have network connectivity to the database servers and the storage back end (Azure Resource Manager for Azure NetApp Files or HTTPS for Azure Large Instances).
 
-> [!TIP]
-> If you're looking for new features (or support for other databases, operating systems, and platforms), see [Preview features of the Azure Application Consistent Snapshot tool](azacsnap-preview.md). You can also provide [feedback or suggestions](https://aka.ms/azacsnap-feedback).
+AzAcSnap is a lightweight application that's typically run from an external scheduler. On most Linux systems, this operation is `cron`, which is what the documentation focuses on. But the scheduler could be an alternative tool, as long as it can import the `azacsnap` user's shell profile. Importing the user's environment settings ensures that file paths and permissions are initialized correctly.
 
 ## Benefits of using AzAcSnap
 
 AzAcSnap uses the volume snapshot and replication functionalities in Azure NetApp Files and Azure Large Instances. It provides the following benefits:
 
 - **Rapid backup snapshots independent of database size**
 
-  AzAcSnap takes snapshot backups regardless of the size of the volumes or the database by using the snapshot technology of storage. It takes snapshots in parallel across all the volumes, to allow multiple volumes to be part of the database storage.  
+  AzAcSnap takes an almost instantaneous snapshot of the database with zero performance hit, regardless of the size of the database volumes. It takes snapshots in parallel across all the volumes, to allow multiple volumes to be part of the database storage.  
   
   In tests, the tool took less than two minutes to take a snapshot backup of a database of 100+ tebibytes (TiB) stored across 16 volumes.
+  
 - **Application-consistent data protection**
   
-  You can deploy AzAcSnap as a centralized or distributed solution for backing up critical database files. It ensures database consistency before it performs a storage volume snapshot. As a result, it ensures that you can use the storage volume snapshot for database recovery.
+  You can deploy AzAcSnap as a centralized or distributed solution for backing up critical database files. It ensures database consistency before it performs a storage volume snapshot. As a result, it ensures that you can use the storage volume snapshot for database recovery.  Database roll forward options are available when used with log files.
 
 - **Database catalog management**
 
   When you use AzAcSnap with SAP HANA, the records within the backup catalog are kept current with storage snapshots. This capability allows a database administrator to see the backup activity.
 
 - **Ad hoc volume protection**
 
-  This capability is helpful for non-database volumes that don't need application quiescing before the tool takes a storage snapshot.  Examples include SAP HANA log-backup volumes or SAPTRANS volumes.
+  This capability is helpful for non-database volumes that don't need application quiescing before the tool takes a storage snapshot.  These can be any unstructured file-system, which include database files like SAP HANA log-backup volumes and shared file systems, or SAPTRANS volumes.
 
 - **Cloning of storage volumes**
 
-  This capability provides space-efficient storage volume clones for development and test purposes.
+  This capability provides space-efficient storage volume clones for rapid development and test purposes.
 
 - **Support for disaster recovery**
 
   AzAcSnap uses storage volume replication to provide options for recovering replicated application-consistent snapshots at a remote site.
 
 AzAcSnap is a single binary. It doesn't need additional agents or plug-ins to interact with the database or the storage (Azure NetApp Files via Azure Resource Manager, and Azure Large Instances via Secure Shell [SSH]).
 
-AzAcSnap must be installed on a system that has connectivity to the database and the storage. However, the flexibility of installation and configuration allows for either a single centralized installation (Azure NetApp Files only) or a fully distributed installation (Azure NetApp Files and Azure Large Instances) with copies installed on each database installation.
-
-## Architecture overview
-
-You can install AzAcSnap on the same host as the database (SAP HANA), or you can install it on a centralized system. But, you must have network connectivity to the database servers and the storage back end (Azure Resource Manager for Azure NetApp Files or SSH for Azure Large Instances).
-
-AzAcSnap is a lightweight application that's typically run from an external scheduler. On most Linux systems, this operation is `cron`, which is what the documentation focuses on. But the scheduler could be an alternative tool, as long as it can import the `azacsnap` user's shell profile. Importing the user's environment settings ensures that file paths and permissions are initialized correctly.
-
-## Technical articles
 
-The following technical articles describe where AzAcSnap has been used as part of a data protection strategy:
+## Supported databases, operating systems, and Azure platforms
 
-- [Manual Recovery Guide for SAP HANA on Azure VMs from Azure NetApp Files snapshot with AzAcSnap](https://techcommunity.microsoft.com/t5/running-sap-applications-on-the/manual-recovery-guide-for-sap-hana-on-azure-vms-from-azure/ba-p/3290161)
-- [Manual Recovery Guide for SAP HANA on Azure Large Instance from storage snapshot with AzAcSnap](https://techcommunity.microsoft.com/t5/running-sap-applications-on-the/manual-recovery-guide-for-sap-hana-on-azure-large-instance-from/ba-p/3242347)
-- [Manual Recovery Guide for SAP Oracle 19c on Azure VMs from Azure NetApp Files snapshot with AzAcSnap](https://techcommunity.microsoft.com/t5/running-sap-applications-on-the/manual-recovery-guide-for-sap-oracle-19c-on-azure-vms-from-azure/ba-p/3242408)
-- [Manual Recovery Guide for SAP Db2 on Azure VMs from Azure NetApp Files snapshot with AzAcSnap](https://techcommunity.microsoft.com/t5/running-sap-applications-on-the/manual-recovery-guide-for-sap-db2-on-azure-vms-from-azure-netapp/ba-p/3865379)
-- [SAP Oracle 19c System Refresh Guide on Azure VMs using Azure NetApp Files Snapshots with AzAcSnap](https://techcommunity.microsoft.com/t5/running-sap-applications-on-the/sap-oracle-19c-system-refresh-guide-on-azure-vms-using-azure/ba-p/3708172)
-- [Protecting HANA databases configured with HSR on Azure NetApp Files with AzAcSnap](https://techcommunity.microsoft.com/t5/running-sap-applications-on-the/protecting-hana-databases-configured-with-hsr-on-azure-netapp/ba-p/3654620)
-- [Automating SAP system copy operations with Libelle SystemCopy](https://docs.netapp.com/us-en/netapp-solutions-sap/lifecycle/libelle-sc-overview.html)
+- **Databases**
+  - SAP HANA (see the [support matrix](#snapshot-support-matrix-from-sap) for details)
+  - Oracle Database release 12 or later (see [Oracle VM images and their deployment on Microsoft Azure](../virtual-machines/workloads/oracle/oracle-vm-solutions.md) for details)
+  - IBM Db2 for LUW on Linux-only version 10.5 or later (see [IBM Db2 Azure Virtual Machines DBMS deployment for SAP workload](../virtual-machines/workloads/sap/dbms_guide_ibm.md) for details)
 
-## Command synopsis
+- **Operating systems**
+  - SUSE Linux Enterprise Server 12+
+  - Red Hat Enterprise Linux 7+
+  - Oracle Linux 7+
 
-The general format of the commands is:
-`azacsnap -c [command] --[command] [sub-command] --[flag-name] [flag-value]`.
+- **Azure platforms**
+  - Azure Virtual Machines with Azure NetApp Files storage
+  - Azure Large Instances (on bare-metal infrastructure)
 
-## Command options
+> [!TIP]
+> If you're looking for new features (or support for other databases, operating systems, and platforms), see [Preview features of the Azure Application Consistent Snapshot tool](azacsnap-preview.md). You can also provide [feedback or suggestions](https://aka.ms/azacsnap-feedback).
 
-The command options are as follows. The main bullets are commands, and the indented bullets are subcommands.
+## Supported scenarios
 
-- `-h` provides extended command-line help with examples on AzAcSnap usage.
-- `-c configure` provides an interactive Q&A style interface to create or modify the `azacsnap` configuration file (default = `azacsnap.json`).
-  - `--configuration new` creates a new configuration file.
-  - `--configuration edit` enables editing an existing configuration file.
+The snapshot tools can be used in the following [Supported scenarios for HANA Large Instances](../virtual-machines/workloads/sap/hana-supported-scenario.md) and [SAP HANA with Azure NetApp Files](../virtual-machines/workloads/sap/hana-vm-operations-netapp.md).
 
-  For more information, see the [configure command reference](azacsnap-cmd-ref-configure.md).
-- `-c test` validates the configuration file and tests connectivity.
-  - `--test hana` tests the connection to the SAP HANA instance.
-  - `--test storage` tests communication with the underlying storage interface by creating a temporary storage snapshot on all the configured `data` volumes, and then removing them.
-  - `--test all` performs both the `hana` and `storage` tests in sequence.
+## Snapshot Support Matrix from SAP
 
-  For more information, see the [test command reference](azacsnap-cmd-ref-test.md).
-- `-c backup` is the primary command to execute database-consistent storage snapshots for SAP HANA data volumes and for other (for example, shared, log backup, or boot) volumes.
-  - `--volume data` takes a snapshot of all the volumes in the `dataVolume` stanza of the configuration file.
-  - `--volume other` takes a snapshot of all the volumes in the `otherVolume` stanza of the configuration file.
-  - `--volume all` takes a snapshot of all the volumes in the `dataVolume` stanza and then all the volumes in the `otherVolume` stanza of the configuration file.
+The following matrix is provided as a guideline on which versions of SAP HANA are supported by SAP for Storage Snapshot Backups.
+ 
+|  Database type            | Minimum database versions | Notes                                                                                   |
+|---------------------------|---------------------------|-----------------------------------------------------------------------------------------|
+| Single Container Database | 1.0 SPS 12, 2.0 SPS 00    |                                                                                         |
+| MDC Single Tenant	        | [2.0 SPS 01](https://help.sap.com/docs/SAP_HANA_PLATFORM/42668af650f84f9384a3337bcd373692/2194a981ea9e48f4ba0ad838abd2fb1c.html?version=2.0.01&locale=en-US)                | or later versions where MDC Single Tenant supported by SAP for storage/data snapshots.* | 
+| MDC Multiple Tenants      | [2.0 SPS 04](https://help.sap.com/docs/SAP_HANA_PLATFORM/42668af650f84f9384a3337bcd373692/7910eb4a498246b1b0435a4e9bf938d1.html?version=2.0.04&locale=en-US)                | or later where MDC Multiple Tenants supported by SAP for data snapshots.                |
+> \* [SAP changed terminology from Storage Snapshots to Data Snapshots from 2.0 SPS 02](https://help.sap.com/docs/SAP_HANA_PLATFORM/42668af650f84f9384a3337bcd373692/7f203cf75ae4445d96ad0012c67c0480.html?version=2.0.02&locale=en-US)
 
-  For more information, see the [backup command reference](azacsnap-cmd-ref-backup.md).
-- `-c details` provides information on snapshots or replication.
-  - `--details snapshots` provides a list of basic details about the snapshots for each volume that you configured.
-  - `--details replication` provides basic details about the replication status from the production site to the disaster-recovery site.
 
-  For more information, see the [details command reference](azacsnap-cmd-ref-details.md).
-- `-c delete` deletes a storage snapshot or a set of snapshots.
+**Additional SAP deployment considerations:**
 
-  You can use either the SAP HANA backup ID (as found in HANA Studio) or the storage snapshot name. The backup ID is tied to only the `hana` snapshots, which are created for the data and shared volumes. Otherwise, if you enter the snapshot name, the command searches for all snapshots that match the entered snapshot name.
+- When setting up the HANA user for backup, you need to set up the user for each HANA instance. Create an SAP HANA user account to access HANA instance under the SYSTEMDB (and not in the tenant database).
+- Automated log deletion is managed with the `--trim` option of the `azacsnap -c backup` for SAP HANA 2 and later releases.
 
-  For more information, see the [delete command reference](azacsnap-cmd-ref-delete.md).
-- `-c restore` provides two methods to restore a snapshot to a volume.
-  - `--restore snaptovol` creates a new volume based on the latest snapshot on the target volume.
-  - `-c restore --restore revertvolume` reverts the target volume to a prior state, based on the most recent snapshot.
+> [!IMPORTANT]
+> The snapshot tools only interact with the node of the SAP HANA system specified in the configuration file.  If this node becomes unavailable, there's no mechanism to automatically start communicating with another node.  
 
-  For more information, see the [restore command reference](azacsnap-cmd-ref-restore.md).
-- `[--configfile <configfilename>]` is an optional command-line parameter to provide a different file name for the JSON configuration. It's useful for creating a separate configuration file per security ID (for example, `--configfile H80.json`).
-- `[--runbefore]` and `[--runafter]` are optional commands to run external commands or shell scripts before and after the execution of the main AzAcSnap logic.
+  - For an **SAP HANA Scale-Out with Standby** scenario it's typical to install and configure the snapshot tools on the primary node. But, if the primary node becomes
+      unavailable, the standby node will take over the primary node role. In this case, the implementation team should configure the snapshot tools on both
+      nodes (Primary and Stand-By) to avoid any missed snapshots. In the normal state, the primary node will take HANA snapshots initiated by crontab.  If the primary 
+      node fails over those snapshots will have to be executed from another node, such as the new primary node (former standby). To achieve this outcome, the standby
+      node would need the snapshot tool installed, storage communication enabled, hdbuserstore configured, `azacsnap.json` configured, and crontab commands staged 
+      in advance of the failover.
+  - For an **SAP HANA HSR HA** scenario, it's recommended to install, configure, and schedule the snapshot tools on both (Primary and Secondary) nodes. Then, if 
+      the Primary node becomes unavailable, the Secondary node will take over with snapshots being taken on the Secondary. In the normal state, the Primary node 
+      will take HANA snapshots initiated by crontab.  The Secondary node would attempt to take snapshots but fail as the Primary is functioning correctly.  But, 
+      after Primary node failover, those snapshots will be executed from the Secondary node. To achieve this outcome, the Secondary node needs the snapshot tool 
+      installed, storage communication enabled, `hdbuserstore` configured, `azacsnap.json` configured, and crontab enabled in advance of the failover.
 
-  For more information, see the [runbefore/runafter command reference](azacsnap-cmd-ref-runbefore-runafter.md).
-- `[--preview]` is an optional command-line option that's required when you're using preview features.
+    > See the technical article on [Protecting HANA databases configured with HSR on Azure NetApp Files with AzAcSnap](https://techcommunity.microsoft.com/t5/running-sap-applications-on-the/manual-recovery-guide-for-sap-oracle-19c-on-azure-vms-from-azure/ba-p/3242408)
 
-  For more information, see [Preview features of the Azure Application Consistent Snapshot tool](azacsnap-preview.md).
 
 ## Next steps
 
