The basic problem with backing up Domino databases (and this is often the case with many server-based systems besides Domino) is backing up open files. This is an issue for every database system and for every major backup system. There are four basic options for backing up a database and they apply to most database systems as well as to Domino. Database administrators usually understand the problem better than Domino administrators, but with this article, you'll be completely clued in.

Here's an interesting hint for you cc:Mail types: Remember that cc:Mail is a database system much more than it is a data communications system.

The two simplest ways to handle open database files are to either (a) shutdown and backup or (b) to do a brute force read of the database without shutting down. A much better approach is to use a backup system that can handle open files. ArcServe, for example, is one product thatsupports backing up of various database systems. Most network backup systems support backup of open files or provide agents designed for compatibility with specific database systems.

How to backup open files
There are four basic ways to backup open files if you want everything to work successfully. They are linear read, the use of open file managers, the use of clustering, and our old favorite: shutdown and backup. There's also the network backup and restore approach, but that's not going to be a win on WANs. Read on for details.

Linear read
Most copy and backup utilities assume that a file that is already open shouldn't be copied or backed up because there's no way to guarantee the integrity of data within a single file or across files, within a set of related files. However, there are backup programs and utilities that allow "hot" copies of live database files. This is a most crude backup method and it brings with it two basic limitations.

It's technically possible to simply read open files linearly without regard to ongoing changes (this works if you open the files in sharing mode). The problem with this approach is that database files in the backup may be inconsistent both internally and with each other (in a set of related files) due to ongoing changes during the backup. In other words, the backup process can open and read a file that is being modified, but, as the backup proceeds through the file, later portions of the file may be inconsistent with earlier portions due to live modifications. Also, when a set of files contains references across files, the file set may be inconsistent across files when each file is read in turn -- while all of the files are being modified.