Restoring 

A successful backup is good to have; however, a successful restore is the key. Restoring a system from an online backup can present problems; therefore, restoring a system based on an online backup must be followed by verification tests.

What Can Be Restored?

The answer to this question lies in the type of backup implemented. Since there are no system-wide checks, data losses must be taken into account, especially when restoring databases.

Consider a situation where a database holding the archive database has to be restored after a crash. For databases, the database’s built-in point-in-time recovery and log recovery can be used. The mechanism allows an almost consistent recovery of the data close to the time of crash.

Databases usually store configuration data for some of the components as well. The applications that store their configuration data in the database would be safe. In addition, these same components store their configuration data on the local file system, so the files would have to be restored to the same point in time, to be consistent. This is not possible using file system backup, and inconsistencies have to be expected. In such situations, you have to weigh the losses.

The main issue for database recoveries in the future will be the restoration of other dynamic data not stored in a database like the LDAP directory information. That is, some components also hold dynamic configuration data, which should be restored as close as possible to the point in time of the crash. However, since that data does not change, frequent partial offline backup or online backup is sufficient to get a near consistent state.

Complete tests have not been done, and some of the issues are likely to change upon testing.