17.4 Preparing for a Restore

The most important part of restoring the eDirectory database is making sure it is complete. Before restoring an eDirectory database to a server, ensure the prerequisites have been met as described in Prerequisites for Restoring. If you are not sure how to gather the right backup files, see Locating the Right Backup Files for a Restore.

17.4.1 Prerequisites for Restoring

  • All servers that share a replica with the server to be restored are up and communicating. This allows the restore verification process to check with servers that participate in the same replica ring.

  • You have gathered all the backup files you need:

    • The full backup and subsequent incremental backup files are copied to one directory on the server to be restored.

    • All roll-forward logs since the last backup are in one directory on the server to be restored.

      If this server participates in a replica ring, you must make sure all the roll-forward logs created since the last backup are in one directory on the server, with the same filenames they had when they were created.

    See Locating the Right Backup Files for a Restore.

    NOTE:If you do not have backup files for the server, use Xbrowse to query eDirectory to help you recover server information. You must do this before you remove the Server object or any associated objects from the tree.

    Xbrowse and additional information is available from the NetIQ Support Web site.

  • You have installed eDirectory, in a new temporary tree.

    You bring up the server in a new tree at first because you will create the server with the same name it had before the failure, and you don't want to cause confusion in the original tree by putting the newly installed server in the tree before the restore has re-created the server's complete identity. Completing the restore process for the database will put the server back into its original tree.

  • (Conditional) If you are using roll-forward logging on this server, plan to re-create your configuration for roll-forward logging after the restore, to make sure it is turned on and the logs are being saved in a fault-tolerant location. After turning on the roll-forward logs, you must also do a new full backup.

    The restore process turns off roll-forward logging and resets the configuration for roll-forward logging back to the default.

    The new full backup is necessary so that you are prepared for any failures that might occur before the next unattended full backup is scheduled to take place.

  • (Conditional) If any applications or objects need to find this server by its IP address, use the same IP address for the restored server.

During the restore process, the eDirectory Backup Tool first restores the full backup. After this is complete, the Backup Tool prompts you to enter the filenames of the incremental files. It provides you with the ID of the next file. After all incremental files are restored, the Backup Tool moves on to the roll-forward logs. See also Overview of How the Backup Tool Does a Restore.

After you have gathered all the files, perform the restore using either iManager or the DSBK Client. See Restoring from Backup Files with DSBK or Restoring from Backup Files with iManager.

17.4.2 Locating the Right Backup Files for a Restore

  1. From your file system backup tape, copy the eDirectory full backup files to one directory on the server.

    You can check the Backup Tool log file if you want to confirm the ID of the last full backup.

  2. From your file system backup tape, also copy each of the subsequent incremental backup files to the a directory on the server.

    To confirm that you have the right incremental backup files, look in the header of the full backup file. It contains the ID of the next incremental backup file, shown in the next_inc_file_ID attribute. The next_inc_file_ID is the same as the ID noted in the header of the incremental backup file in the incremental_file_number attribute. For a description of the header, see Format of the Backup File Header.

    WARNING:When opening a backup file, just view the header—make sure you don't try to save or modify the file, or it might become truncated. Most applications can't save the binary data correctly.

    Each incremental backup file will also contain the ID for the next incremental backup file.

    You can also look for the incremental backup ID in the Backup Tool log file.

    The IDs are important because your backup files might have had the same filenames when they were created (for example, if you used the same batch file for unattended incremental backups so the backup filename specified was always the same), and you might have to change the filenames so you can place all the backups in the same directory. The ID in the header lets you find the correct files even if you have changed the filenames.

  3. (Conditional) If you are using roll-forward logging on this server, make sure the roll-forward logs created since the last backup are in one directory on the server, with the same filenames they had when they were created.

    If this server participates in a replica ring, you must restore using all the roll-forward logs. If you don't include all the roll-forward logs, the restore verification process will not be successful because the transitive vectors will not match when compared to the other replicas in the ring. By default the restored eDirectory database will not open after the restore if it is inconsistent with the other replicas.

    Identify the first roll-forward log you need by opening the last backup file in a text editor and reading the current_log attribute in the header. You will need to collect this one and all the subsequent roll-forward logs.

    WARNING:When opening a backup file, just view the header—make sure you don't try to save or modify the file, or it might become truncated. Most applications can't save the binary data correctly.

    The roll-forward logs you need might not all be in the same location at the time you want to use them for a restore, so you need to make sure you have collected a complete set and placed them all in the same directory. The roll-forward logs might be in multiple locations for the following reasons:

    • You have changed the location of the roll-forward logs directory since the last full or incremental backup.

    • You have backed them up to tape using file system backup and then have removed them from the server, to save disk space.

      If you need to retrieve any of the roll-forward logs from tape backup, make sure you have the most current set. You must compare time stamps for any files that are duplicated on the tape and on the server. The roll-forward log file that was in use by the database during the time of the file system backup will be incomplete on the tape. The latest and complete version of that file will be on the server.

    • You have changed the name of the eDirectory database since the last backup (such as from NDS to ND1). This changes the last directory name in the path to the roll-forward logs.

      For example, if the location you specified was d:\novell\nds\dibfiles\, and the name of your eDirectory database was NDS, the location of the roll-forward logs would be d:\novell\nds\dibfiles\nds.rfl\. If you renamed the database from NDS to ND1, the roll-forward log directory would change to d:\novell\nds\dibfiles\nd1.rfl\.

    IMPORTANT:You must ensure that you provide all the necessary roll-forward logs. The Backup Tool cannot tell whether your set of roll-forward logs is complete. It will open and use the roll-forward logs in order. When it cannot find the next roll-forward log in the directory you specified, it ends the restore process. If you have not provided all the necessary roll-forward logs, the restore will be incomplete.