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 DevOps Code ClearCase® 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 DevOps Code ClearCase 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.