Lock the VOB.

Back up the VOB storage directory.

Back up some or all of the VOB's storage pools.

Unlock the VOB.

Unmount the VOB—The VOB must be unmounted on each client host. For example:

% cleartool umount /vobs/flex

Go to the VOB host—Log in, as the root user, to the host where the VOB storage directory resides:

% rlogin ccsvr01 -l root
Password: <enter root password>
#

Check disk space availability—Make sure there is enough free space in the VOB's disk partition to load the backup copy:

# cleartool space /vobstore/flex.vbs
  Use(Mb) %Use  Directory
  27.0     2%   VOB database /net/ccsvr01/vobstore/flex.vbs
  33.0     3%   cleartext pool /net/ccsvr01/vobstore/ 
                flex.vbs/c/cdft
   .
   .
--------  ----  ------------------------------------------
  312.9    28%  Subtotal 
  828.4    74%  Filesystem /net/ccsvr01/vobstore
                (capacity 1115.1 Mb)

If the available space is insufficient, delete the VOB storage directory, or use other means to make enough space available.

Shut down ClearCase on this host—This ensures that ClearCase processes associated with the VOB are terminated. For example:

# /etc/rc.atria stop

---

Note: The name of the ClearCase shutdown script varies from system to system. See the init_ccase manual page.

---

Move the original VOB aside—If it still exists, rename the VOB storage directory:

# mv /vobstore/flex.vbs /vobstore/flex.OLD

Restart ClearCase on this host—This reenables use of any other VOBs located there. For example:

# /etc/rc.atria start

Load the backup—Restore the VOB storage directory from the backup medium. For example:

# mkdir /vobstore/flex.vbs
# cd /vobstore/flex.vbs
# tar -xvp

---

Note: Each VOB storage area includes a directory named .identity, which stores files with special permissions: the setUID bit is set on file uid; the setGID bit is set on file gid. You must preserve these special permissions when you restore a VOB backup:

---

If the VOB has remote storage pools, restore the backups of these pools at this point. 

Reregister the VOB—This is necessary only if you restored the VOB to a new location. For example, if you restored the VOB to new location /vobst_aux/flex.vbs:

# cleartool unregister -vob /vobst_aux/flex.vbs
# cleartool register -vob /vobst_aux/flex.vbs
    (Yes, unregister followed by register)
# cleartool mktag -vob -replace -tag/vobs/flex/ \
  vobst_aux /flex.vbs

Mount the restored VOB on one host—If the VOB host is also a client host, activate it there. Otherwise, use some other ClearCase host:

# cleartool mount /vobs/flex

Unlock the restored VOB—The VOB should have been locked before it was backed up. (See “Ensuring a Consistent Backup”.)

# cleartool unlock -vob /vobstore/flex.vbs
Unlocked versioned object base "/vobstore/flex.vbs".

Mount the restored VOB on all hosts—The restored copy of the VOB is now ready to use. Have users remount the VOB on their workstations, using cleartool mount.

Determine the location of the view storage directory—Use the lsview command:

% cleartool lsview akp_vu
View on host: neptune
View server access path: /home/akp/views/akp.vws
        (use this information if your backup program works locally)
 .
 .
  Tag: akp_vu
    Global path: /net/neptune/home/akp/views/akp.vws
 .
 .
    Region: dvt
        (use this information if your backup program runs over the network)

Ensure self-consistency of the backup—A view cannot be locked with the lock command. To guarantee that a view is inactive when it is backed up:

Determine whether the view has remote storage—You can use a standard ls(1) command:

% cd /home/akp/views/akp.vws
% ls -ld .s
   ...  .s -> /net/ccsvr04/viewstore/akp.stg
    (symbolic link indicates remote private storage area)

Enter the backup command(s)—If the view's private storage area is local, then a single command can back up the entire view storage directory tree. Use the local address or the network-wide address listed by lsview in Step #1:

% cd /home/akp/views
% tar -cv akp.vws

If the view's private storage area is remote, you need to perform a second backup (typically, using a different backup tape):

% tar -cv /net/ccsvr04/viewstore/akp.stg

Reactivate the view—If you renamed the view storage directory in Step #2, restore it to its original name. Inform users that they may resume using the view, with setview and startview commands.

Go to the view host—Log in to the host where the view storage directory resides:

% rlogin neptune

Check disk space availability—Make sure there is enough free space in the view's disk partition to load the backup copy. If necessary, delete the view storage directory, or use other means to make enough space available.

Move the original view aside—If it still exists, rename or delete the view storage directory:

# mv /home/akp/views/akp.vws /home/akp/views/akp.vws.OLD

Load the backup—Restore the view storage directory from the backup medium. For example:

% cd /home/akp/views
% tar -xv

If the view's private storage area is remote, restore its backup, too.

Reregister the view—This is necessary only if you restored the view to a new location. For example, if you restored the view to new location /usr2/akp.vws:

# cleartool unregister -view /usr2/akp.vws
# cleartool register -view /usr2/akp.vws
    (Yes, unregister followed by register)
# cleartool mktag -view -replace -tag akp_vu /usr2/akp.vws

Reactivate the view—The restored copy of the view is now ready to use. Use a setview or startview command to start a view_server process. Inform the user(s) of the view that it is available again.