This chapter contains procedures to follow to prepare for and recover from a major disk crash. Four different types of disk crash situations are covered:
The primary disk, which contains the operating system and NetWorker binaries, is damaged. This can apply to a client system or a NetWorker server.
A secondary disk, which contains other filesystems, is damaged. This can apply to a client system or a NetWorker server.
The NetWorker server's disk, which contains the online indexes (the /nsr filesystem), is damaged. You have to recover the indexes before using NetWorker to recover any filesystems.
Your NetWorker fileserver was destroyed. You must recover everything to a new NetWorker server.
If a primary disk suffers a head crash, you may need to replace the disk, boot from miniroot, format and partition the disk, reinstall the operating system and NetWorker binaries, and then recover the affected filesystems. In this case, you must consult the system administration manuals you used to set up your fileserver for the first time before using NetWorker to recover the data on the disk.
If a secondary disk suffers a head crash, its recovery procedure is simpler, since you do not have to reinstall the operating system and NetWorker binaries.
This appendix gives a shortcut recovery procedure and explains
preparing for a crash
using recover or save set recover
recovering a secondary disk
recovering a primary disk on a client
recovering /nsr on a NetWorker server
recovering to a new server
disaster recovery with jukeboxes
 | Note: It is impossible to provide step-by-step instructions on how to recover your system from a disaster, because every site and every disaster is unique. The discussions in this chapter are designed to give you general principles on how to recover a primary or secondary disk, and to help you understand the procedure. They are meant to be examples only, not instructions. |
The following steps summarize what you need to do if a primary or secondary disk is damaged, destroying the filesystems of a NetWorker server or client:
If the operating system is lost, reload and boot the system using the same hostname and disk partitioning.
Replace the damaged disk, if necessary. Format it, partition it, and make new filesystems. Mount the filesystems in the same locations and with the same names as before.
If the NetWorker software was lost, reinstall it from the NetWorker software distribution CD.
If the /nsr filesystem is destroyed on a NetWorker server, use recoverindex to recover the NetWorker server's indexes.
Recover the lost filesystems by using the save set recover feature or the normal recover process. Recover the client indexes using the normal recover process.
The ultimate disaster for a system is to lose all the files on its disk. Most sites back up their fileservers daily as insurance against this event. If a system's primary disk suffers a crash, you can rebuild its filesystems with NetWorker, after you reinstall the operating system (if necessary).
If the NetWorker server's filesystem or disk that contains /nsr is destroyed, the recovery procedure involves an extra step: you must recover the server's online indexes as well as the server's filesystems. The server's /nsr filesystem contains one index for each client, including an index for the server as a client of itself.
If your NetWorker server was destroyed (in a fire, for example), you need to replace it with another system. You may do this as long as you perform the following procedures:
Give the replacement server the same hostname as the original NetWorker server.
Get new NetLS licenses for the new system. The licenses for the old system will not work.
Reinstall NetWorker using the same directory locations for the online indexes as in the original installation.
 | Tip: Once you understand the procedure for a disaster recovery, make sure you have carefully thought out a disaster recovery plan for your site. If possible, you should test your ability to recover from a disaster at your site. |
If you have set up your network and enabled NetWorker to execute automatic, network-wide backups, you are well prepared for a disaster. Every time NetWorker backs up a group of clients, it also backs up all the online indexes for those clients, including the indexes for the server itself.
The media database, NetWorker configuration files, and part of the server's index is saved to a special save set named bootstrap. The save set identification numbers (ssid) for all recent bootstraps are sent to a default printer, providing a hard copy for your records.
Take two additional precautionary steps to help you recover from a future crash:
Keep a file containing hard copies of the daily bootstrap records. Place these sheets of paper in a three-ring binder or a file folder.
Make a hard-copy record of the disks, partition sizes, and mount points for the server and any clients that have a local hard disk. This information makes the recovery procedure much smoother for you in the future.
NetWorker sends a record of the index backup to your default printer, so you have a piece of paper with the date, name of the backup media, and save set ID number for bootstrap. If you ever need to recover the server's online indexes, you need the information on this piece of paper. Save this information in a safe place.
The information sent to the printer looks similar to this:
March 11 16:42 1994 NetWorker boostrap information Page 1 date time level ssid file record volume 3/10/94 2:46:02 9 1148868949 56 0 bitbucket.002 3/11/94 2:53:34 9 1148868985 77 0 bitbucket.003 |
NetWorker prints all the bootstrap save sets for the past month. The bootstrap save set may span more than one backup volume. The file and record numbers are used to find the associated save set quickly.
You can also manually back up the NetWorker server's indexes by using the saveindex command. Using this command also sends the bootstrap information to a printer. For example:
# /usr/etc/saveindex -c server_name March 7 03:30 1994 NetWorker bootstrap information Page 1 date time level ssid file record volume 3/01/94 7:44:38 full 1148869706 55 0 bitbucket.008 3/02/94 6:12:09 9 1148869754 48 0 bitbucket.008 3/03/94 6:14:23 9 1148869808 63 0 bitbucket.009 3/04/94 6:29:58 9 1148869870 88 0 bitbucket.009 |
To use the saveindex command, you must be root on the NetWorker server.
Use the disk information commands to find out how the NetWorker server's disks are partitioned and mounted, and make a hard copy of this information. Do the same for any NetWorker clients that have local hard disks. The information you need is
-
Note: For XLV, there is no /etc/lvtab. To list all XLV volumes on the system and their contents, do one of these actions: run xlv_make and enter the show command to display the current set of XLV objects on your system
or
run xlv_assemble -n which will display the same information
Because of a bug in XLV, you'll see the following output from a prtvtoc command when you are running on an XLV root volume:
xfs-mp9 1# prtvtoc Printing label for root disk prtvtoc: /dev/rdsk/xlv_root: Can't get volume header xfs-mp9 2#
For example, the df information looks similar to this:
mars% df Filesystem Type blocks use avail %use Mounted on /dev/root xfs 67800 42135 25665 62% / /dev/dsk/xlv/usr xfs 6732736 5992080 740656 89% /usr /dev/dsk/xlv/f xfs 86673816 58296424 28377392 67% /f /dev/dsk/xlv/e xfs 31405776 27886176 3519600 89% /e /dev/dsk/xlv/d xfs 3907872 2477400 1430472 63% /d /dev/dsk/xlv/b xfs 31316992 27869408 3447584 89% /b |
The prtvtoc(1M) command gives you information about how each disk is partitioned. It takes device volume header names as arguments; you can construct these from the output of hinv(1M). For example:
mars% hinv -c disk Integral SCSI controller 131: Version WD33C95A Integral SCSI controller 130: Version WD33C95A Integral SCSI controller 4: Version WD33C95A Integral SCSI controller 3: Version WD33C95A Integral SCSI controller 2: Version WD33C95A Disk drive: unit 4 on SCSI controller 2 Disk drive: unit 3 on SCSI controller 2 Disk drive: unit 2 on SCSI controller 2 Disk drive: unit 1 on SCSI controller 2 Integral SCSI controller 1: Version WD33C95A Disk drive: unit 4 on SCSI controller 1 Disk drive: unit 3 on SCSI controller 1 Disk drive: unit 2 on SCSI controller 1 Disk drive: unit 1 on SCSI controller 1 Integral SCSI controller 0: Version WD33C95A |
One device volume header name is constructed from each of the disk drive lines. The device name for the first disk drive line in the example is /dev/rdsk/dks2d4vh.
Give the prtvtoc command with the device names as arguments (the /dev/rdsk/ prefix can be omitted). For the example above, the command is:
mars# prtvtoc dks2d4vh dks2d3vh dks2d2vh dks2d1vh \ dks1d4vh dks1d3vh dks1d2vh dks1d1vh * /dev/rdsk/dks2d4vh (bootfile “/unix”) * 512 bytes/sector * 94 sectors/track * 15 tracks/cylinder * 34 spare blocks/cylinder * 2858 cylinders * 3 cylinders occupied by header * 2855 accessible cylinders * * No space unallocated to partitions Partition Type Fs Start: sec (cyl) Size: sec (cyl) Mount Directory 0 efs 4128 ( 3) 49152 ( 35.7) 1 raw 55040 ( 40) 524288 ( 381.0) 6 efs 579328 ( 421.0) 3353280 (2437.0) 7 lvol 4128 ( 3) 3928480 (2855) 8 volhdr 0 ( 0) 4128 ( 3) 10 volume 0 ( 0) 3932608 (2858) ... |
The file /etc/lvtab describes the logical volumes used for LV. This file, along with the information from the df command, tells how the disk partitions are combined and used and how to map names onto partitions. /etc/lvtab looks similar to this:
mars% cat /etc/lvtab lv0:/b volume:stripes=4:devs=/dev/dsk/dks1d2s7,/dev/dsk/dks1d5s7, \ /dev/dsk/dks2d1s7, /dev/dsk/dks2d2s7 lv4:/a volume:stripes=4:devs=/dev/dsk/dks1d3s7,/dev/dsk/dks1d4s7, \ /dev/dsk/dks2d3s7, /dev/dsk/dks2d4s7 |
Print and file this information in case you ever have to recover from a disk crash. If a disk is destroyed in a head crash, you can rebuild it exactly as it was and recover the filesystems to their original state using the hard copy information from the disk information commands.
You can use the save set recover feature or the normal recovery procedure to recover filesystems after disk failure. This section describes the advantages of each method.
During backup, NetWorker multiplexes different filesystems simultaneously to the backup media. By recovering multiple filesystems at the same time, NetWorker can demultiplex the filesystem save sets from the same backup volume in parallel, thus reading each backup volume only once. Thus you should try to recover multiple filesystems at the same time if it is practical for you to do so. You can do this by marking different save set points (using the save set recover feature) or different mount points (using the normal recover procedure).
| Note: With release 4.1.1, the NetWorker server can recover several save sets from the same backup volume in parallel, eliminating the need to read the same backup volume several times during a recovery. |
The big advantage to using the save set recover feature is that it takes less time to browse and mark filesystems. With normal recovery, an entry for each individual file is accessed in the NetWorker file index to reconstruct an accurate view of the filesystem. It takes time to “pick” the most recent versions of files from the tape. With save set recover, individual file browsing is bypassed and entire save sets are recovered in one step.
The two ways to use the save set recover feature are as follows:
Run the nwadmin program and choose “Recover” from the Save Set menu to open the Save Set Recover window.
If you are not using the X window system, run recover with the -S ssid option from the system prompt. Refer to the mminfo(8) reference page for instructions on how to find the save set(s) you want to recover. Refer to the recover(8) reference page for detailed instructions on using the recover -S command.
In the Save Set Recover window, note the backup levels of the save sets you are marking for a recovery. For each save set you wish to recover, you need the last full backup followed by the most recent level backups of the save set in order to bring the system back to the state it was in before the system crash.
Remember, a level 0 backup is a full backup, and other levels after a full are represented by ascending numbers, or by the letter i for incremental saves. In other words, a level 3 backs up more data than a level 5. Figure B-1 diagrams several backups over time.
In this diagram, the bars represent the level backups since the last full backup. The arrows point to the save sets you would need in order to recover your filesystems from the disk crash. For example, suppose you wish to recover the save set /nsr/index/xfs4.engr.sgi.com, shown in the Recover Save Set window shown in Figure B-2.
When you select /nsr/index/xfs4.engr.sgi.com in the Save Set scrolling list, the Instances scrolling list displays its backup history. You must mark (for a recovery) the most recent full backup of /nsr/index/xfs4.engr.sgi.com and the most recent level 9 in order to restore /nsr/index/xfs4.engr.sgi.com to the state it was in before the system crash. In other words, you must mark the appropriate save set levels for each filesystem you are recovering.
Normally during disaster recovery, you force the recover program to overwrite existing files. When you use save set recover, marking the save set level is even more important, because the same file might be recovered multiple times with each successive version coming from a later save set. And since each file in each save set is recovered with save set recover, files or directories that have been previously deleted or renamed between backups (with the mv command) are still recovered and therefore must be manually deleted. You might even run out of space during the recovery if there are too many instances of previously deleted files or directories recovered by save set recover.
The save set recover feature reads each save set in its entirety during recovery. If you have to recover many save sets, you might be better off using the normal recover instead of save set recover. If, however, you only need the last full backup of a save set, save set recover should be your method of choice.
By contrast, if you decide to use the Recover command from the nwrecover program, you recover your filesystems exactly as they were as of the last backup before the crash, and NetWorker reads the minimum amount of tape to recover the files. The disadvantages are as follows:
It takes more time to browse and mark files for recovery, since NetWorker needs to find an entry for each file in the index to add all the files in one filesystem.
You might run out of swap space if you add too many filesystems at once to your list of data to recover.
In summary, we recommend the save set recover feature for faster disaster recovery if
you can determine the correct save sets to recover
there are only a few save sets to recover for each filesystem
you are not recovering the NetWorker indexes
recovering extra files is acceptable (not an issue if you are recovering from full backups only)
Use the normal recovery procedure if
you cannot determine which save sets to recover
you must recover files from many backups to restore the filesystem to an acceptable level
you are recovering the NetWorker indexes
recovering extra files is not acceptable, and you are recovering from several backups, not just a full one
This section gives you an outline of how to recover a secondary disk using NetWorker. The outline applies to either a NetWorker server or a client.
The example in Figure B-3 assumes the primary disk is still operational, so the system has an operating system and can run NetWorker. However, a secondary disk is lost due to a head crash.
If the disk is damaged, replace it with a new disk of the same type. Try to get a disk of the exact same size as the old one. You need a disk large enough to hold all the filesystems to be recovered.
Install the replacement disk. Make sure that IRIX recognizes the new disk.
Label the new disk, partition it, and make filesystems. This procedure is outlined in the section “Repartitioning a Hard Disk” in Chapter 8 of the IRIX Advanced Site and Server Administration Guide. Use the hard copy of the disk information to remember how large each partition was. (See the section “Filing the Disk Information” in this appendix.)
Recreate logical volumes on this disk, if used. Use the procedure in the section “Logical Volumes and Disk Striping” in Chapter 8 of the IRIX Advanced Site and Server Administration Guide and again use the hard copy of the disk information.
Invoke the recover command:
venus# /usr/etc/recover
Select one filesystem to recover. You should recover one filesystem at a time, because NetWorker adds all the files in one filesystem but stops at a mount point, and you may run out of swap space if you add too many filesystems at once to your list of data to recover.
Add the directories and files under the filesystem to be recovered:
NetWorker> add /home
-
NetWorker> recover /home is being recovered into its original location Requesting 33023 files, this may take a while...
Repeat steps 5 through 7, adding and recovering one filesystem at a time. Remember to open a main window on your screen (or use the nsrwatch command) so you can monitor NetWorker requests for backup media during the recovery.
Exit the recover program:
NetWorker> quit
In the example in Figure B-4, a disk with the operating system or the NetWorker binaries is damaged.
After replacing the damaged disk, format it and reinstall the operating system, using the original software distribution. Next, reinstall NetWorker from the original software distribution, reinstall the NetWorker licenses, and activate the licences as described in the section “Installing and Enabling NetWorker Software on Servers” in Chapter 2.
With the operating system and NetWorker back in place, you are ready to start recovering the remainder of the data lost from the disk.
Using the original partition information, make filesystems for each partition you are going to recover, and mount them. If a filesystem is already created and mounted, you do not need to do this. For example, if you reinstalled / and /usr, you do not need to recreate them.
Invoke NetWorker to recover each filesystem on the disk being recovered, one at time. For example:
venus# /usr/etc/recover NetWorker> add /
Use the list command to check the list of directories and files you are about to recover. Use the force command so that you are not prompted every time a file naming conflict occurs. For example:
NetWorker> list NetWorker> force NetWorker> recover
Recover the lost filesystems, one at time. Open the main window or use the nsrwatch command to monitor NetWorker requests for backup media during the recovery.
| Note: Always reboot a system after recovering a primary disk. |
This section addresses the case in which the /nsr filesystem on a NetWorker server is lost due to a disk crash. The /nsr filesystem contains the indexes that hold the necessary information to recover the NetWorker clients.
If the server loses its operating system and NetWorker commands, these have to be reinstalled first. See “Recovering a Primary Disk on a Client” earlier in this appendix.
The next important step is to recover the server's indexes from the backup media, using the recoverindex command. The recoverindex command asks you for the bootstrap save set ID (ssid). If you followed the procedure recommended to prepare for a disk crash, you have a piece of paper with the name of the backup media you need and the bootstrap save set ID.
For example, save set ID 1148869870 below is the most recent bootstrap backup:
March 11 16:42 1994 NetWorker boostrap information Page 1 date time level ssid file record volume 3/10/94 2:46:02 9 1148868949 56 0 bitbucket.002 3/11/94 2:53:34 9 1148868985 77 0 bitbucket.003 |
If you do not have this piece of paper, you can still recover the indexes by finding the save set ID using the scanner command. (See the section “Finding the Bootstrap Save Set ID” in this appendix.)
You may need more than one backup medium to recover the server's indexes. During the recovery, you can use the nsrwatch command or open the main window to watch for pending messages requesting backup media.
With the operating system and NetWorker in place, recover the indexes from the backup medium:
Obtain the printout of the bootstrap save set ID information.
Retrieve the backup medium that contains the most recent backup named bootstrap, and load it into the server's device.
Use the recoverindex command to extract the contents of the bootstrap backup. For example:
mars# /usr/etc/recoverindex recoverindex: Using mars as server NOTICE: recoverindex is used to recover the NetWorker server's on-line file and media indexes from media (backup tapes or disks) when either of the server's on-line file or media index has been lost or damaged. Note that this command will OVERWRITE the server's existing on-line file and media indexes. recoverindex is not used to recover NetWorker clients' on-line indexes; normal recover procedures may be used for this purpose. See the recoverindex(1M) and nsr_crash(1M) man pages for more details. What is the name of the tape drive you plan on using [dev/rmt/tps1d6nrnsv]? Enter the latest bootstrap save set id []: 1148869870 Enter starting file number (if known) [0]: 88 Enter starting record number (if known) [0]: 0 Please insert the volume on which save set id 1148869870 started into dev/rmt/tps1d6nrnsv. When you have done this, press <RETURN>: Scanning dev/rmt/tps1d6nrnsv for save set 1148869870; this may take a while... scanner: scanning 8mm 5GB tape space.006 on dev/rmt/tps1d6nrnsv uasm -r nsr/res/nsr.res uasm -r nsr/res/nsrjb.res uasm -r nsr/res/ nsrmmdbasm -r nsr/mm/mmvolume nsr/mm/mmvolume: file exists, overwriting uasm -r nsr/index/space/ nsrindexasm -r nsr/index/space/db scanner: ssid 449955156: scan complete scanner: ssid 449955156: 31 KB, 10 files nsr/index/space/db: file exists, overwriting uasm -r nsr/index/ uasm -r nsr/mm/ uasm -r nsr/ uasm -r space: 31 records recovered, 0 discarded. nsrindexasm: Building indexes for mars... nsrindexasm: Caching save times for mars... 8mm 5GB tape space.006 mounted on dev/rmt/tps1d6nrnsv, write protected The bootstrap entry in the on-line index for mars has been recovered. The complete index is now being reconstructed from the various partial indexes which were saved during the normal saves for this server. # nsrindexasm: Pursuing index pieces of nsr/index/space/db from mars. Recovering 2 files into their original locations Total estimated disk space needed for recover is 11 MB Requesting 2 files, this may take a while... nsrindexasm -r .db .db: file exists, overwriting : 25711 records recovered, 0 discarded. nsrindexasm -r .db .db: file exists, overwriting nsrindexasm: waiting for lock on ../db.SCAVENGE nsrindexasm: lock on ../db.SCAVENGE acquired Received 2 files from NSR server `mars' : 733 records recovered, 0 discarded. nsrindexasm: Building indexes for mars... nsrindexasm: Caching save times for mars... nsrindexasm: Suppressing duplicate entries in mars - 50 duplicates discarded. The on-line index for space is now fully recovered.
Notice that the shell prompt appears once bootstrap is recovered. You can use NetWorker commands such as nsrwatch to watch the progress of the server, or nwadmin to bring up the NetWorker Administrator window during the recovery of the index. Open a new shell to monitor the recovery so that the recoverindex output does not display on top of the nsrwatch output.
The recoverindex command also recovers the /nsr/res directory, which is used by NetWorker to store configuration information such as the list of NetWorker's clients and registration information. However, this directory, unlike the indexes, cannot be overwritten or relocated; instead, the recovered /nsr/res directory is renamed /nsr/res.R.
After recoverindex has finished, this final message appears:
nsrindexasm: The on-line index is now fully recovered. |
To complete the recovery of the /nsr/res directory, you need to shut down NetWorker, move the recovered /nsr/res directory into its original location, and then restart NetWorker:
Shut down the NetWorker server using the nsr_shutdown command:
# /usr/etc/nsr_shutdown
Save the original /nsr/res directory, and move the recovered version into the correct location.
# cd /nsr # mv res res.orig # mv res.R res
Restart the NetWorker server
# cd / # nsrd
When NetWorker restarts, it uses the recovered configuration data.
Once you have verified that the NetWorker configuration is correct, you can remove the /nsr/res.orig directory.
# rm -r /nsr/res.orig
To recover other filesystems, see the section “Recovering a Secondary Disk” earlier in this appendix.
If you did not file a hard copy of the bootstrap information, you can still find the save set ID of the most recent bootstrap by using the scanner command.
For example:
The scanner command displays the contents of the backup media, for example:
# scanner /dev/rmt/tps1d1nrnsv scanner: scanning 8mm 5GB tape atlas.005 on /dev/rmt/tps1d1nrnsv client name save set save time level size files ssid S atlas.engr.s / 3/10/94 3:37 f 6072660 1053 3388 E atlas.engr.s /usr 3/10/94 3:37 f 57315808 2985 3387 E atlas.engr.s /usr/people 3/10/94 3:33 f 504417356 19737 3372 S atlas.engr.s /usr/people 3/10/94 3:33 f 1340638812 41067 3372 E scanner: done with 8mm 5GB tape atlas.005 |
In this example, the bootstrap save set ID is 1340638812. Once you find the most recent bootstrap save set ID, you can use the recoverindex command to recover the server's index. Otherwise, use another backup volume to try to find a more recent bootstrap.
This section describes the case where your old NetWorker server is beyond repair, and you wish to recover NetWorker to a new server.
| Note: The new NetWorker server must have the same hostname as the old NetWorker server. |
To recover NetWorker to a new server, follow these steps:
Install the NetWorker software from the original distribution media on the new server.
Note: If you have a jukebox, do not start the NetWorker daemons. See Chapter 11, “Using NetWorker with Jukeboxes,” and “Enabling Autochangers” in Chapter 2 earlier in this guide for jukebox device driver installation and testing. Obtain new NetWorker licenses for all affected systems; see Table 2-2 in Chapter 2, “Installing NetWorker.”
Find the printout of the bootstrap save set ID information from the old server. You will need it for the next two steps.
Retrieve the backup media that contains the most recent backup named bootstrap, and load it into the new server's device.
Use the recoverindex command to extract the contents of t he bootstrap backup.
The NetWorker daemons should start up on the new server. Messages like the following should appear on the new server:
new_server syslog: NetWorker Server: (notice) started new_server syslog: NetWorker Registration: (notice) invalid auth codes detected. new_server syslog: new_server syslog: The auth codes for the following licenses enablers are now invalid. new_server syslog: The cause may be that you moved the NetWorker server to a new computer. new_server syslog: You must re-register these enablers within 15 days to obtain new codes. new_server syslog: new_server syslog: License enabler #xxxxxx-xxxxxx-xxxxxx (NetWorker TurboPak)
Contact Silicon Graphics to obtain the new licenses you need.
Finally, follow these steps after successfully moving your server:
Verify that all the clients are included in the scheduled backups.
Recover the client filesystems and indexes.
Use the Recover window to make sure all the client indexes are visible and therefore “recoverable.”
Back up the indexes on the new server by entering saveindex -l full at the system prompt. (Or, if you prefer, perform a full backup of the new server as soon as possible.)
To use jukeboxes during disaster recovery, follow these steps:
Read the disaster recovery procedures listed in the reference page nsr_crash(1M). Perform all steps up to giving the recoverindex command. If only one volume is needed to recover your NetWorker file indexes, follow the instructions in nsr_crash(1M).
Run the jbm_enabler command to add the jukebox.
Give the command nsrjb -H to reset the jukebox for operation. If any volumes are loaded in the media drives, they are moved back to a slot. This operation may take a few minutes to finish.
Using the instructions in nsr_crash(1M), determine which volumes are needed to retrieve the NetWorker file indexes. Load these volumes into the jukebox.
Give the command nsrjb -I to reinventory the jukebox. To speed up this process, use the command with the -S flag and list the slots where you placed the backup volumes. You must list the slots continuously; for example, nsrjb -I -S 1-3. To inventory slots out of order (for example, 2, 1, and 4), you must use the nsrjb –I –S command separately for each slot.
All the volumes currently loaded in the jukebox are marked with an asterisk because there is no media database.
Load the first volume that recoverindex requests into the first drive in the jukebox. Give this command:
# /usr/etc/nsrjb -l -n -S slot -f device_name
slot is the slot where the first volume is located and device_name is the pathname of the first drive.
Run recoverindex. Provide the same device name as in step 6 above and the last save set ID requested by recoverindex. At this point, NetWorker recovers the file indexes.
After the indexes have been recovered, give the command nsrjb -u.
To recover whole filesystems, use the save set recover feature as explained earlier in this chapter to determine which volumes will be needed. If any of the volumes are not located in the jukebox, load them into the jukebox and inventory those slots. Continue with this process until all your filesystems have been restored.