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 impacting operations such as switchovers and failovers. 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.
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 command,
TAKESNAPSHOT, 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.
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.
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.
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.
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.
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.
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).
IMPORTANT: The maximum size of a volume to be snapshotted is 2 TB.
When configuring the snapshot location, make sure it meets the following criteria:
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
- Right-click on the appropriate mirror and select Mirror Properties.
- 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.
- 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.
- 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.
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.
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.
To disable target snapshot for a given volume, the snapshot location must be cleared. This can be accomplished via the GUI.
The 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.
DataKeeper target snapshot is currently supported in non-shared (1x1 and 1x1x1) environments using Windows 2008 R2 and Windows Server 2012.
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.
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 "<DataKeeper Install Path>\support". Please review the script code on how to add to your WSFC hierarchy.
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
<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
<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.
If you are using DataKeeper target snapshot with SQL Server in a SteelEye 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.
The target snapshot feature requires Microsoft .NET Framework 3.5 SP1 to be installed - download from: http://www.microsoft.com/net.
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.
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.
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.
© 2013 SIOS Technology Corp., the industry's leading provider of business continuity solutions, data replication for continuous data protection.
Open topic with navigation