NetWorker Snapshot Management:
EMC technology that provides point-in-time snapshot copies of data. NetWorker software backs up data from the snapshot. This allows applications to continue to write data during the backup operation, and ensures that open files are not omitted.
Note: With NetWorker release 8.1 or later, the NSM feature integrates and replaces the PowerSnap Modules. NSM is available as part of the NetWorker client software.
Types of NSM backups: The type of NSM backup that you configure depends on where you intend to create and store the snapshot, as follows:
* Snapshot backup—NSM creates a snapshot of specified files on the application host and retains the snapshot on the storage array only. The NetWorker server catalogs the snapshot as a backup in the media database. The NetWorker server can perform a restore from the snapshot.
* Snapshot and rollover backup—NSM creates a snapshot of specified files on the application host and then immediately rolls over the snapshot to conventional storage media. The storage array retains the snapshot. The NetWorker media
database catalogs both the snapshot and the rollover as backups. The NetWorker client file index catalogs the rollover. The NetWorker server can perform a restore from either the snapshot or the rollover.
* Rollover-only backup—NSM creates a snapshot of specified files on the application host and then immediately rolls over the snapshot to conventional storage media. When the rollover completes, NSM deletes the snapshot. Because NSM does not retain the snapshot, the NetWorker server can restore only from the rollover. Previous versions of PowerSnap referred to this process as a “serverless backup” configuration.
Backup configuration methods:
You can configure all the supported types of snapshot backups by using the NetWorker Management Console (NMC) interface. All the supported storage arrays support the following configuration methods:
* The NMC Client Configuration Wizard is the recommended method to create and modify the NSM configurations for snapshots and rollovers. The wizard accommodates the most common NSM workflows by providing the correct sequence of steps and verification of configuration dependencies.
* As an alternative to the wizard, the NMC Client Property windows provide a manual, nonwizard user interface that you can use to modify existing configurations. For example, you can use the property windows to specify uncommon directives or the
options that the wizard interface does not support.
You can use the following interfaces to restore snapshot-based data:
* The NMC Recovery Wizard is the recommended interface to use to restore data from the snapshots and conventional storage media.
* The nsrsnapadmin command utility provides an interactive CLI session for various snapshot-related operations, including restore from a snapshot and restore from conventional storage media. “Using nsrsnapadmin for NSM operations” on page 80
* The nsrsnap_recover command provides another CLI method to restore data from a snapshot or conventional storage media.
NSM supports the following types of mirror devices on RecoverPoint Appliances (RPA)
• Local continuous data protection (CDP)
• Continuous remote replication (CRR)
Components of the NSM network
You can deploy various required and optional hosts, devices, connectivity, and applications in a NetWorker datazone for NSM.
An application host in the NSM context is a computer whose production data resides on storage array volumes and requires snapshot services. The production data can consist of file systems or databases.
Each application host must run NetWorker client 8.1 software and must be a client of the NetWorker server.
All hosts involved in the movement of production data within the NSM snapshot environment must use Fibre Channel (FC) connectivity deployed as a storage area network (SAN). NSM does not support iSCSI or FCoE environments.
For NSM operations, one or more supported storage arrays must provide logical units (LUNs) to store the application host’s production data and the snapshots of this data. The storage arrays manage the LUNs as production volumes and snapshot volumes that are available to the required hosts.
NSM supports the following storage arrays:
· EMC VMAX (Symmetrix) storage array
· EMC VNX Block (CLARiiON) storage array
· EMC RecoverPoint appliance
The NetWorker server manages the NSM clients and the configuration settings required to create the snapshots and perform the rollover operations.
NetWorker storage node:
The NetWorker storage node manages the devices for backups to conventional storage media, such as advanced file type device (AFTD), DD Boost devices, and tape. NSM requires a storage node for all rollover operations and restores from rollover operations. If you do not plan to perform rollovers but plan to use NSM only to create and restore snapshots, then the use of a storage node is optional.
Snapshot mount host:
NSM requires a NetWorker client host to mount the storage array’s snapshot volumes for snapshot restore operations and for rollover to conventional storage media. This mount host can be the local application host, a NetWorker storage node, or a remote NetWorker client host. The choice of mount host depends on the storage network configuration. A well-planned configuration considers the data processing speed and the bandwidth load on the different possible hosts.
The mount host must use the same operating system with the same third-party volume manager (if any) as the application host. You must synchronize the system clocks of the mount host and the application host.Rollback operations do not use a mount host.
Backup storage media:
NSM can roll over the snapshots to conventional backup storage media, such as AFTD, DD Boost devices, and tape. During the rollover, NetWorker catalogs the save set files in the client file index.
NetWorker application modules:
NSM supports application hosts that use NetWorker application modules, such as NMDA or NMSAP that use VMAX or VNX Block arrays.
The following figures and description of processes illustrate the flow of data with two variations during a snapshot with rollover backup in a typical NSM environment.
Figure 55 Snapshot and rollover with the storage node as the mount host
Figure 56 Snapshot and rollover with the application host as the mount host
1. The application host processes its production data by writing to one or more source volumes on an attached storage array.
Note: The application host can run NMDA or NMSAP. As a common practice for these modules, the application host can have its own NetWorker storage node, which makes the application host also the mount host.
2. At the predetermined time, NSM creates a snapshot of the production data on a different volume on the storage array or on a different array:
a. NetWorker policies and Client resource settings identify which file systems or which data on the application host require a snapshot.
b. NSM quiesces, flushes, and synchronizes the source LUNs with the target LUNs. The source LUNs contain the production data volumes.
c. The storage array splits/fractures the target snapshot LUN from the production LUNs. This process creates a fully usable snapshot on the snapshot volume.
3. NSM temporarily mounts the completed snapshot volume on the mount host, which makes the volume ready for backup to the storage media.
The choice of mount host depends on the storage network configuration. A good plan considers the data processing speed and the bandwidth load on the different possible hosts. For example, the mount host can be one of the following components:
o A NetWorker storage node as shown in Snapshot and rollover with the storage node as the mount host
o The application host as shown in Snapshot and rollover with the application host as the mount host
o A remote mount host with NetWorker Client software installed
Note: If the NetWorker Client resource attributes specify the Client Direct and DD Boost options, then on-client data deduplication processing occurs on the mount host during rollover operations.
4. NSM manages the snapshot according to the options in the Client resource and Snapshot Policy resource:
· If NSM rolls over the snapshot to conventional storage media, the snapshot data becomes available for NetWorker clone operations and conventional NetWorker restore operations.
Note: After a rollover-only snapshot operation, NSM deletes the snapshot, and the snapshot is not available for further NSM operations.
· If NSM does not roll over the snapshot but retains the snapshot on the storage array only, the snapshot is available for an NSM snapshot restore or a rollback. NSM retains the snapshot until it expires or until NSM must delete it to create new snapshots, as specified by the snapshot policy.
The following figure and description of processes illustrate the data flow for a selective restore of files from a snapshot save set. The NetWorker storage node restores data from the snapshot target volume to the production source volume:
1. You select the snapshot that contains the data that you want to restore. NSM mounts this snapshot on the mount host.
2. You browse for the files, file systems, or volumes that you want to restore.
3. You specify where to restore the data on the application host or alternatively on a different host.
4. When you start the restore, NSM contacts the mount host and the application host or an alternative restore host.
5. NSM copies the data from the snapshot volume to the specified volume:
• For a save set restore or a file level restore, the data restore path is over the LAN as shown in Figure 3
• For a rollback recovery, the storage array capabilities perform the recovery from the snapshot LUNs to the production LUNs.
· NMDA supports NSM snapshot backups and re stores of DB2 and Oracle data on the primary storage, for example, EMC VNX Block (CLARiiON) or EMC VMAX (Symmetrix).
· NSM supports scheduled backups only, not manual (client-initiated) backups.
Types of NSM backups:
Snapshot backup (instant backup):
A snapshot backup, formerly known as an instant backup, creates a permanent point-in-time copy or snapshot of the data on the primary storage system. The snapshot is available to NMDA for performing snapshot restores or rollbacks. You can schedule a snapshot backup to occur many times in a single day with minimal impact to the database server or network.
You must configure a snapshot policy to control the lifecycle of the snapshot. The policy specifies the frequency of snapshot backups and how long to retain snapshots before recycling the snapshots.
Rollover-only backup (immediate live backup):
A rollover-only backup, formerly known as an immediate live backup, is also called a serverless snapshot backup. For this type of backup, NSM creates a temporary snapshot and immediately backs up the snapshot to secondary storage. The software then automatically deletes the snapshot from the primary storage so that NMDA cannot use the snapshot for performing snapshot restores or rollbacks.
NSM can use a proxy client host, also called the mount host, that is separate from the database server host to move the snapshot to the secondary storage. The use of a proxy client reduces the impact on the database server. The proxy client or mount host is typically a NetWorker storage node.
Snapshot and rollover backup (deferred live backup):
A snapshot and rollover backup, formerly known as a deferred live backup, creates a permanent snapshot and uses NSM to back up the snapshot to secondary storage. The permanent snapshot is retained on the primary storage and is available to NMDA for performing snapshot restores or rollbacks for the period specified by either of the following policies:
· Snapshot expiration policy
· Retain Snapshots attribute of the snapshot policy
Similar to a rollover-only backup, NSM can use a proxy client host, also called the mount host, to roll over the backup to secondary storage.
Types of NSM restores:
Snapshot restore (instant restore):
A snapshot restore, formerly known as an instant restore, retrieves the saved data from a mounted snapshot created through a snapshot backup. This type of restore requires a
minimal amount of time.
Restore from rollover (restore from secondary storage):
A restore from rollover, formerly known as a restore from secondary storage, restores a snapshot (saved to the secondary storage system) from the storage system to the database server. You can redirect this type of restore to a different host.
NSM supports two types of restore from secondary storage: conventional restore and file-logical image restore (FLIR). The NSM documentation provides details.
Note:The restore of snapshot data from the secondary storage requires the use of NSM.
A rollback restores an entire snapshot back to the source location on the database server by using the hardware capabilities. A rollback does not support relocation of the database to a different host because the relocation requires the reverse synchronization of the data between the snapshot and its original source.
NSM backup processes
An NSM snapshot backup includes the following processes:
1. At the time of a scheduled snapshot backup, the NetWorker server starts the NMDA nsrdasv process, which invokes the DB2 or Oracle RMAN backup.
2. The DB2 or Oracle backup process loads the NMDA libnsrdb2.xx or libnsrora. xx library, respectively. Each library communicates with NSM.
3. On the database server host, NSM takes a point-in-time (PIT) snapshot of the database data on the primary storage. NSM uses an application programming interface (API) specific to the storage system to take the snapshot. The snapshot then
becomes available to the proxy client (mount host).
4. If the backup type has a rollover, NSM on the proxy client moves the snapshot data on the primary storage to the NetWorker server or the storage node. The server or storage node stores the data on secondary storage, such as tape or disk. If required, NSM deletes the snapshot from the primary storage.
5. At the end of the snapshot backup, the NetWorker server updates the online client index and the media database with information about the backup.
DB2 considerations for NSM snapshot operations:
· IBM DB2 software provides a feature called Advanced Copy Services (ACS) that enables snapshots of DB2 data. The NMDA software works with ACS, NSM, and NetWorker software to back up snapshots of DB2 data.
· By default, DB2 ACS includes log files in the snapshot backups, in addition to data files. As a result, ensure that both data and log files are located on a snapshot table device. Otherwise, the snapshot backup fails.
· Due to a DB2 ACS limitation, NMDA with NSM only supports the snapshot backup and restore of the whole DB2 database. NMDA does not support the snapshot backup and restore of selected DB2 tablespaces, logs, or other files.
· S set up the automatic backup of transactions logs to protect the logs. The logs are required to run the db2 rollforward command to apply the transaction logs and recover a DB2 database to either the current time or a specific point-in-time. The automatic backup of transaction logs does not use snapshots. The logs are backed up through regular backups
Oracle considerations for NSM snapshot operations:
· Certain Oracle RMAN features, such as checking for corrupt blocks, are not applicable to NSM snapshot operations.
· NMDA supports proxy backups and restores of archived redo logs.
· Oracle does not support proxy backups of datafiles or archived redo logs that reside on Oracle Automated Storage. Oracle Automated Storage is also known as Oracle Automated Storage Management (ASM). “Replication Manager snapshot operations with Oracle ASM”