Troubleshooting replication failures
The following are some scenarios in which a replication job can fail:
- The destination volume is offline.
- The destination volume was full.
- One of the volumes involved may have been unmounted.
- The replication process was rebooted while a replication job was in progress.
NoteWithout any further action upon a replication failure, the replication will continue as expected on its next scheduled run. However, this will recopy any changes already copied during the failed replication attempt.
Clicking Restart will cause the failed replication to be restarted immediately and will avoid recopying most of the data.
Manually restarting a failed replication
If a replication has failed, the
replication will be started normally at its next scheduled run time, rather
than "picking up where it left off." To restart the replication from the point
of failure (before its next scheduled time), you must restart it manually:
Procedure
Navigate to to display the File Replication page.
Click details for the failed replication to display its Replication Schedule page, and click restart.
Rolling back an incomplete replication
Upon successful completion of a replication, the system takes a snapshot to preserve the state of the target file system. With this snapshot, if an offline source leads to failure of a subsequent replication, the target file system can be rolled back to the state of the last successful replication.
To rollback the target file system to the state of the last successful replication:
Procedure
Navigate to to display the File Replication page.
Click details for the failed replication to display its File Replication Schedule page, and click rollback.
NoteRollback should only be used when the target will be used as the live file system. If the replication’s source file system cannot be used as the live file system (either permanently or temporarily), users can access the latest available data on the replication target (the file system created by the last successful replication). There are two possible approaches:- If the target file system will be used as the live file system permanently, delete the replication policy and all related schedules (since the source will not be used for this replication again). You can then create new replication policies and schedules.
- If the target file system will be used as the live file system temporarily, contact Hitachi Vantara Support Center for assistance in synchronizing the “old” (source) and the “new” (target) file systems before transferring access and resuming replication operations as implemented prior to the “rollback”.