Nonauthoritative Restore Process

Version numbers are not retained with a file when it gets backed up. However, if the file was backed up from a replica set, it has a file object ID saved along with the other file attributes. The file object ID guides the nonauthoritative restore process.

Use a nonauthoritative restore to create a new replica member, which is the recommended course of action if an individual replica is lost. First, remove the failed member from the replica set. Then, restore the replicated share from the backup tape into what is to become the root directory for the new member. Next, add the member to the replica set, specifying the root path where the replicated share was just restored. Note that FRS has been running all this time, but because this member was removed from the replica set, none of the restored files has been replicated.

When FRS notices that the configuration has changed, it begins its initialization sequence to add the member. The first step is to move all the files just restored from the new replica's root directory to a temporary directory. Next, FRS joins with an inbound partner and requests information about every file in the replica share. The inbound partner supplies information such as the version number, file object ID, and so forth, for each file and folder. By using the file object ID, FRS locates the file or folder that was restored from tape and does a checksum-based comparison (using MD5) of the file contents with the corresponding checksum supplied by the inbound partner. If the checksums match, FRS places the file from tape into the replica share. Otherwise, FRS requests the file from the inbound partner. If the backup data is fairly current, few files are copied from the inbound partner.

At the conclusion of the nonauthoritative restore process, the file content and the version information on the new member match the content on the inbound partner. In essence, the files supplied from the backup tape are used only if they have file object IDs and their content matches the content of the corresponding file held by the inbound partner. This is especially valuable if the two members are linked by a low-speed network connection.