Can't find what you are looking for?

Click here to open a case.



Reset Search
 

 

Article

DPX Open Storage Server Migration Guide

« Go Back

Information

 
Details

Overview

Customers using the DPX Open Storage Server solution occasionally need to relocate backup data on the server to a different host or volume for various reasons. An in place upgrade of the existing server or volume is not feasible or desirable in these cases. After the migration, any existing backups should continue to operate without change and should be directed to the new target location.
 
An open storage server host likely protects data for several clients and maintaining the integrity of this data is paramount. Also, the amount of data stored on the server is potentially large. Copying this vast quantity of data reliably is of utmost importance. As an added measure of security, verification of the copied data is required to ensure that existing restore points are not compromised and that a critical warning is generated if they are so that appropriate measures can be taken to resolve the issues prior to retiring the existing server.
 
This document describes the recommended methods for performing data migration and cutover to a new server. It is the customer’s responsibility to follow all documented procedures accurately in order to guarantee that data integrity is maintained. Any deviation may cause data corruption, loss of recovery points or other significant disruptions.
 

Prerequisite actions

Backup data on the open storage server host is maintained in the form of logical snapshots which are represented by a set of linked files on the server volumes. Any change in these files or their linkage during the data copy process can adversely impact the copy and result in a corrupted snapshot being created on the new server.
 
In order to avoid interfering with the copy, the following mandatory actions must be performed irrespective of the method chosen for migration. Each method may also require additional prerequisite actions. Performing a catalog backup prior to migration is strongly recommended.
  • Disable the condense job and verify that any background batch condense operation previously initiated has completed on the server.
  • Suspend all backup jobs that are directed to the server.
  • Prevent any restore activity that needs access to data on the server.
  • Disconnect all LUNs that map data from existing snapshots on the server. The iSCSI service on the server may be stopped to ensure that no activity takes place inadvertently.
  • Disable any applications on the server that perform file system changes or access the snapshot files (Ex. Virus scanners or disk defragmentation)
 
DPX client software, including the open storage server package, must be installed on the new server host, and a corresponding node must be added to the Enterprise.

Copy based relocation

This method employs the DPX Copy feature for replicating data from the original open storage server host to new server host. The advantage of using this method is that data movement can be accomplished with a single step and without using an intermediate repository. However, it may not be suitable if the replication must occur over a WAN or other less reliable network especially if the amount of data to be copied is sufficiently large.
 
Before starting the copy operation, the following additional prerequisite actions should be performed as directed.
  • Recommended - Stop the Catalogic DPX Advanced Protection Manager Service on the current open storage server host. This is an additional safeguard to prevent inadvertent updates to existing snapshots while the copy operation is active.
 
To perform the copy, define and run a standard DPX Copy Job as illustrated below. It is strongly recommended that a separate Job be used to migrate each data volume on the current open storage server host.
 
Figure 1 - Create a new Copy Job selecting the source volume on the current open storage server host and the desired destination volume on the new open storage server host

User-added image

Figure 2 - Specify the prepackaged data validation script configured as shown for use as Pre and Post scripts of the Copy Job.

User-added image
 
The recommended Pre and Post script definitions are shown below for additional clarity:

 
jsescript@<DOSS source> --runlimit 0 --jobid %JOBID --runclass com.syncsort.bex.utils.SnapValidator -- --checksum create --volume <Source vol> --verifysnap
jsescript@<DOSS destination> --runlimit 0 --jobid %JOBID --runclass com.syncsort.bex.utils.SnapValidator -- --checksum verify --volume <Destination vol> --verifysnap


Figure 3 - Hold all Block Backup and Condense Jobs as mandated before running the Copy Job.

User-added image

Figure 4 - Review Job schedule for a future date as well to verify held selections.

User-added image
 
 
Verify that the Copy Job completes without any errors (See the Appendix for sample output from successful Pre and Post script executions). Then perform the post relocation actions as described later in this document.

Archive based relocation

This method employs the DPX Image Backup feature for replicating data from the original open storage server host to new server host. The advantage of using this method is that an implicit backup of the existing server is created first and can be reused as a restore point in future. It is also the preferable method when the new open storage server host is located at a geographically distant location or connected via a low bandwidth network. The disadvantage is that media storage (disk or tape) is required to hold the complete data size of the existing server.
 

Post relocation actions

When all data from the existing open storage server host has been successfully migrated to the new server, perform the following steps in sequence to reconfigure the Enterprise and begin using the new server.
 
Delete the Node entry for the new open storage server host (must be done to prevent duplicate IP@/hostname)Update the configuration for the original open storage server Node so that it reflects the new server address.Existing Job definitions must be updated if any of the following is trueThe Nodes for the existing and new open storage server hosts are to be retained in the Enterprise. In this case update Job definitions to select the new open storage server host.The volume identifiers on the new open storage server host are not identical to those on the existing open storage server host. Here the target volume selections must be updated in each Job definition.Update any Job definitions with Pre or Post Job scripts that execute on the original open storage server host and redirect these to the new open storage server host address.Reverse the appropriate actions performed in the prerequisite sectionVerify that the next set of scheduled backups occurs as expected to the new server. The backups should perform incremental data transfers based on the last successful backup event to the original server. It is strongly recommended that data verification be performed for all volumes after the first backup following relocation.Verify that the next condense operation is successful on the new serverOnly when all operations have been checked should the old server be decommissioned. 

About the script

The previous sections only presented a small glimpse into the capabilities of the SnapValidator script that is provided with DPX. The script is a versatile utility designed to work as an independent Java Application in addition to being used as a Pre or Post script for a DPX job.
 
While it was primarily developed to assist with open storage server data verification needs, the script can easily be used as a general purpose checksum generator or directory scanner. Please consult the Javadoc (included in the userscripts.zip archive) for details regarding the supported options and their behavior.
 
In order to run the script as a Java Application, the following DPX library dependencies must be accessible and added to the Classpath: jse.jar, bexclasses.zip. Launch the application using the following command which will display brief usage syntax information.
 
>java -cp userscripts.zip;JSE.jar;bexclasses.zip com.syncsort.bex.utils.SnapValidator --help


By default, the script generates a MD5 hash checksum value since this provides the best balance of performance and security needs for the verification use case.  A different hash algorithm may be chosen by using the “--method” option and specifying any supported standard algorithm name as the option value. The script was tested with values – SHA-1, SHA-256, SHA-512 and MD2.
 
It is possible to exclude files from the operation by using the “--filter” option and specifying any valid Regular Expression pattern as the option value. This provides a finer grained control when required.
 

Performance

The performance of the script when the checksum option is selected greatly depends on the I/O subsystem of the host since it reads the complete contents of each selected file under the specified root directory in order to compute the checksum value. For sparse files, like the open storage server snapshots, this will even read the “holes” and can therefore take a considerable time even though the actual size of the file on disk appears to be small.
 
To calculate the approximate time required for a specific execution based on the selected volume(s), root directory and filter, first determine the total data size that must be processed by executing a run using the “--checksum scan” option. Note the reported size statistics for each volume:
 
INFO: Size stats for directory(E:\.BackupExpressSnapshots): Total Logical Size(1,359,787,491,517); Total Real Size(N/A)

Next, execute another run using the desired checksum operation while selecting a representative sample subset of the data. Note the reported performance and size statistics:
 
INFO: Performance stats for directory(E:\.BackupExpressSnapshots\SSSV_DOSS_Win\{BEX-453A-5333322102A0}\[DOSS_Win]QA41CLIENTW@{9665DF2B}): Processed Files(9); Duration(177.78s); Rate(0.05 files/sec)
INFO: Size stats for directory(E:\.BackupExpressSnapshots\SSSV_DOSS_Win\{BEX-453A-5333322102A0}\[DOSS_Win]QA41CLIENTW@{9665DF2B}): Total Logical Size(21,485,706,611); Total Real Size(N/A)


The estimated run time for the actual operation can then be calculated by extrapolating the results from the sample run scaled to the total expected data size.
 

Appendix

 
Nibbler log segment showing start and end of a “batch” snapshot condense operation. This can be obtained by scanning the Nibbler log for lines containing “condense_demon”:
 
Mar 26 03:24:10 2014:1456:INFO:condense_demon: [4]th thread, vol[E:], in-queue[12], failed/skipped[0], thread-busy[0]
Mar 26 03:24:10 2014:1456:INFO:condense_demon: Queue[E:]: [4]th thread[ID=2908] started
Mar 26 03:24:10 2014:1456:INFO:condense_demon: to wait for [1] threads
Mar 26 03:24:41 2014:1456:INFO:condense_demon: [4]th thread signalled. rc=[0]
Mar 26 03:24:41 2014:1456:INFO:condense_demon: current batch done
Mar 26 03:24:41 2014:1456:INFO:condense_demon: to wait for next batch

Prescript output:
Mar 26, 2014 5:41:59 PM com.syncsort.bex.utils.SnapValidator run INFO: Check log file(C:\Program Files\DPX\logs\SnapValidator5632770143067801915.log) for task detail info
Mar 26, 2014 5:41:59 PM com.syncsort.bex.utils.SnapValidator run INFO: SnapValidator args: com.syncsort.bex.utils.SnapValidator --checksum create --volume E: --verifysnap 
Mar 26, 2014 5:41:59 PM com.syncsort.bex.utils.SnapValidator verifySnapChain INFO: Performing verify snap operation using command: C:\Program Files\DPX\bin\nibbler -f -c verifysnap 
Mar 26, 2014 5:42:29 PM com.syncsort.bex.utils.SnapValidator verifySnapChain INFO: Verify snap operation completed
Mar 26, 2014 5:42:29 PM com.syncsort.bex.utils.SnapValidator executeChecksumAction INFO: Checksum operation(CREATE) started
Mar 26, 2014 5:42:29 PM com.syncsort.bex.utils.SnapValidator executeChecksumAction INFO: Processing for volume(E:) started
Mar 26, 2014 5:42:29 PM com.syncsort.bex.utils.SnapValidator executeChecksumAction INFO: Performing checksum operation(CREATE) on root path(E:\.BackupExpressSnapshots)
Mar 26, 2014 7:35:55 PM com.syncsort.bex.utils.SnapValidator executeChecksumAction INFO: Checksum operation(CREATE) on root path(E:\.BackupExpressSnapshots) completed
Mar 26, 2014 7:35:55 PM com.syncsort.bex.utils.SnapValidator executeChecksumAction INFO: Operation stats for directory(E:\.BackupExpressSnapshots): Total Files(1,550); Processed Files(1,548); Duration(6805.26s); Rate(0 files/sec)
Mar 26, 2014 7:35:55 PM com.syncsort.bex.utils.SnapValidator executeChecksumAction INFO: Processing for volume(E:) completed
Mar 26, 2014 7:35:55 PM com.syncsort.bex.utils.SnapValidator executeChecksumAction INFO: Checksum operation(CREATE) completed
Mar 26, 2014 7:35:55 PM com.syncsort.bex.utils.SnapValidator executeChecksumAction INFO: Cumulative stats: Total Files(1,550), Processed Files(1,548); Duration(6805.26s); Rate(0 files/sec)
Mar 26, 2014 7:35:55 PM com.syncsort.bex.utils.SnapValidator run INFO: SnapValidator completed with status(0)


Postscript output:
Mar 26, 2014 7:41:29 PM com.syncsort.bex.utils.SnapValidator run INFO: Check log file(C:\Program Files\DPX\logs\SnapValidator5960339037732346990.log) for task detail info
Mar 26, 2014 7:41:29 PM com.syncsort.bex.utils.SnapValidator run INFO: SnapValidator args: com.syncsort.bex.utils.SnapValidator --checksum verify --volume E: --verifysnap 
Mar 26, 2014 7:41:29 PM com.syncsort.bex.utils.SnapValidator verifySnapChain INFO: Performing verify snap operation using command: C:\Program Files\DPX\bin\nibbler -f -c verifysnap 
Mar 26, 2014 7:42:12 PM com.syncsort.bex.utils.SnapValidator verifySnapChain INFO: Verify snap operation completed
Mar 26, 2014 7:42:12 PM com.syncsort.bex.utils.SnapValidator executeChecksumAction INFO: Checksum operation(VERIFY) started
Mar 26, 2014 7:42:12 PM com.syncsort.bex.utils.SnapValidator executeChecksumAction INFO: Processing for volume(E:) started
Mar 26, 2014 7:42:12 PM com.syncsort.bex.utils.SnapValidator executeChecksumAction INFO: Performing checksum operation(VERIFY) on root path(E:\.BackupExpressSnapshots)
Mar 26, 2014 9:37:21 PM com.syncsort.bex.utils.SnapValidator executeChecksumAction INFO: Checksum operation(VERIFY) on root path(E:\.BackupExpressSnapshots) completed
Mar 26, 2014 9:37:21 PM com.syncsort.bex.utils.SnapValidator executeChecksumAction INFO: Operation stats for directory(E:\.BackupExpressSnapshots): Total Files(3,096); Processed Files(1,548); Duration(6908.60s); Rate(0 files/sec)
Mar 26, 2014 9:37:21 PM com.syncsort.bex.utils.SnapValidator executeChecksumAction INFO: Processing for volume(E:) completed
Mar 26, 2014 9:37:21 PM com.syncsort.bex.utils.SnapValidator executeChecksumAction INFO: Checksum operation(VERIFY) completed
Mar 26, 2014 9:37:21 PM com.syncsort.bex.utils.SnapValidator executeChecksumAction INFO: Cumulative stats: Total Files(3,096), Processed Files(1,548); Duration(6908.60s); Rate(0 files/sec)
Mar 26, 2014 9:37:21 PM com.syncsort.bex.utils.SnapValidator run INFO: SnapValidator completed with status(0)
 

 
Reference Document 
Article TypeLong Form
Article Number000004988
Article Created Date3/30/2017 5:25 PM

Feedback

 

Was this article helpful?


   

Feedback

Please tell us how we can make this article more useful.

Characters Remaining: 255