|
|
Given a complete and consistent VOB storage backup, vob_restore can accommodate a variety of restore scenarios. You can use vob_restore with or without a VOB snapshot. Any valid VOB backup (as defined in section 9.2) will work. vob_restore handles all of the following subtasks:
Stops and restarts ClearCase
Updates the ClearCase LT VOB registry
Merges the VOB database snapshot and VOB storage directory
Copies the temporary storage directory to the target location
Runs checkvob to resynchronize the VOB database and storage pools
NOTE: You cannot use vob_restore to restore a VOB that is located on a Network Attached Storage device.
Before examining alternative restore scenarios, it is useful to summarize the restoration procedure. We recommend that you do not retrieve VOB storage from backup media until vob_restore prompts you to do so in Step #3.
Log on to the ClearCase LT server. Log on as a user with permission to stop and start ClearCase-typically the root user on UNIX or a local administrator on Windows.
Check available disk space. If you are not restoring the VOB to the same location, make sure that there is enough free space in the VOB's disk partition to load the backup copy into a temporary storage location. To do so, use the VOB storage node in the ClearCase Administration Console or the cleartool space command.
# cleartool space /vobstore/flex.vbs
Use(Mb) %Use Directory
27.0 2% VOB database /net/pluto/vobstore/flex.vbs
33.0 3% cleartext pool /net/pluto/vobstore/flex.vbs/c/cdft
.
.
----------------------------------------------------------------------
312.9 28% Subtotal
828.4 74% Filesystem /net/pluto/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.
Run vob_restore. Exit any current working view and run a command like this one:
vob_restore /flex (the VOB-tag is the only argument)
When prompted, supply the information required by vob_restore-target directory for VOB restoration, location of database snapshot (if any), and so on.
NOTE: On Windows, you must use UNC names (\\host\share\rest-of-path) for all path information you supply to vob_restore.
For more information on vob_restore operations, refer to these sections:
While the VOB is still locked, run some consistency checks. For example, create a new view with the default config spec, load it from the restored VOB, and verify that all versions of recently changed elements are present.
Unlock the restored VOB. vob_restore always leaves the VOB locked when it exits.
# cleartool unlock vob:/flex
Unlocked versioned object base "/vobstore/flex.vbs".
If necessary, resynchronize the VOB and views. See VOB and View Resynchronization.
The sample session presented here restores VOB \vob_src. To complete the recovery, checkvob is run to find and fix inconsistencies between the restored VOB database and the restored VOB storage pools.
Additional details about this scenario:
The VOB is being restored to its current location (\\io\vobstore\vob_src.vbs). This is the in-place scenario, which is the most common.
The data currently in the VOB is invalid, so there is no need to maintain read-only access to the VOB during the restore operation.
A database snapshot for this VOB, \\io\e\vob_snaps\src, is used.
The administrator is logged on as Administrator on the VOB host, io.
As is recommended, the restored data is not retrieved from backup media before running vob_restore.
To start the process, run the vob_restore command.
ccase-home-dir\etc\vob_restore \vob_src
This utility helps recover a damaged VOB or replica from backup. It will first
prompt you for the information it needs to perform its job. Then, it will
describe the 'restore scenario' it believes you have in mind, based on the
information you have supplied. You will then be asked various questions as the
script proceeds through the restoration process. Some prompts ask for more
information, others simply request verification for the next step. Each prompt
includes a list of valid responses and the default, where appropriate.
At many prompts, a possible response is the string 'quit'. If you choose to
quit at one of these prompts, a '-restart <pathname>' string will be displayed
as the script exits. Save this output and supply it as a command line option
to vob_restore (before the VOB-tag argument) when you want to resume the
interrupted restore operation on the same VOB or replica. If you choose to
quit at any point, DO NOT in any way alter the state of the VOB or replica
before restarting the restore operation.
Valid responses are (quit,<RETURN> to continue)
There is no default response: <RETURN>
vob_restore prompts for a target destination for the reassembled VOB storage directory.
Specify the full path for target storage directory to contain the VOB or
VOB replica. The default is the currently registered local path:
\\io\vobstore\vob_src.vbs
Type a full pathname, "help", or "quit": <RETURN>
Pressing RETURN restores the VOB to its current, registered location. Supplying a different pathname moves the VOB. The pathname supplied here must be on the local host.
Next, vob_restore prompts for the location of the storage directory backup, which may or may not be retrieved at this point.
Please specify the full path for the VOB or replica storage that was
either restored from backup media or will be during this restoration
process.
Valid responses are (Full path, quit or help)
There is no default response: \\io\vobstore\vob_src.vbs
This response indicates that the retrieved backup storage directory is already in, or will be loaded into (recommended), the currently registered storage location, overwriting the existing storage directory.
vob_restore prompts for the location of the VOB database snapshot, if any. If you are not using a semi-live backup strategy for this VOB, press RETURN.
If a merge of a snapped database with this retrieved backup data is
desired, please specify the full pathname of the snapped database.
(Full path, help, quit): \\io\e\vob_snaps\src
vob_restore prompts you to specify whether the backup has been loaded.
Is the data currently contained in the directory
\\io\vobstore\vob_src.vbs
the data restored from backup media?
Valid responses are (yes,no,help)
The default is no: no<RETURN>
This response confirms that the VOB storage directory is not yet retrieved from backup media.
At this point, vob_restore has the information it needs to determine the restore scenario. See also vob_restore: Restoration Scenarios.
The information you supplied, and the state of the registry at that time, resulted in the following initial restoration parameters. If this invocation is a restart, the current registry state may be different.
o The vob is currently registered.
o The restored vob will be placed in its previously registered location
\\io\vobstore\vob_src.vbs
on its previously registered host
io
o The restoration will be done in place.
o The database will be copied from the snapshot directory
\\io\e\vob_snaps\src
If you wish, you may quit for now and restart the script at a later time.
Do you want to proceed?
Valid responses are (yes,quit)
The default is yes: yes<RETURN>
If the VOB is registered in a registry that is served by a different registry host, you must go to a host served by that registry server and unregister the VOB with cleartool unregister. You can also use the ClearCase Administration Console.
NOTE: ClearCase LT does not support multiple registries. Press RETURN when prompted for a response.
The vob must now be made unavailable. This script will unregister the vob
from this hosts's registry. If it is registered in any other registries
you must unregister it from those registries before continuing. Do not
unregister it from this host's registry. You may quit for now to perform
this operation. Press <RETURN> to continue only when this host's registry
is the only registry the replica remains registered in.
Valid responses are (quit,<RETURN> to continue)
There is no default response: <RETURN>
The full current registry settings will be saved in the file
\\io\vobstore\register_save_io
Press return to continue.
Valid responses are (quit,<RETURN> to continue)
There is no default response: <RETURN>
Removing vob tag \vob_src...rmtag complete
Unregistering \\io\vobstore\vob_src.vbs...unregister complete
At this point, vob_restore is ready to shut down ClearCase.
Is it all right to shutdown Clearcase on this host?
Valid responses are (yes,quit,help)
The default is yes: yes<RETURN>
Shutting down Clearcase...Clearcase shutdown complete
You must now move or remove the old, damaged storage directory before vob_restore restarts ClearCase:
You must either move or remove the previous storage directory
\\io\vobstore\vob_src.vbs
now. Press <RETURN> to continue only when it has been completed.
Valid responses are (quit,<RETURN> to continue)
There is no default response: <RETURN>
Starting Clearcase...Clearcase start complete
Now, load the backup into the directory supplied at Storage Directory Prompt.
The restored data must now be retrieved from backup media and placed in
\\io\vobstore\vob_src.vbs
You may quit to restore the data now or press <RETURN> to continue when
the restoration has been completed.
Valid responses are (quit,<RETURN> to continue)
There is no default response: <RETURN>
If the VOB is configured for database snapshots, but not for db_check operations at snapshot time (see vob_snapshot_setup), run db_check now. Note that db_check is forced in either of these situations:
There is no snapshot, and the VOB was unlocked at backup time.
The snapshot was taken when the VOB was unlocked.
A dbcheck was not done during the snapshot. Do you wish to do one now?
Valid responses are (yes,no,quit)
The default is no: yes<RETURN>
Performing data base check. This may take some time...checked clean
ClearCase LT does not support remote storage pools. Press RETURN at the next prompt.
If there are any remote pools that should be restored now is the time to
restore them. You may quit for now to perform this operation or press
<RETURN> to continue.
Valid responses are (quit,<RETURN> to continue)
There is no default response: <RETURN>
Confirm that you have supplied a VOB database snapshot. vob_restore merges it with the retrieved VOB storage backup, overwriting any VOB database retrieved with the storage directory:
The restored storage area contains a copy of a directory being restored
from the snapshot area.
\\io\vobstore\vob_src.vbs\db
Is it ok to remove this copy?
Valid responses are (yes,quit,help)
The default is yes: yes<RETURN>
Making tag for storage \\io\vobstore\vob_src.vbs\db...mktag complete
Registering \\io\vobstore\vob_src.vbs\db...register complete
If you are testing backup or restore procedures and not restoring a broken VOB, let vob_restore temporarily disable VOB database snapshot activity on the VOB:
The VOB database snapshot utility is enabled for this VOB/replica. If you
are restoring this VOB/replica because it was broken, this is probably ok.
However, if you are merely testing your backups, and this replica is
actually active in some other region, this may cause a problem. If the
snap path
\\io\e\vob_snaps\src
is visible on this host, the test backup VOB's database will be snapped,
overwriting the real snap for the VOB/replica . This can be prevented by
removing the snap parameter attribute for this VOB/replica at this
time.You should answer yes to this prompt if this recovery is a test of
backups otherwise answer no.
Do you want this script to remove the snap parameter attribute ?
Valid responses are (yes,no)
There is no default response: no<RETURN>
If you supplied a database snapshot when prompted for one, you must run checkvob to resynchronize the VOB database and storage pools. We recommend that you run checkvob whenever you restore a VOB, because it may expose problems in the restored VOB.
NOTE: vob_restore replaces the VOB lock with one that permits access by the checkvob process, and relocks the VOB against all users when checkvob exits. Make sure that the user ID under which vob_restore or checkvob runs does not modify the VOB in any way while checkvob is running.
Do you want to have checkvob examine the vob for possible problems?
Valid responses are (yes,quit,help)
The default is yes: yes<RETURN>
Would you like to have checkvob run in 'check only' mode?
Valid responses are (yes,no,quit,help)
The default is yes: yes<RETURN>
Source pools?
Valid responses are (yes,no)
The default is yes: yes<RETURN>
Derived object pools?
Valid responses are (yes,no)
The default is yes: yes<RETURN>
Cleartext pools?
Valid responses are (yes,no)
The default is yes: yes<RETURN>
Checkvob expects to be run in a view context. If you are not currently in
a view, checkvob will accept a view tag argument. Supply one now if you
are not in a view.
view_tag: adm_view<RETURN>
Checkvob will now be run in 'check only' mode. This may take a while on
large vobs. Checkvob will generate logs in the directory
checkvob_sum.03-Oct-96.14.21.06
It will emit rather verbose information to standard output as it runs. All
of this information is also saved in the log directory for later viewing.
You may be prompted for information as well. You may quit for now or press
<RETURN> to continue.
Valid responses are (quit,<RETURN> to continue)
There is no default response: <RETURN>
At this point, checkvob takes control temporarily from vob_restore:
The session's log directory is 'checkvob_sum.03-Oct-96.14.21.06'.
=================================================================
Starting "source pool" processing at 03-Sep-96.14:21:59
... lots of checkvob output ...
The VOB's derived pools are healthy.
Poolkind transcript log:
checkvob_sum.03-Oct-96.14.21.06\poolkind_derived\transcript
=================================================================
checkvob's check-only pass is complete. Control has returned to vob_restore, which summarizes the results and prompts you run checkvob in fix mode to repair any problems:
1 source containers are either missing or corrupt
0 derived object containers are either missing or corrupt
0 source containers are misprotected
0 derived object containers are misprotected
Cleartext containers were not checked.
More details may be found in the log files in the above directory
Do you want to have checkvob run in repair mode?
Valid responses are (yes,no,quit)
The default is yes: yes<RETURN>
Source pools?
Valid responses are (yes,no)
The default is yes: yes<RETURN>
Checkvob will now be run in fix mode. This may take a while on
large vobs. Checkvob will generate logs in the directory
checkvob_fix.03-Oct-96.14.22.02
It will also emit rather verbose information to standard output as it
runs. All of this information is also saved in the log directory for
later viewing. You may be prompted for information as well.
Do you want to proceed?
Valid responses are (yes,quit)
The default is yes: yes<RETURN>
While running checkvob the the vob will be locked for all but user
Administrator (or other account used to invoke vob_restore)
The vob will be open to possible modifications by anyone running as
this user. This MUST NOT be allowed to happen. If you need to make
arrangements to ensure that no one with this identity will attempt to
modify this vob before proceeding you may quit for now. Press <RETURN>
if you are satisfied that no such modifications will occur.
Valid responses are (quit,<RETURN> to continue)
There is no default response: <RETURN>
Once again, checkvob is back in control, running in fix mode.
The session's log directory is 'checkvob_fix.03-Oct-96.14.22.02'.
If any version data is missing from source pool data containers,
fix processing involves irreversibly updating the VOB database
with the equivalent of 'cleartool rmver -data' operations.
By default, checkvob does not allow this class of fix processing.
Do you want to override the default and fix elements with
missing version data? [no] yes<RETURN>
You must specify a time limit for acceptable missing data.
Refer to the reference manual for more information.
Allow missing version data created since: [date-time, <CR>] <RETURN>
Allowing missing version data created since 02-Oct-96.00:00:00.
WARNING: You are allowing fix processing for missing version data.
If the allowable missing version data limit encompasses
more versions than you expected, you will have to restore
this VOB from backup media to undo the effects of this fix
processing.
Do you want to continue with force mode processing? [no] yes<RETURN>
=================================================================
Starting "source pool" processing at 03-Oct-96.14:26:21
... lots of checkvob output ...
The VOB's source pools are healthy.
Poolkind transcript log:
checkvob_fix.03-Oct-96.14.22.02\poolkind_source\transcript
=================================================================
0 source containers remain either missing or corrupt
0 source containers remain misprotected
0 source elements experienced loss of version data
0 source versions were lost
0 derived object containers remain either missing or corrupt
0 derived object containers remain misprotected
0 rmdo operations were done
0 derived objects were lost
Cleartext containers were not checked.
Check has either detected no problems or has repaired what it did detect.
This is a non replicated vob so no further action should be required.
VOB restoration is now complete. Go to Step #6 here.
vob_restore can accommodate a number of restoration scenarios:
In place: restore a VOB without changing its location
VOB is active: restore a VOB that has read-only access
Move VOB on same host
Move VOB to new host
VOB is unregistered
All have two variants: with and without a VOB snapshot.
The previous example restored a VOB in place, loading the backed up VOB storage directly into the currently registered location. The examples also merged in a VOB database snapshot from its on-disk location. This scenario can be called "in place, with snapshot." There are other possibilities.
When you run vob_restore, it prompts for three critical pieces of information:
What is the target? That is, where will the restored VOB storage ultimately reside?
Where are you going to put the VOB storage directory backup (or, where did you put it)?
If you want to merge in a VOB database snapshot, where is it?
vob_restore also derives the VOB's currently registered storage location from the VOB-tag argument supplied on the command line.
As shown in Figure 10, vob_restore's task is to merge the backup and the snapshot (if there is one) at the target, and to correctly re-register the target, which may be at a location other than the VOB's currently registered location.
vob_restore uses your input to describe the restore scenario. For example, Figure 11 shows the scenario from the sample restore session in the previous section.
Figure 11 Restore Scenario Summarized by Output from vob_restore
o The vob is currently registered.
o The restored vob will be placed in its previously registered location
\\io\vobstore\vob_src.vbs
on its previously registered host
io
o The restoration will be done in place.
o The database will be copied from the snapshot directory
\\io\e\vob_snaps\src
This output can vary, depending on the information you supply at vob_restore prompts.
At restore time, remember these rules and guidelines:
Target must be on the ClearCase LT server.
Snapshot can reside on a remote host.
Whenever possible, the backup and target pathnames ought to be the same. That is, always try to load the backup into its final destination. This practice avoids a time-consuming copy operation. (In fact, vob_restore copies the backup to the target only if a move operation is impossible.) This avoidance is possible for all scenarios but vob_restore: VOB Is Active.
If the backup and target pathnames are different, try to keep them on the same host to avoid possible problems with permissions, network load, and so on.
If you retrieve the backup before running an in-place restoration, you must unregister the VOB, stop ClearCase, load the backup, and restart ClearCase.
Now let's look at the main scenarios, one at a time.
This scenario is illustrated in Figure 12
Formula. backup = target = currently-registered-location
Advice. Use this scenario whenever practical.
Figure 12 vob_restore: In Place
In this scenario, the VOB is still active for read-only access, so the backup must be loaded into a temporary storage location. (See Figure 13.)
Formula. (backup different from target) and (target = currently-registered-location)
Advice. Do not combine this scenario with a move VOB scenario. Keep the VOB at its currently registered location.
Figure 13 vob_restore: VOB Is Active
In this scenario, the backup is restored to a different location on the same host. (See Figure 14.)
Formula. target different from currently-registered-location
Advice. Load the backup directly into the target destination.
Figure 14 vob_restore: Move VOB on Same Host
When moving a VOB as part of a vob_restore operation, the target host must have the same architecture (hardware and operating system). (See Figure 15.)
NOTE: Because a ClearCase LT client can only access VOBs on a single ClearCase LT server, moving a VOB off a ClearCase LT server makes it inaccessible to clients of that server. In a ClearCase LT environment, server-to-server VOB moves are generally undertaken only in conjunction with a planned change in ClearCase LT server host hardware. In this scenario, you must run vob_restore on the target host.
Formula. target different from currently-registered-location
Advice. Load the backup directly into the target destination.
Figure 15 vob_restore: Move VOB to New Host
Formula. Same as in place, but no currently-registered-location
Advice. Load the backup directly into the target destination.
Any restore scenario that includes a VOB database snapshot introduces an additional complication: the VOB database and VOB storage pools have different reference times; that is, one is newer than the other. This skew must be resolved in the restored VOB. Run checkvob to resolve it. Figure 16 illustrates the problem and summarizes what checkvob does when the a VOB database is newer or older than the VOB's storage pools (the backup) at restore time.
Figure 16 VOB Database or Storage Pool Skew Associated with VOB Snapshots
NOTE: Derived objects (DOs) are not supported by ClearCase LT. ClearCase LT VOBs include DO pools, but the pools never contain DOs. Both vob_restore and checkvob include code to deal with DOs and DO pools. This code may produce log output that refers to DOs, but you can ignore such output in a ClearCase LT environment.
VOB snapshots have minimal impact on the your work at restore time. When prompted by vob_restore, you need only supply the correct snapshot directory. However, the checkvob portion of a vob_restore operation is critical. You must be prepared to respond intelligently to checkvob prompts and to understand the implications of any errors reported in its output. Typically, checkvob finds and repairs numerous small problems, but it reports version data loss for the interval between storage pool and VOB database reference times.
For more information, see the checkvob reference page and Chapter 13, Using checkvob.
|
|
Feedback on the documentation in this site? We welcome any comments!
Copyright © 2001 by Rational Software Corporation. All rights reserved. |
