Backing up a view

The contents of views, unlike that of VOBs, can usually be reconstructed easily. With the exception of changes to checked-out versions and other view-private files, the contents of any view can be recovered by re-creating the view. Regular backups of views can still be important, especially if users are not in the habit of checking in their work regularly.

About this task

Backing up a view is similar to backing up a VOB, but simpler:

Views do not have multiple storage pools. A dynamic view has a single private storage area, its .s subdirectory. Unless the view storage is on a host running Linux or the UNIX system, where it may be implemented as a symbolic link to a remote host, or on a NAS device, this directory must be local to the host where the view server runs. Element versions loaded into a snapshot or Web view reside in a single directory and its subdirectories (there is no .s directory).
Do not make partial backups of a view storage directory or snapshot view directory. All the data in these directories is important, especially modified checked-out files and other view-private files, which are not recorded in the VOB.

Attention: Any utility you use to back up a view storage directory must be able to back up files that are open for writing. View database files are typically held open for write while HCL VersionVault is running, even if the view is inactive or read-only. A backup that skips these files has limited value, if any. Unless your backup software is known to capture files open for write access (something many Windows® utilities cannot do), you must stop HCL VersionVault on the view host before performing a backup.

A snapshot or Web view may have a view storage directory that is in a different location, perhaps on a separate host, from the directory where the downloaded files are stored. (Web views almost always have this configuration.) You must back up both directories.

Procedure

Determine the location of the view storage directory.
Use the HCL VersionVault Administration Console or run lsview to display view storage information.:
cleartool lsview –long r5_integration
Tag: r5_integration Global path: /net/mars/viewstg/r5_integration.vws ... ... View on host: mars View server access path: /viewstg/r5_integration.vws ...
If your backup program runs over the network, you need the Global path. If your backup program runs locally, you need the View server access path
Make the view read-only to ensure integrity and consistency of the backup.
To keep the view inactive while it is being backed up, use the chview command to prevent users from updating the view database.
cleartool chview –readonly r5_integration
Properties: readonly
This command does not prevent changes to the view's config spec. To keep the config spec from being changed during backup, rename the view storage directory before backing it up, and then stop the view server with cleartool endview –server view-tag.
If the view is on a host running Linux or the UNIX system, determine whether it has remote storage.
Use the ls command:
cd /viewstg/r5_integration.vws ls –ld .s
... .s -> /net/ccsvr04/viewstore/r5_integration.stg
A symbolic link indicates remote private storage area.
Enter the backup commands.
For a dynamic view or for a snapshot view whose view storage directory is a subdirectory of the snapshot view directory, back up the entire view storage directory. Use the local path or the network path listed by lsview in Step 2. If you are backing up a snapshot or Web view and its view storage directory is not a subdirectory of the view directory, back up both the view directory and the view storage directory.
Note: When you back up and restore a snapshot view, use a utility that preserves the modification times and ownership of all files and directories in the view. If you do not, loaded files become hijacked.
If you made the view read-only in Step 2, make it writable.

cleartool chview –readwrite r5_integration
Properties: readwrite
If you renamed the view storage directory, rename it to its original name.