6.0 Backing Up and Restoring NICI

Specific applications (some versions of eDirectory, for example) might provide alternate utilities that back up NICI when the application backs up its own data. In this circumstance, see the application’s documentation. Use the information in this chapter when the application does not provide these alternate utilities.

Backing up and restoring NICI requires two things:

The exact sequence of events required is platform-dependent.

NICI stores keys and user data in the file system and in system-specific and user-specific directories and files. The NICI installation program protects these directories and files by setting the proper permissions on them, using the mechanism provided by the operating system.

Uninstalling NICI from the system does not remove these directories and files; therefore, the only reason to restore these files to a previous state is to recover from a catastrophic system failure or a human error. Also, overwriting an existing set of NICI user directories and files might break an existing application.

When you back up and restore NICI, it is critical that you maintain the exact permissions on the directories and files. NICI’s operation and the security it provides depends on these permissions being set properly.

Typical commercial backup software should preserve permissions on the NICI system and user directories and files. You should check your commercial backup software to see if it does the job before you do a custom backup of NICI.

You should always back up the existing NICI directory structure and its contents, if any, before doing a restore. If you lose the machine key, it is unrecoverable. Because the user data and keys could be encrypted by using the machine key, losing it results in a permanent loss of user data.

To do a restore of NICI only, you must understand which specific files must be restored. During restoration, it is important that the correct access rights be restored for the correct owner. On UNIX and Windows systems, the name of the user-specific directory reflects the ID of the owner, but on both systems the owner ID might change between the time of the backup and the time of the restore. It is important for security reasons that you know which account is being restored and that you assign the directory name and access rights accordingly. The existence of a user account on the system with the same ID as an account that was backed up does not mean that the current account is the actual owner of the information being restored.