|
|
Because of operating system differences, VOB backup operations are handled differently on UNIX and Windows. All VOB backup operations begin with locking the VOB. This step is critical to the integrity of any VOB backup.
A VOB backup on UNIX can be summarized as follows:
Lock the VOB.
Back up the VOB storage directory.
Unlock the VOB.
By default, a VOB storage directory is wholly contained in a single directory tree, which resides in a single disk partition. If you use a file-oriented backup tool, you specify only the VOB storage directory to ensure a complete backup. If you use a disk-partition-oriented backup tool, you specify only the partition name. (Remote storage pools complicate the picture. See Backing Up a UNIX VOB with Remote Storage Pools.)
VOB storage on Windows is wholly contained in a single directory tree, which simplifies the backup process. A VOB backup on Windows can be summarized as follows:
If your backup software can be configured to capture files that are open for write access:
Lock the VOB
Back up the VOB storage directory.
Unlock the VOB.
If your backup software cannot process files that are open for write access, you must stop ClearCase on the VOB host, back up the VOB storage directory, restart ClearCase, and unlock the VOB.
WARNING: Many Windows backup utilities do not back up files that are open for writing. Because the VOB database files are typically in this state while ClearCase is running, even when the VOB is locked, your backup operation skips these files unless you stop ClearCase before performing the backup. Unless your backup software can capture files open for write access, you must stop ClearCase on the VOB host before performing a backup. To stop ClearCase, use the ClearCase program in Control Panel.
The standard backup procedure is to lock the VOB and back up the entire VOB-VOB database, plus VOB storage pools and various other files in the VOB storage directory. The VOB must remain locked for the duration of the backup. Keeping VOB database and storage pools synchronized on backup media is desirable; the standard backup procedure is recommended for all sites that can accept the duration of required locks. Note that ClearCase build programs are designed to cope with locked VOBs. They will "sleep" when they are unable to open an object in a locked VOB, and then retry as described on the clearmake reference page.
As illustrated in Figure 7, semi-live backup involves backing up the two major pieces of a VOB separately, as follows:
VOB database. Configure the VOB to have the vob_snapshot utility periodically lock the VOB and copy the VOB database to another location on disk (from which it can be backed up as part of the site's normal backup process).
VOB storage pools. Back up the VOB storage directory routinely, without locking the VOB. The backed up VOB storage directory may include a copy of the VOB database. However, because it is backed up while the VOB is unlocked, this database is useless and is discarded when the VOB is restored.
If your UNIX VOB servers have remote storage pools, you must back the pools up as well.
VOB lock time reduced. The VOB storage directory can be backed up unlocked. The vob_snapshot utility locks the VOB, copies the VOB database to another disk location, and unlocks the VOB.
More disk space is required. A second copy of the VOB database must be captured to disk. In addition, each of the VOB's source pool data containers, when replaced by a container with new version data, is retained for an additional 30 minutes to guarantee that source containers can be reconstructed when checkvob resynchronizes the VOB database and the storage pools at VOB restore time.
The VOB restore procedure is more complex. The VOB storage pools and the VOB database have different reference times. VOB database and storage pools must be resynchronized when you restore the VOB. In particular, DO and version data added or removed in the interval between the database snapshot and storage pool backup cause database or pool skew that must be resolved. The vob_restore utility runs the checkvob utility to do this work.
Some data may be lost at VOB restore time. If the restored pools are older than the restored VOB database, data missing from the pools is lost (as expected). If the restored pool backup is newer than the database, pool version data newer than the snapshot is not added to the restored database. See also vob_restore: Restoring with a Database Snapshot.
To enable database snapshots, run vob_snapshot_setup on a VOB. This command causes the ClearCase scheduler to run vob_snapshot periodically on the VOB (daily, by default). The vob_snapshot and vob_snapshot_setup reference pages explain these operations. Consult them if you choose to use semi-live backup.
The backup procedures that follow accommodate (but do not require) snapshot-enabled VOBs. However, their focus is the standard backup approach, which requires the VOB to be locked for long enough to back up the database and all the pools. The vob_restore procedure applies equally to VOBs with and without database snapshots.
NOTE: The commands used in the following sections do not require a ClearCase view context or mounted VOBs.
Deferred deletion is enabled by the vob_snapshot_setup program. It ensures that the source pool will contain all needed containers when a backup program archives an active VOB. When a container is replaced by new version data (for example, during a checkin), the new container is created and the client requests the vob_server to remove the old container. If deferred deletion is deactivated, the container is immediately removed. If deferred deletion is enabled, the old container is added to a list of pending deletions, and it is removed in 30 minutes. Keeping source data containers for 30 minutes increases disk space requirements. The increase can be substantial during any 30-minute interval of heavy VOB checkin activity.
On UNIX platforms, you can execute the kill -HUP command on the vob_server process to send deferred deletion statistics to the vob_server log (see also getlog and getlog -gr).
When checkvob examines source pools, it reports containers on the deferred deletion list.
The deferred deletion list is written every five minutes to the file delete_list.db in the VOB storage directory.
To determine the location of a VOB storage directory, use the ClearCase Administration Console or the cleartool lsvob command. If your backup program runs locally, it probably uses the VOB server access path. If your backup program runs over the network, it probably uses the Global path.
cleartool lsvob -long \vob_flex
Tag: \flex
Global path: \\ccsvr01\vobstore\vob_flex.vbs
.
.
Region: uno
.
.
VOB on host: ccsvr01
VOB server access path: c:\vobstore\vob_flex.vbs
Specify the appropriate pathname to your backup program.
NOTE: Some UNIX utilities that back up entire disk partitions require you to specify the disk partition where the VOB storage directory resides.
A backup represents a self-consistent snapshot of a VOB storage directory's contents only if the VOB is not modified while the backup program is working. That's why it is essential to lock the VOB before backing it up and unlock it after the backup completes.
WARNING: Regardless of your chosen backup strategy (see Choosing Between Standard and Semi-Live Backup), you must lock the VOB against all users. Use the ClearCase Administration Console, the UNIX clearvobadmin GUI, or the Windows Explorer shortcut menu to lock the VOB. If you use the cleartool lock command, do not use the -nusers option. The lock is mandatory. It is not sufficient to capture a VOB that happens to be idle. The lock does more than ensure that no one modifies the VOB. It also causes the VOB to flush a database checkpoint to disk before backup. A VOB lock applied with the -nusers option does not perform the required database checkpoint.
You must be a privileged user to lock or unlock a VOB. There are several GUIs that support VOB locking, as well as two cleartool commands.
You can lock or unlock a VOB on any UNIX or Windows host from the ClearCase Administration Console:
Navigate to the VOB storage node for the VOB. This is a subnode of the host node for the host where the VOB storage directory resides.
Click Action > Properties. In the Properties of VOB dialog box, click the Lock tab.
From a Windows host, you can lock or unlock a VOB using the Windows Explorer shortcut menu for the VOB. Click ClearCase > Properties of VOB and click the Lock tab.
On UNIX, you can use the VOB Admin Browser (clearvobadmin). Click VOB > Lock or VOB > Unlock. (The -nusers option has no analog in the VOB Admin Browser.)
On the command line, use cleartool lock and unlock:
cleartool lock vob:/vobs/flex
Locked versioned object base "/net/pluto/vobstore/flex.vbs".
<perform backup>
cleartool unlock vob:/vobs/flex
Unlocked versioned object base "/net/pluto/vobstore/flex.vbs".
If you use a file-oriented backup program, you may want to exclude some subdirectories within the VOB storage directory to save time. Use the guidelines in Table 8 to determine the relative importance of the various directories.
VOB Directory | Importance for Backup |
|---|---|
Top-level VOB storage directory | Required |
VOB database subdirectory | Required |
Source storage pools | Required |
Derived object storage pools | Important, but not required |
Cleartext storage pools | Optional |
Administrative directory | Important, but not required |
Backing up derived object storage pools is not required because, by definition, DOs can be rebuilt from sources. The importance of backing up these pools may change over time:
In the early stages of a project, when the source base is changing rapidly, the useful life of most derived objects is very short. Omitting DO storage pools from a backup regimen at this stage should not cause a problem.
When a project is relatively stable, a VOB's DO storage pools contain many often-reused objects. At this stage, a complete build of a software system may wink in virtually all DOs, rather than building them. Loss of a DO storage pool may increase the time required for such a complete system build by an order of magnitude.
Before choosing not to back up DO pools, make sure that you and your development staff can accept the time it may take to rebuild these DOs, which can be very long.
If you do not back up DO pools, include each pool's roots in the backup-the pool's root directory (d\ddft, for example) and pool_id file, but not its subdirectories. Doing so prevents pool root check failure at restore time (see also Pool Root Check Failure).
WARNING: A shared derived object has two parts: an object in the VOB database and a data container in a DO storage pool. Losing DO data containers (for example, by failing to back them up) throws the VOB's database out of sync with its DO storage pools. To resynchronize, you must delete all the empty DOs from the VOB database, using cleartool rmdo and/or checkvob. See also VOB and View Resynchronization.
Backing up cleartext storage pools is not important, because they are caches that enhance performance. Type managers re-create cleartext data containers as necessary.
If you do not back up cleartext pools, include each pool's roots in the backup-the pool's root directory (c\cdft, for example) and pool_id file, but not its subdirectories. Doing so prevents pool root check failure at restore time (see also Database or Storage Pool Inconsistencies) and possible cleartext construction errors in the restored VOB.
The admin directory contains data on how much disk space has been used by the VOB and its derived objects. The ClearCase scheduler runs periodic jobs that collect data on disk space use and store it in the admin directory. By default, the scheduler stores data for the previous 30 days. This historical data cannot be re-created. If the data is important to you, back up the admin directory.
Using a base-plus-incremental scheme to restore a VOB storage directory typically restores too much data. Depending on your particular VOB and disk, this data may fill up the disk.
ClearCase stores version data in delta format (for example, the container of a text_file element). Instead of modifying an existing data container when a new version of an element is checked in, ClearCase creates a new container at a different pathname within the source storage pool. (It then deletes the old container.)
An example demonstrates how this storage strategy works with an incremental backup scheme. Suppose that one or more new versions of a particular element are created each day for a week. Each day's incremental backup picks up a different source data container for that element. If a crash occurs on the VOB server host at the end of the week, restoring the VOB places all those source data containers in the source storage pool, even though only one of them (the most recent) corresponds to the current state of the VOB database. Also, checkvob reports large numbers of unreferenced data containers when it runs at VOB restore time. (See the checkvob reference page for details.)
Given this situation, we recommend that you perform only a few incremental backups on a VOB storage directory before the next full backup. This practice minimizes the extra data involved in a base-plus-incremental restoration of the VOB. Run checkvob to detect and clean up the extra debris containers.
|
|
Feedback on the documentation in this site? We welcome any comments!
Copyright © 2001 by Rational Software Corporation. All rights reserved. |
