> Technical Notes

8.3.1

GSS Technical Note: Backing up cc:Mail

by Ron Herardian
©1998 Global System Services Corporation (GSS)

OVERVIEW

The problem with backing up cc:Mail databases is backing up open files. There are 4 basic options for backing up cc:Mail POs. Except for CCSAVE, this material applies to other database systems, e.g. Oracle, or Domino server. DBAs usually understand the problem better than cc:Mail administrators. Remember that cc:Mail is a database system much more than it is a data communications system.

The simplest ways to handle open database files are to either shut down and backup or, for cc:Mail, CCSAVE the entire PO to a server that will be backed up. A superior approach is to use a backup system that can handle open files. ArcServe, for example, supports backing up cc:Mail post offices, although there some limitations to this particular product. Other backup systems also support backup of open files generally or provide a number of agents specifically for particular database systems.

There are 4 basic ways to backup open files:

1. LINEAR READ/CCSAVE: The issue is that most copy and backup utilities assume that a file that is already open should not be copied or backed up because there is no way to guarantee its integrity.

Nonetheless, it is technically possible to simply read open files linearly without regard to ongoing changes (open the files in sharing mode). This is what CCSAVE does. The problem with this approach is that database files in the backup may be inconsistent both internally and with each other (in a matched set of files) due to ongoing changes during the backup.

Fortunately for cc:Mail administrators, cc:Mail is tolerant of minor inconsistencies and the cc:Mail database is repairable (CHKSTAT DIAGNOSTICS/M; DIAGNOSTICS/R in DB6; or CCRSTR /M plus RECLAIM in DB8). In the case of cc:Mail, in effect, any data after the start time of the backup may be destroyed. Like CCSAVE, ArcServe also uses the linear read method. Other database systems are less tolerant of such inconsistencies.

Other database systems, e.g., Oracle, are much less tolerant of such inconsistencies and may not be repairable in the same sense (although it is possible to fall back to a known good version of the database and reapply logged transactions to produce a 'backup' up to the minute of a system failure.

2. 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 matched file set such as a cc:Mail database. Using this technology it is still necessary to run repair and maintenance procedures on the PO before putting it online.

3. CLUSTERING: Another approach is to use clustering, e.g., NetWare SFT 3 (or Domino clustering in the case of Domino), then break the cluster and backup the secondary server (and when finished, reestablish the cluster. For cc:Mail this does not eliminate the need to run repair and maintenance procedures before bringing a cc:Mail PO backup online, unless of course the PO had been shut down ahead of time.

4. SHUT DOWN AND BACKUP: The final, and simplest, method is well known to cc:Mail DB6 administrators. In DB6 it was necessary to shut down the PO for routine maintenance. The same logic can of course be applied to backups, i.e., shut down (clear user and Router connections) and then run the backup. Obviously this applies to all database systems. The drawback is that this assumes the system can be completely shut down, and that it can be shut down for entire the length of time necessary to perform the backup.

 

About GSS

Global System Services Corporation (GSS) is the leading provider of consulting and professional services for large-scale and distributed infrastructure systems such as email and messaging, directory services, groupware, and wireless solutions. GSS customers include Fortune 500 companies, large services providers and telecom companies, government agencies, major messaging product vendors, and innovative technology startups.

GSS provides a complementary suite of services including strategic technology consultation and competitive vendor and product analysis, product and system architecture and design, system development deployment, customization, and testing, technical support, email migration, and other IT services. GSS has been directly responsible for some of the largest global systems and solutions and counts as customers many of the largest companies in the world.

From its offices in the Silicon Valley California, GSS delivers services and solutions to customers worldwide through a network of mobile consultants and qualified GSS Affiliates. With industry certified professionals on staff, GSS is a Qualified Lotus Business Partner, a Certified Microsoft Solution Provider (MCSP), a Principal Partner in the Sun Partner Advantage program and a member of the Sun Software Partner Council, as well as a member of key industry organizations.

Contact GSS

©1995-2005 by Global System Services Corporation (GSS). Portions of this material are copyright ©1995-1999 by Ron Herardian