Probably a LTO drive a few generations old and a SAS card. Current generations cost too much and you aren't going to be able to keep up with the data rate that they prefer.
From personal experience you are not going to be able to saturate even a horrifically obsolete LTO drive and SAS interface without specialized software or purely sequential data. Most of the cheap/free ways of running tape drives aren't optimized for parallel I/O and will horrifically shoe-shine (that's the rev-up and rev-down sound you hear when the tape drive isn't getting enough data), which isn't great for the tapes and massively increases backup time and drive usage.
AFAIK most commercial tape deployments nowadays are disk-to-disk-to-tape arrangements. All the actual data is serialized to an archive on disk first, and then that serialized archive is written to tape at full speed. This minimizes tape wear and ensures your very expensive tape drives are being used efficiently.
I am using a LTO-7 drive connected to a FreeBSD server.
FreeBSD always succeeds to write the tape continuously at about 300 MB per second, which is the maximum speed for LTO-7.
All the files send to the tape are grouped into large archive files and for the dd command that writes to tape I use a block size of 128 kB.
The tape commands from FreeBSD are more convenient than those from Linux, which have not seen much maintenance in recent years.
Obviously, you cannot reach tape speed when making the backup directly from a HDD or from a 1 Gb/s Ethernet.
You must write the backup to tape either from a fast SSD, or from 10 Gb/s Ethernet coming from a fast SSD at the other end, or from a RAM disk configured on the server, if you have enough memory.
To not wear unnecessarily the SSDs on my server where the tape drive is located, whenever I write the backup, I configure a large RAM disk on the server. The backup files coming through Ethernet to the server are written to the RAM disk on the server, then they are copied to the tape.
With this arrangement it is very easy to ensure that the tape drive is written at maximum speed without any hiccups.
I would like very much if someone would introduce a tape drive with an USB interface, using the USB-Attached-SCSI-Protocol.
This would have no importance for software, as the tape drives would continue to be seen as SCSI devices. The performance of USB is adequate and an USB tape drive could be cheaper, while also saving money for not needing a SCSI HBA.
Unfortunately, there are no tape drives for modern tape standards with USB and no hope that one will appear soon.
I use a tabletop tape drive. Internal tape drives are a little cheaper, but I think that the external drive is more reliable, because it is protected from dust when not active and it is well cooled (even if it is noisy) when it is active.
Previously I have used a SCSI HBA card for PCIe, together with an external SCSI cable having the appropriate connectors.
The server motherboard that I am using now has on-board SCSI, so I have a cable from motherboard to the case, having internal SCSI connectors at one end, to plug in the motherboard, and external connectors at the other end, in a cover for a the opening of an expansion card slot on the case.
Then I have an external SCSI cable to connect the tabletop drive.
With SCSI cables, you must pay attention to the connectors at each end, because there are many variants. On the motherboard I have internal high-density connectors, on the case I have external high-density connectors, while on the tape drive I have external lower-density connectors.
I have used 2 kinds of SCSI HBA cards, some with LSI controllers, e.g. LSI LSI00343 SAS 9300-8E Host Bus Adapter, and a similar card with a Microsemi controller (now Microchip). There were no differences, all were OK.
The SCSI HBA cards may have either external connectors or internal connectors or both kinds, so you must choose the appropriate card, depending on whether your drive is internal or external.
The only difficulty that I had in the past was that on some motherboards the computer did not boot with the SCSI card inside and I could not understand why.
I have even bought a second SCSI HBA card from a different vendor, wrongly believing that it is buggy.
The problem turned out to be not a bug, but a standard feature :-(
When booting in legacy mode, some add-in cards, including all SCSI cards and all GPUs, attempt to map their ROMs adding BIOS functions in the address space above 640 kB but under 1 MB, which is accessed in the Intel real-address mode.
The SCSI cards do this for the case when you will attach a HDD or a SSD and you would want to boot from it, which the MB BIOS does not know how to do.
On the computers that refused to boot, without any errror message, I also had a NVIDIA GPU. The sizes of the SCSI ROM with the NVIDIA ROM together exceeded the reserved address area mappable by the BIOS, so the BIOS failed to initialize the GPU. When either one of the 2 cards was present booting was OK, with both cards the computer remained stuck with a blank screen.
The solution for those cards to work together was to go in the BIOS at PCIe properties, select the slot where I intended to put the SCSI card and disable the mapping of the extension ROM.
However, not all BIOSes have these options. On one of my Supermicro MBs, the BIOS had the option, but it did not have any effect, due to a BIOS bug. While I have been very content with the hardware of my Supermicro motherboards, I have encountered a lot of bugs in their BIOSes.
Because I use the HBA only for tapes, disabling the ROM has no consequence, because I never want to boot from SCSI.
Very insightful comment on the data rate, if you can't feed the LTO properly, it may be stopping and starting all the time, which could have a detrimental effect to its mechanism. But this is probably easily fixed by spooling (using bacula terminology). You buffer like 100Gbytes, write them in one batch. Plus, some drives support variable speeds.
Also, in addition to SAS, a fibre channel card would also fit the bill, albeit probably a trifle more expensive. But if you go for low speeds (e.g. 8Gbps), those cards can be less than 100$.
For example, I collect all the files that I send to backup in archive files whose size is approximately 50 GB, then I copy to the tape the 50 GB files.
Doing like this, the write speed to a LTO-7 drive is always constant at 300 MB per second, which is the maximum possible for that standard (which is much higher than what a HDD can sustain, so the 50 GB files must come from a fast SSD or from a RAM disk).
I didn't know -- or perhaps remember -- that you had to match the feed against the speed, sort of like the way you had to be very careful about burning CD-Rs in the old days, but that makes perfect sense.
I have been fearfully realizing that I will soon need tape backup for my next project and this is helpful. Now I am wondering if a RAID 0 of multiple HDDs could provide the ~300 MB/s speed needed.
You do not have to match the speed, but you should.
Sending the data fast enough to the drive will reduce both the total time required for backup, when the drive is active, and it will also avoid starting and stopping a lot the drive during the transfer.
Both eliminating the start-stop cycles and reducing the total active time will increase the life of your tape drive.
On my server I have 128 GB of DRAM, which makes it extremely easy to ensure maximum speed without wearing a SSD.
When the backup starts, I create an 80-GB RAM disk, larger than the up to 60 GB archives in which I collect the files sent to backup.
With less memory one could either use smaller chunks or use a SSD instead of the RAM disk, but that seems wasteful.
Then the archive files are buffered in the RAM disk and written in one command, without pauses.
> Current generations cost too much and you aren't going to be able to keep up with the data rate that they prefer.
Maybe. Keeping up only really matters if your slowest data rate is going to be between 50MB/s and 120MB/s. If it's below that then you have a strong need for a buffer drive no matter what tape generation. And if it's above that then you shouldn't have any real trouble no matter what tape generation.
