The difference between a normal restore and a full system restore is the severity of the problem. Normally, if data is lost or removed, it is recovered from the archives using the normal restore procedures. However, when a normal restore operation cannot correct a software and/or hardware corruption problem, some additional changes may be required.
The level of system restore required may be different as described below.
When the database is corrupted and a restore is required, both the application software and database must be restored. This can be achieved by performing the following steps:
Restoring the application by using the file system Agent restore options.
Restoring the database files using the restore options in the Agent.
When the client system (operating system, hardware, hard drives, etc.) is damaged or destroyed, a full system restore may be required.
In the case of disaster recovery, where a full system restore is required, you must rebuild the system to exactly the state as it existed before the problem. In some cases, where the Documentum Repository is corrupted, the Documentum software must be reloaded and the server rebuilt. To resolve a hardware corruption problem, see the appropriate Documentum documentation.
Preparing for a Full System Recovery
Before an unplanned disaster strikes, do the following:
Perform regular backups of Documentum and database binaries using the Unix File System iDataAgent.
Perform regular backups of Documentum configuration files (e.g., server.ini, Docbroker.ini, dfc.properties) and database configuration files using the Unix File System Agent.
Using the Documentum Agent, perform a full repository backup that includes the database, storage areas, and full-text indexes.
Perform frequent backups of logs and data with control files will also aid in successfully performing a successful disaster recovery procedure.
Ensure to exclude database and log files from the backup performed using the Unix File System Agent. This can be achieved by configuring a backup filter in the subclient to exclude these files (e.g., .dbf).
Once an application has been discovered, the version of the application on which the Agent was installed or upgraded on the client computer is displayed in the Instance Properties (General) tab. This can be particularly useful in disaster recovery situations when you need to rebuild the environment.
Oracle Database Considerations
If using an Oracle database, the following considerations are recommended:
Ensure that the recovery catalog is available on a separate machine. If the recovery catalog is on the same machine, you should have:
Exported the user, who is the owner of the recovery catalog using the Oracle export command to an external flat file.
Included this external flat file in your file backup.
If required, the recovery catalog should be manually resynchronized using the Resync Catalog command.
Perform the following steps if the recovery catalog is on the same machine that you are rebuilding:
Create the recovery catalog database as it existed before the crash.
Create the user (who was the owner of the recovery catalog) with the same user privileges that existed for the user.
Import the user (which was exported to a flat file and was backed up as a part of the file system) using the Oracle import command.
Full System Recovery
A full system restore is the process of restoring all files (including the operating system) and Oracle database files on a client computer after a catastrophic event.
A full system recovery of a Documentum client includes the following phases:
PHASE I - Restoring Documentum Components
PHASE II - Restoring Database Components