DataKeeper Target Snapshot

Overview

DataKeeper’s target snapshot feature, integrated with both DataKeeper and DataKeeper Cluster Edition, is the process of creating point in time copies of replicated volumes allowing access to data on a standby cluster node without interrupting data replication from the source system. Data protection is not lost for any period of time. Enabling target snapshot allows data to be used on an otherwise idle target node without negatively impacting the performance of the source.

Without target snapshot, DataKeeper and DataKeeper Cluster Edition are able to maintain a real-time replica of their source system’s data on the target system. However, this replica cannot be accessed without pausing the mirror and unlocking the target system. Mirror failover and switchover cannot occur while in this paused and unlocked state, making the protected application less highly available. Application-consistent target snapshot allows access to data on the target system while maintaining high availability of the running application on the source system. The mirror remains in the mirroring state and continues to update the target volume with all writes from the source. Target snapshot integrates with Volume Shadow Copy Service (VSS) to ensure that the data which is exposed on the target system is in an application-consistent state.

When To Use Target Snapshot

DataKeeper Target Snapshot is an alternative to using the “Pause and Unlock” command to access data on your target system. Target Snapshot provides the following benefits that Pause and Unlock does not:

• The mirror remains in the Mirroring state, and data continues to be replicated from the source system with no interruption.

• Multiple volumes can be snapshotted simultaneously.

• VSS-aware applications (like MS SQL Server) that are running on the source system are briefly quiesced using VSS in order to ensure that the data exposed on the Target system is in an application-consistent state.

How To Use Target Snapshot

Define Snapshot Location on Target system
In order to use the Target Snapshot feature, a Snapshot Location must be defined on the target system for each volume you plan to access. The Snapshot Location can be defined in the DataKeeper GUI, in the Mirror Properties dialog. It can also be defined by running the EMCMD SETSNAPSHOTLOCATION on the target system.

EMCMD <system> SETSNAPSHOTLOCATION <volume letter> “<directory path>”

Enable SIOS VSS Provider on Source system
DataKeeper target snapshot uses VSS to quiesce data on the mirror source system. DataKeeper has a VSS Provider component which is used to accomplish this. However, due to reported interference of the SIOS VSS Provider with some backup products, the provider is shipped in a disabled state. In order to take a snapshot, the VSS Provider on the mirror source system must be activated.

To activate the SIOS VSS Provider, run the script “install-siosprovider.cmd” which is located in “%ExtMirrBase%\VSSProvider”.

After you have taken a Target Snapshot, you may choose to de-activate it on the mirror source system by running the command “uninstall-siosprovider.cmd” in the same folder. If you are using a backup product that is incompatible with the SIOS VSS Provider, you should de-activate it using this command (see Known Issues below for incompatible products). However, if you are not using a product with such an incompatibility, you can leave the VSS Provider activated. Note: Any DataKeeper update will disable the provider, it must be re-enabled in order to take a target snapshot after this occurs.

The SIOS VSS Provider is only needed at the time that a snapshot is taken. The snapshot can be left in place on the target system after the provider has been deactivated, and the snapshot can be dropped while the provider is deactivated.

Execute the TAKESNAPSHOT command
After the Snapshot Location has been defined for each mirrored volume, and the SIOS VSS Provider is activated on the source system, the volumes can be made accessible on the target system by running the EMCMD TAKESNAPSHOT command:

EMCMD <target_system> TAKESNAPSHOT <volume letter> [<volume letter>…]

where <target_system> is the name or IP address of the target system, <volume letter> is the drive letter of one of the volumes to be snapshotted, [<volume letter>…] is the (optional) drive letter of another drive to be snapshotted at the same time, etc.

*This command/syntax can be run on any source or target system in the cluster. It is recommended to run the command/syntax on the target system.

How Target Snapshot Works

DataKeeper target snapshot uses a copy-on-write strategy to maintain and expose a view of the volume at a particular point in time. A snapshot file is used to store the volume information. Configuring the location of this snapshot file is the first step toward enabling target snapshot.

When the EMCMD TAKESNAPSHOT command is run, DataKeeper will create and mount a snapshot file in the configured snapshot folder. A request is then sent to the source system telling it to use VSS to quiesce any VSS writers on the given volume and notify the target when all write operations to the disk are stopped and the volumes are in a well-defined state.

Quiescing the Database/Application

The application-consistent capabilities of this feature integrate with Volume Shadow Copy Service (VSS) to ensure that the data that is exposed on the target system is in an application-consistent state. Once a snapshot is requested, the VSS service pauses the systems and ensures that all applications modifying data on disk bring all their files into a consistent state prior to the creation of the snapshot. This is called quiescing the database/application. Rather than shutting down the database and reopening it in restricted mode, quiescing temporarily freezes application write I/O requests (read I/O requests are still possible) for the short time required to create the snapshot. Once in the quiesced state, the snapshot on each volume is initiated by adding the snapshot message to the driver mirror write queue(s). VSS will then unfreeze the applications and the volume is unlocked, thus minimizing the amount of time the apps are quiesced. The user can now perform actions on the target system while the mirror remains in the Mirroring state and the application on the source system remains highly available.

Read and Write I/O Requests

The snapshot exists in parallel with the live copy of the volume to be backed up, so except for the brief period of the snapshot’s preparation and creation, an application can continue its work. Writes to the target, however, will now be processed differently while the target is in this state.

Data mirroring from the source system will continue uninterrupted, but any new data from the source that is received after the snapshot is taken will not be visible on the target system until the snapshot is dropped. This allows an application on the target system to run, using (and updating) data that represents the source system’s data at the point in time that the snapshot was taken.

Source Write

In order to accomplish source writes, when new data comes from the source, DataKeeper first determines if that particular block of data has already been written to the snapshot file.

If the block has not been written to, as shown above, that original block is written to the snapshot file in order to preserve the snapshot data, then the new data is written to the target. The result is shown below.

If DataKeeper determines that this block has already been written to the snapshot file, then this step is skipped and the block is just written to the target. For blocks on the source volume that are overwritten frequently, the snapshot file only has to be updated once, the first time that block is written after the snapshot is taken.

Local Write

If local writes are performed on the target (from applications on the target system), these writes are stored in the snapshot file and do not overwrite any blocks on the replicated volume itself. (Note: Any local writes stored in the snapshot file will be lost when snapshot is dropped.)

Target Read Request

Read requests on the target volume will return snapshot data. This is accomplished by first reading data from the blocks written in the snapshot file. Any blocks that have not been saved to the snapshot file will be read from the target volume.

Using Target Snapshot

There are three tasks that must be performed when using target snapshot. The snapshot location must be configured, the snapshot must be initiated, then once target reporting actions are complete, the snapshot must be dropped.

Configuring the Snapshot Location

When target snapshot is initiated, DataKeeper creates and mounts a file in the snapshot location to hold the snapshot data. This location must be configured prior to initiating a snapshot. See Files / Disk Devices / Registry Entries below for more information about the mounted snapshot disk(s).

When configuring the snapshot location, make sure it meets the following criteria:

• Is only used when a snapshot is requested.

• Cannot be stored on a DataKeeper mirrored volume.

• Can store multiple snapshot files for different volumes.

• Must have enough free space to create and accommodate a file that will grow depending on the source mirrored volume size and writes during snapshot use.

Note: Do not change the snapshot location during a snapshot.

Snapshot Location Size

The size of the snapshot location should be determined on an individual basis based on several criteria. In practice, the size required for the snapshot file will be far less than the size of the volume being snapshotted. The storage required needs to be big enough to contain any data that changes on the source system while the snapshot is being used. All snapshot files will be zeroed out each time a snapshot is initiated and will incrementally grow in size during use. The files will be deleted when the snapshot is dropped. Given that the copy on write process only writes “changed” blocks to the snapshot file, consideration should be given to the duration of the snapshot as well as the rate of change in the volume being mirrored. Once an historical view can be established of snapshots from past activity, the size can be re-evaluated.

* BEST PRACTICE: Be conservative in your estimate, assuring that there is excess space available. If enough space is not allocated and the limit is reached, your snapshot will be dropped.

Snapshot Location Selection

1. Right-click on the appropriate mirror and select Mirror Properties.

2. From the Mirror Properties dialog, select the Snapshots tab.

*NOTE: DataKeeper will use the snapshot location configured on the target node; however, since either node in the mirror can become target, the snapshot location may be configured on both the source and the target.

3. Use the browse button to choose the location for the snapshot or type the path into the text box.

When clicking the browse button that corresponds to the system where the GUI is running, the Browse for Folder dialog will appear. When clicking the browse button that corresponds to a system that is not the system where the GUI is running, the Browse for Folder On Remote dialog will appear.

4. Select your snapshot location for the source and the target. Make sure this volume has sufficient free space in order for the operation to complete successfully. Refer back to Snapshot Location Size for further details when estimating the volume size for your snapshot. Click Apply.

Note: Each volume on a given system can either use the same location or a different location can be selected.

	In order to Bypass the GUI*, the location of the snapshot file can be set via command line using the SETSNAPSHOTLOCATION command. In order to view the current snapshot location of a given volume, use the GETSNAPSHOTLOCATION command

Taking a Snapshot

Once a snapshot location has been configured on the target system, a snapshot can be taken. From the target node, run the EMCMD command TAKESNAPSHOT.

Dropping a Snapshot

When the snapshot is no longer needed, volume snapshots must be dropped in order to return to normal processing. Run the EMCMD command DROPSNAPSHOT which will lock the volume and clean up the snapshot files that were created. The volume will then return to a normal target where writes from the source will go directly to the volume with no copy-on-write storage.

Note: In Windows 2012R2, you will see the warning message “Disk # has been surprise removed.”

Disabling Target Snapshot for a Given Volume

To disable target snapshot for a given volume, the snapshot location must be cleared. This can be accomplished via the GUI.

1. Right-click on the appropriate mirror and select Mirror Properties.

2. From the Mirror Properties dialog, select the Snapshots tab.

3. Remove the snapshot folder of the volume you would like target snapshot disabled on.

4. Click Apply.

	IThe snapshot file location can also be cleared via command line by executing the CLEARSNAPSHOTLOCATION command.

Once successfully executed, a snapshot location will have to be reconfigured in order to initiate another snapshot of that volume.

Target Snapshot Notes

Supported Configurations

DataKeeper target snapshot is currently supported in non-shared (1×1 and 1×1×1) environments on all Windows OS versions supported by SPS.

Source Out of Service

DataKeeper target snapshot cannot be initiated when the source is out of service. However, if the source is taken out of service after snapshot is initiated, the snapshot will continue to work as expected. You can continue to use the snapshot, and drop it when you are done, while the source is out of service.

Switchovers and Failovers

If a snapshot is in progress, the volume being snapshotted cannot become the mirror source until the snapshot has been dropped. You must perform a DROPSNAPSHOT in order to allow a switchover or failover of the volume to the local node. Any processes that access data on the snapshotted volume will have their handles invalidated when the snapshot is dropped. However, if the volume is subsequently unlocked, you must make sure that those processes do not re-open their handles. At this point the data will be “live” application data and not the snapshotted data.

Note: To provide protection during SQL Server recovery we provide a generic script that needs to be added to stop the reporting SQL instance on the target node. Instructions are located in DKSnapshotCleanup.vbs script located in “\support”. Please review the script code on how to add to your WSFC hierarchy.

Files / Disk Devices / Registry Entries

When a snapshot is taken, a snapshot file is created for each snapshotted volume in that volume’s snapshot location. The name of the file that is created is datakeeper_snapshot_vol<X>.vhd, where <X> is the drive letter. This VHD file gets attached as a virtual disk device which can be seen in Windows Disk Management.

*NOTE: The colored icon next to the disk number represents this disk as a VHD.

! CAUTION: The virtual disk devices that are created will appear as unpartitioned Basic disks. They should be used for snapshot data only and should not be detached or partitioned while snapshots are in progress. Doing so may result in corruption of the snapshot data. Make sure that they are not mistaken for available disks to be partitioned and formatted.

Once these virtual disk devices are attached, a registry entry named SnapshotDevice is created in the volume’s key. The value is set to \\.\PHYSICALDRIVE<x> where <x> is the disk number, as shown below:

TargetSnapshotBlocksize Registry Value

DataKeeper target snapshot uses a default block size of 64KB for all entries that are written to the snapshot file. This block size can be modified by creating a REG_DWORD value named TargetSnapshotBlocksize in the Volume registry key.

The value should always be set to a multiple of the disk sector size, which is usually 512 bytes. Certain workloads and write patterns can benefit from changing the block size. For example, a volume that is written in a sequential stream of data (e.g. SQL Server log files) can benefit from a larger block size. A large block size results in fewer reads from the target volume when consecutive blocks are written. But a volume that is written in a random pattern may benefit from a smaller value or the default 64KB. A smaller block size will result in less snapshot file usage for random write requests.

SQL Server Notes

If you are using DataKeeper target snapshot with SQL Server in a SIOS Protection Suite environment, it is recommended that you use a separate SQL Server instance to attach database(s) to the snapshot.

For a clustered SQL Server environment, you must use a separate SQL Server instance to attach database(s) to the snapshot.

Known Issues

SIOS VSS Provider Incompatible with some backup products

The SIOS VSS Provider component has been reported to cause backups to fail when using the following backup products:

• IBM Tivoli Storage Manager
• Microsoft Data Protection Manager

Microsoft .NET Framework 4.5.2 Requirement

The target snapshot feature requires Microsoft .NET Framework 4.5.2 to be installed – download from: http://www.microsoft.com/net.

NTFS File System Message

If an internal snapshot error occurs after target snapshot is initiated (such as the snapshot file running out of space or being detached by the user), snapshot will be disabled, the volume will be locked and snapshot files for any failed volumes will be deleted. While the snapshot error is being handled, you may receive NTFS file system errors. These messages are normal and can be ignored.

Application Data Using Snapshot

When using target snapshot data with your application, if the target snapshot is refreshed, you may need to close and reopen your application(s) to refresh the data.

Volume Shadow Copy Service (VSS) Free Disk Space Requirements

If your target snapshot volume has insufficient disk space, VSS operations involving that volume may fail with an “unexpected error”. To avoid this, your snapshot volume should follow the guidelines from the Microsoft article Troubleshoot VSS issues that occur with Windows Server Backup (WBADMIN) in Windows Server 2008 and Windows Server 2008 R2.

This article provides the following requirements for free disk space:

For volumes less than 500 megabytes, the minimum is 50 megabytes of free space. For volumes more than 500 megabytes, the minimum is 320 megabytes of free space. If the volume size is more than 1 gigabyte, a minimum of at least 1 gigabyte of free disk space on each volume is recommended.

Copyright © 2024 SIOS TECHNOLOGY CORP.