Depending on the value and the nature of the data as well as on the availability of tools to reconcile differences within and between files, the linear read backup method may be acceptable. However, most database systems contain critical data and low-level database analysis and repair tools are often unavailable or limited. Oracle, for example, is not tolerant such inconsistencies resulting from hot backups and may not be repairable upon restore. The accepted method is to fall back to a known good version of the database and reapply logged transactions to produce a reconstructed version of the data up to the minute of a failure. Of course, if you don't have the ability to roll in logged transactions, your database is toast.

Open file managers
The second way to backup open files is through true open file management in the backup system. This means that the backup system will wait to start the backup of a given file until all write operations have completed. Once there are no writes pending, the backup will take a snapshot of the file system data for that file and begin backing up. Systems such as Veritas provide this type of advanced functionality.

In this case, as changes to the open file continue during the backup, the open file manager intercepts write calls to the file being backed up, and stores any changed records or sectors of the file in a temporary location. As the backup proceeds, any changed records are read from the temporary backup so that the backup system ultimately produces a copy of the open file exactly as it was when no writes were pending. This method ensures internal file consistency but not consistency across files in a set of related files. When using this type of backup technology, it is still necessary to run repair and maintenance procedures before putting a restored database back online. However, this method is adequate for most Domino databases.

More sophisticated agents are available from some backup vendors that are capable of ensuring integrity across files by applying the same open file management logic, at one time, to a complete set of files. In this case the backup software, in effect, takes a 'snapshot' of the file system, then logs changes as it proceeds to backup the file system, fetching data from a temporary cache for any files that are modified during the backup. On a busy server, however, this may require a brief shutdown of server processes to bring the file system to a known state before starting the backup (this functionality is available with some versions of the HP/UX operating system).

Clustering
A more sophisticated approach is to use clustering (e.g., NetWare SFT 3 or Domino clustering), then break the cluster and backup the secondary server (and when finished, reestablish the cluster). While this is a technically excellent solution that eliminates a variety of problems, it requires a cluster of servers -- which means at least one additional server machine with identical storage resources.

A refinement to this solution for Domino is to archive data to a cluster server maintaining a lesser amount of data on a primary server (this can be done through Domino replication and server-based agents). This makes it possible to bring the primary server back on line quickly since it will have smaller databases to process.