If a snapshot rollback repair occurs, you should use the Management Console to review the recovered pairs, policies, schedules, and cloud accounts to ensure that they reflect any recent configuration changes that you made. This section provides information about what to do after a snapshot rollback repair.
Section 14.5.2, What If an Old Pair’s Secondary Data Appears After a Snapshot Rollback Repair?
Section 14.5.3, What If Policies Run or Don’t Run as Expected After a Snapshot Rollback Repair?
Section 14.5.5, What If a Pair Database Error Cannot Be Fixed?
Section 14.5.6, What If a Policy Database Error Cannot Be Fixed?
Section 14.5.7, What If a Schedule Database Error Cannot Be Fixed?
When a rollback repair occurs, the pair database file rolls back to the latest known-to-be-valid version of the file. The recovered file might not contain pair information for a recently created pair. When users access the share on the primary location, they see only the data on the primary location because the pair definition is not available.
To resolve this problem, you can create the pair again as described in Section 8.2, Creating a Pair. This adds the pair configuration information to the recovered pair database file. The merged view begins to work, and users see data on both the primary and secondary locations.
When a rollback repair occurs, the pair database file rolls back to the latest known-to-be-valid version of the file. The recovered file might not contain pair information for a recently unlinked pair. When users access a share on the primary location, they see a merged view that includes the old pair’s secondary location.
To resolve this problem, you can unlink the pair again as described in Section 8.13, Unlinking the Paths in a Pair. This removes the pair configuration information from the recovered pair database file. Users see data only on the primary location.
When a rollback repair occurs, the policy database file and the related policy files and schedule files roll back to the latest known-to-be-valid version of the files. The recovered files might not contain recent changes that were made to the policies or their associations. As a result, policies might run or not run as expected.
After a rollback repair occurs, you should review the recovered policies in the Management Console to verify that the recovered policies reflect any recent changes, such as the following:
New policy
Deleted policy
Added or removed pair-to-policy association
Added or removed policy-schedule-to-policy association
Modified filter options
Modified direction
Renamed policy
To resolve this problem, you can make the changes again.
When a full rollback repair occurs, the pair, policy, and schedule databases roll back to their latest known-to-be-valid versions. The recovered files might not contain recent changes that were made to schedules and their associations. As a result, review notifications might run or not run as expected.
After a rollback repair occurs, you should review the recovered schedules in the Management Console to verify that the recovered schedules reflect any recent changes, such as the following:
New schedule
Deleted schedule
Added or removed review-schedule-to-retention-pair association
Added or removed policy-schedule-to-policy association
Modified frequency
Renamed schedule
To resolve this problem, you can make the changes again.
If the fatal errors in the pair database file cannot be repaired because no snapshot files are available, you can try to clean up the database file, then re-create the pair. However, if the pairs database file is totally corrupted, you must delete the …\Dynamic File Services\Pairs\DswPairDatabase.xml file and re-create all pairs.
To clean up the pairs database file and re-create selected pairs:
Identify where the pair errors occurred:
Open the …\Dynamic File Services\DswRepair.log in a text editor.
From the log, note the GUID and name of each pair where fatal errors occurred.
Close the file.
Clean up the pair database file:
Open the …\Dynamic File Services\Pairs\DswPairDatabase.xml file in an XML editor.
A pair’s information begins with the <DswPairEntry> XML tag and ends with the </DswPairEntry> XML tag. Remove the tags and the information about the pair in between them.
Save the edited file.
In the Pairs folder, delete the pair history subfolders that correspond to the pairs you deleted from the database.
You need the pair’s GUID to recognize which subfolder belongs to a pair.
Re-create the pair as described in Section 8.2, Creating a Pair.
Associate each re-created retention pair with a review schedule.
Associate each re-created pair to one or more policies.
If the fatal errors in the policy database files cannot be repaired because no snapshot files are available, you can clean up the policy database and individual policy files, then re-create the policies. However, if the files are totally corrupted, you must delete the …\Dynamic File Services\Policies\DswPolicyDatabase_v2.xml file and re-create all policies.
To clean up the policies database files and re-create selected policies:
Identify where the policy errors occurred:
Open the …\Dynamic File Services\DswRepair.log in a text editor.
From the log, note the GUID and name of each policy where fatal errors occurred.
Close the file.
Clean up the policy database files:
Open the …\Dynamic File Services\Policies\DswPolicyDatabase_v2.xml file in an XML editor.
For each policy that has corrupted information, remove the policy’s configuration information from the file.
Save the edited file.
Use either of the following methods to re-create the policy:
Re-create the policy as described in Section 9.2, Creating a Policy.
If you previously exported a policy, you can import the policy to add it back in the database.
Associate a policy schedule to the re-created policy if you want it to run automatically.
Associate one or more pairs to the policy.
If the fatal errors in the schedule database files cannot be repaired because no snapshot files are available, you can clean up the database file, then re-create the schedules and associate them again with policies. However, if the file is totally corrupted, you must delete the …\Dynamic File Services\Schedules\DswScheduleDatabase.xml file and re-create all of the schedules.
To clean up the schedules database files and re-create selected schedules:
Identify where the schedule errors occurred:
Open the …\Dynamic File Services\DswRepair.log in a text editor.
From the log, note the GUID and name of each schedule where fatal errors occurred.
Close the file.
Clean up the schedule database files:
Open the …\Dynamic File Services\Schedules\DswSchedulesDatabase.xml file in an XML editor.
For each schedule that has corrupted information, remove its information from the file.
Save the edited file.
Re-create the schedule as described in Section 10.0, Creating and Managing Policy Schedules.
Associate each of the re-created policy schedules with one or more policies.