I understand your frustration–I share it around the lack of drive support for drive-native encryption, which has nothing to do with TrueNAS–but some of this is a limitation of how LTO currently works and the lack of standardization among the LTO consortium when it comes to interfaces and tape library support. Only one company currently produces LTO-9 drives with native Thunderbolt. So, everything else not only needs drive, adapter, and possibly library drivers (especially if your library does anything complicated or requires KMIP). This will then complicate your life with TrueNAS.
Assuming you can get your hardware to work at all on TrueNAS, at best you’d be exposing a raw tape device. The “smarts” of LTO backups are generally either in the backup software or in the firmware/hardware for hardware compression and (if you have the right KMIP software) the hardware-based AES-256-GCM encryption. That means if you don’t have problems with the drivers, you’ll still need to find backup software that can see the right data, and I’m not sure that ZFS snapshots capture sufficient data to restore from tape if your backup software doesn’t know how to treat them as ZFS snapshots. That’s why I’m suggesting LTFS rather than block storage.
Some of this may be the way iX seems to draw the line between “preconfigured appliance” and “flexible ZFS-based RAID arrays with additional services,” but in fairness most of the complexity is in ZFS itself and in the hardware and software limitations of the current generation of LTO devices. That’s why some LTO backup systems opt for LTFS by default: it’s dealing with what appear to be files, not raw data blocks, and that often makes differentials and appends faster and more time-efficient (although less space-efficient) to handle via LTFS and its index rather than as data blocks, whether raw or as part of a tar-like backup.
Except for raw block storage, the LTFS approach is likely a better approach for most (although certainly not all) use cases. Even in the case of a block-storage zvol, you can always find a way to treat it as a file (e.g. dd or a disk image cloner) rather than as just ZFS-specific data blocks. LTFS doesn’t care; it’s just a file system, so as long as you can copy the data you want from one filesystem to another “it just works.” Snapshots are more of a filesystem internal, so any non-LTFS backup software would need to understand the internals to handle snapshots as something other than files or a disk image.
Your mileage will definitely vary, but I would personally recommend Canister for doing efficient backups onto LTFS unless it lacks support for some particular hardware. It currently handles all drives (most are really IBM drives anyway) that can use LTFS, but your mileage may vary with libraries as Canister can grow your differential or incrementals (including offline indexes) across tapes automagically, but AFAIK it leaves the tape library functions to your drivers or hardware.
Whatever you decide to do, let us know. I’m deeply interested in how people are stringing their LTO solutions together, and you may discover something I haven’t run across yet.