[kmeisthax]

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.

[adrian_b]

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.

[vermaden]

Hi,

how that LTO-7 drive is attached to the host? Is it USB 3.0 external drive or internal drive with additional controller?

Thanks.

[monocasa]

It's probably fibre channel if external, or SAS if internal.

[adrian_b]

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.

[vermaden]

What about these:

- https://ltoworld.com/products/unitex-lt70h-lto7-usb-3-0-ltfs...

- https://www.backupworks.com/unitex-LT60-LTO-6-USB3-Drive.asp...

[bombcar]

It may even be possible to find on eBay a multi tape loader that has a disk inside and appears to the system as just a dumb tape drive.