If the tapes have 'expired' then you will need to re-import them into the catalog (which is an index of what is on what tape). I think this is what has happened, and unless you have a backup of that catalog I'm afraid you are going to have to go through tape by tape. This is a two step process (or a two phase process a Symantec calls it).
The first part is to scan the tapes to find the image you need, you then need to import that image so it is ready for backup. So use phase 1 to find the backup running it on each tape, and then phase 2 once you have found it. The second phase can take a while. The instructions are located here, and I recommend you use the command line method as that has worked well for me in the past. The highlights are:
To start a phase 1 import from the command line run the command:
# cd /usr/openv/netbackup/bin/admincmd
# ./bpimport -create_db_info -id <disk_path> -L /usr/tmp/phase1.log
Enter the disk path to use for the import. Then, monitor the /usr/tmp/phase1.log file to monitor the progress of the phase 1 import.
To start a phase 2 import from the command line run the command:
# cd /usr/openv/netbackup/bin/admincmd
# ./bpimport -id <disk_path> -s <startdate> -e <enddate> -L /usr/tmp/phase2.log
I also strongly recommend you flick the hardware lock on each tape to be sure you don't overwrite these images with another backup.
Also, in the future you will want to change the "retention period" on the tapes so the backups remain in the catalog (not sure about your question as to removing the client removes from the catalog, but in case it wasn't infinity). The levels are:
Retention Retention Equivalent
Level Period Days
--------- ----------- ----------
0 1 week 7
1 2 weeks 14
2 3 weeks 21
3 1 month 31
4 2 months 62
5 3 months 93
6 6 months 186
7 9 months 279
8 1 year 365
9 infinity
After you import the tape, you can set the images on this tape to never expire with:
/usr/openv/netbackup/bin/admincmd/bpexpdate -ev B00010 -d infinity
All my commands are unix examples but they should be the same or similar in Windows, also, the link I provided above shows how to do the import with the gui as well.
You should be able to build a new server with Backup Exec and import the tape. The import populates the new database with what was backed up, allowing you to then recover content.
If the database is selected in your backup process, you should also then be able to recover the database in its entirety, including the historical data.
Best Answer
The first thing to check is how much network (TCP) throughput your server can handle. Use netcat, etc. If it is less than around 30 MB/s, multiplexing from network is of no use to you, and my further advice can be ignored. Work on tuning your network throughput instead. Now, to the point.
The LTO3 drive, just like any other linear tape drive, works well only when it gets a stream of data with a certain constant throughput.
The tape is passing under the head at a high speed, and you don't want to stop it. At each stop the drive has to perform lengthy procedure: decelerate to full stop, accelerate back, pass the end-of-data point, decelerate again, accelerate forth to reach the end-of-data point. When data is not feeded by NetBackup fast enough, the buffer underruns frequently and so the drive has to stop/rewind/start frequently. The performance is hurt dramatically. This is called "start-stop" operation or "shoe shining".
Drive adjusts the speed of the tape somewhat, but not very much, it can drop to about 50% of maximum speed.
The whole point of Netbackup multiplexing is to provide a better streaming throughput and avoid start-stop operation. Check the throughput of your RMAN backup, if it is 30 MB/s or less you have a classic start-stop operation.
Now, let me make one thing clear. If you do not have start-stop I would not recommend multiplexing RMAN backups at all. RMAN is complicated enough without multiplexing. I don't want to mess with RMAN, I want my restore to be as fast, easy and seamless as possible.
However, if you find your backup throughput unacceptably low, I would suggest implementing around three multiplexing streams for starters. Increase the number each night until you will not gain any more throughput. And make sure each stream is coming from the different disk spindle(s). Not from different partitions/tablespaces/filesystems/databases/servers/LUNs/other-virtualization-layers. These matter little, if any. Physical disk spindles. If you feed many streams from the same spindles you will just cause thrashing and overall performance will drop even more.
Note: NetBackup theoretically can also de-multiplex a restore. If I remember correctly, it pauses a little before a restore, to give a chance for more restore attempts to launch. In this case they will run jointly, just like multiplexed backups. But please verify this with a manual, I am only 90% sure on this one.