If I understand you correctly, running the backup job on the server with the tape drive (fetching data from one or more other servers over the network) results in an unacceptably high CPU load on that server, so you wish to run the backup job on the remote server(s) instead.
Backing up data to tape (or any storage medium) is an I/O intensive task, and should not by itself cause the CPU load to increase noticably on a server with a half-decent controller. However, compressing the data prior to backing it up can be both CPU and memory intensive, and I would guess that is what you're seeing. What software are you using to perform the backup?
Edit: I see now that you say the CPU load issue occurs mainly during restores. That sounds rather odd. Are you restoring directly to the original server over the network, and if so, what network file system are you using?
There's no way to "export" a raw device node over the network and mount it on another server, as a device node is just a pointer to an internal (kernel) device on a given system.
I can think of at least four ways to offload the CPU-intensive parts of your backup job to another server (or in one case, another device):
- Using hardware compression
If your tape drive supports hardware compression (and most do), you can configure your backup software to rely on that rather than sending pre-compressed data to the drive. Hardware compression in a tape drive is likely to be slightly less efficient than software compression, but using it will dramatically reduce the CPU load on the server.
- Using an accelerator agent
Some backup software supports the concept of an "agent", a piece of software you install on any servers you want to collect data from for the purpose of backing it up. Whether or not this will offload a significant portion of the backup job to the server being backed up, depends on the agent design.
- Piping the data stream across the network
Rather than fetching the files using a network file system of some sort, the backup job can run on the remote server and the resulting data stream can be sent to a (network) pipe rather than a tape device. The server with the backup device will act as the other endpoint of the pipe, and write the data to the tape drive. This can be implemented using nothing but tar, netcat and a compression tool (gzip, bzip etc.)
- Exporting the tape drive as an iSCSI target
This is the "proper" way to share SCSI devices across the network: You export the drive as an iSCSI target, and access it with an iSCSI initiator from anywhere. I suggested SCST because it works extremely well, both performance-wise and in terms of stability and functionality, but as you point out, one has to install it (and even patch the kernel to achieve the best possible performance).
A while back, a competing SCSI target architecture (LIO) was included in the kernel, but unfortunately the RAW target needed to export a tape device ("PSCSI") doesn't exactly come highly recommended by the developers. (Also, over the last few years the developers have deprecated two different sets of management tools, and I could never get the damned thing to work, while setting up SCST is a breeze.)
Option
2 may not be available to you, depending on the software being used, and I would consider
3 a (potentially quite ugly) hack.
4 is as close to an "official" solution as you can get, but
1 may actually solve your problem almost as effectively, and requires no software and hardly any configuration at all.
