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.
We use Iron Mountain tape vaulting services. The tapes are transported in a locked container that is somewhat weather-proof and foam lined. There is a specific chain of custody regarding this procedure. They're then transported to an offsite tape-vaulting location in an unmarked and alarmed van.
I surely hope that you guys aren't taking your backup tapes home with you.
Edited to add:
Taking them home with you because you're an awesome I.T. guy and trying to be nice, opens you up to a world of hurt when and if that tape gets "lost" or stolen. But, it also depends on what you're backing up. Is it SS#? Is it credit card information? How valuable is the data to someone who would use it for nefarious purposes? (Don't really answer what kind of data it is in this public forum..just questions you need to ask yourself :) )
If this company is too cheap to pay for some other method of getting backups offsite, then make the owner of the company take the tapes home with him/her.
If there are no tape vaulting services in your area, Iron Mountain (Mozy, Amazon S3 with JungleDisk, etc.) offer online backups into the cloud. We are in the process of moving our physical tape backups to cloud based with Iron Mountain, called Live Vault. We're also making use of their Turbo Restore Appliance, which facilitates everyday backups and restores for around 30 days. The rest gets backed up into their cloud. It fits our needs because it's automated AND encrypted. While it's not inexpensive, the loss of business in a disaster, without proper backups to restore to, would be astronomical.
Best Answer
You could try duplicity, it can make incremental backups and send them to a FTP server, gmail, Amazon S3...