The Dynamic File Service Repair feature provides the following options to help ensure that a valid copy of the database files are available to the Service. Each of these functions is described in more detail later in this section.
Run a Report: Checks the consistency of configuration information in the pair, policy, and schedule database files. It reports health information and errors.
Take a Snapshot: Saves a snapshot of valid pair, policy, and schedule database files.
Restore a Snapshot: Replaces the current versions of the pair, policy, and schedule database files with the most recent snapshot that is available and valid.
When the Service starts, it automatically uses the Report capability to check the consistency of the pair, policy, and schedule database files. If fatal errors are detected, the Service rolls back to the most recent snapshot that is available and valid. The Service also runs the Snapshot function daily at a scheduled time to save a valid snapshot of the database files. These actions are performed only if the Service is running.
The option in the Service Controller menu allows an administrator to manually run the report, snapshot, and restore options as needed. The Dynamic File Service must be stopped before you can use the tool.
See the following sections to understand how the repair capability is used to detect problems in the pair, policy, and schedule database files.
The Dynamic File Services database files contain configuration information about the pairs, policies, schedules, and cloud accounts that you create on a server. The schedule information for the daily snapshot is also verified with the database files. Database files are stored by default in the C:\ProgramData\Dynamic File Services folder.
The Pairs folder contains the pairs database file (DswPairDatabase.xml) and a separate subfolder for each pair that you create on the server. The database file contains the configuration information for all of the pairs on the server. Each pair’s information begins with the <DswPairEntry> XML tag and ends with the </DswPairEntry> XML tag.
The subfolder for each pair is named with the pair’s GUID (globally unique identifier), such as f59058ea-ae9a-4352-bf3c-cc3a7d7fc443. In this subfolder, a PairSummaryHistoryTable.xml file and the PairRunHistoryTable.xml file store historical information for the individual pair. The repair capability does not check or repair a pair’s folder and historical information files.
The Policies folder contains the policy database file (DswPolicyDatabase_v2.xml). The database contains the configuration information for all of the policies that you create on the server. It also contains the configuration files for two global policies that you should not alter: the Global Conflict policy and the Global Remove Pair policy. Each policy’s configuration information appears between the <DswPolicyEntry> XML tag and </DswPolicyEntry> XML tag.
The Schedules folder contains the schedule database file (DswScheduleDatabase.xml).
The database contains the configuration information for all of the policy schedules on the server. Each schedule’s information begins with the <DswScheduleEntry> XML tag and ends with the </DswScheduleEntry> XML tag.
The Clouds folder contains the cloud account database file (DswCloudDatabase.xml).
The database contains the configuration information for all of the cloud accounts on the server. Each schedule’s information begins with the <DswCloudEntry> XML tag and ends with the </DswCloudEntry> XML tag.
The ..\Program Files\Dynamic File Services\DswCore.xml file contains the schedule information for the repair Snapshot function that is run daily by the Dynamic File Service. The default time is 23:30 hours (11:30 p.m.).
Dynamic File Services provides the Snapshot function as a precautionary measure to help resolve fatal errors that might rarely occur in the pair, policy, or schedule database files. If it is necessary, the Repair function can roll back the files to the most recent set of known-to-be-valid set of snapshot files. The Dynamic File Service has all of the permissions and rights necessary to run the Snapshot function.
The snapshots are taken by default between 11:30 p.m. and midnight daily. The time values for when the snapshot is taken are stored in the ..\Dynamic File Services\DswCore.xml file. There is no graphical interface option to change the time when the snapshots are taken. The Service must be running in order for the snapshot service to be called at its scheduled time and while the snapshot is being taken.
Each day at the scheduled time, the Dynamic File Service automatically calls the Snapshot function to take a snapshot of the pair database file, the policy database file the individual policy configuration files, and the schedule database file. For information about which files comprise the set of files that are saved in a snapshot, see Section 14.1.1, What Are the Database Files?.
Before a snapshot is taken, the database files are checked for consistency to ensure that they are valid. The known-to-be-valid set of files are stored in the C:\ProgramData\Dynamic File Services\SnapShot\day_of_the_week folder. If any one of the database files is found to have fatal errors, a snapshot is not saved.
Only one snapshot for each day of the week is kept at any given time. The snapshots are retained on a seven-day rotation.
Errors in the database files are expected to occur rarely, if at all. Common causes for corruption might be:
If a connection to the server is lost when you are creating a pair, a policy, or a schedule
If the server crashes while you are creating a pair, a policy, or a schedule
If the server crashes while you are modifying a policy or a schedule
If the file system where the database files are stored becomes corrupted
If you introduce errors by attempting to manually modify the content of a database file
When the Dynamic File Service starts, it automatically uses the repair capability to check the consistency of the pair, policy, schedule, and cloud account database files. The Service has all of the permissions and rights necessary to roll back to the last known-to-be-valid snapshot if necessary.
The database check on Service start performs the following tasks:
The Report function opens the pair, policy, and schedule database files and checks the consistency of information in them.
If errors are detected, all databases automatically roll back to the last known-to-be-valid snapshot.
The restore checks for recent database files in the same day’s folder first in case snapshots have been taken manually, or the Service is starting between 2300 and 0000 hours.
For information about the database snapshot process, see Section 14.1.2, Taking Daily Snapshots of the Database Files.
If a snapshot rollback repair effort fails, the Service does not start. An error message is logged in the Windows Event Logger.
Two failure events trigger an entry in the Windows Event Logger:
The repair capability does not respond when it is called by the Service to begin the database check.
A snapshot rollback fails because there is no snapshot available to roll back to.
The Repair tool allows you to manually run a report, take a snapshot, and restore the databases. The Service must be stopped in order to run the Repair tool.
When it is running, the Service keeps a copy of each of the databases in memory, and writes them to the database files when the Service stops. You stop the Service to access the Repair tool, which allows the changes to be made in the files, and not in memory. The changes apply when you restart the Service.
The Repair tool runs with the identity of the user that is logged in to the server’s desktop. This user needs file permissions on the Dynamic File Services software and data paths, including any remote shares used in pairs. If the user does not have access to all of the paths necessary, you get errors.
IMPORTANT:Typically, the user has Administrator privileges on the DynamicFS server, rights on the remote share, and NTFS file system access rights on the primary path and secondary path. Otherwise, the secondary location is reported as missing. One way to give the user the necessary rights is to add the user name as a member of the Dynamic File Services Storage Rights group. It does not matter if the user is also a member of the Dynamic File Services group.