Linear Tape-Open (LTO) at Home in 2026
Disclaimer: This post was written with the assistance of Anthropic’s Claude Opus 5.5 model, which also helped build and debug the setup it describes.
In 2023 I wrote Adventures with Linear Tape-Open (LTO) at Home in 2023, about how I started using an LTO-5 drive for personal backups. I still use tape, but almost everything around it has changed. This post describes how it works now.
What Changed Since 2023
- At the moment, I use an internal LTO-6 drive. It writes both LTO-5 and LTO-6 cartridges, and I use both. Earlier this year I replaced a faulty drive.
- The tars are no longer made on my PC. TrueNAS makes them with cron jobs.
- The tape VM reads the tars from a TrueNAS share over SMB, instead of receiving them through SSH.
- Compression is disabled, so the size of a tar tells exactly whether it fits on a cartridge.
- Encryption is still done in the drive, and the keys are rotated.
- Every cartridge carries a label, and the scripts refuse to write over a cartridge that does not carry the expected label.
- Every write is recorded with the cartridge’s own counters and performance data, and the results go to Prometheus and Grafana.
System Overview
TrueNAS, the tape VM and the monitoring VM with Prometheus and Grafana are all virtual machines on the same Proxmox VE host. The disk controller of TrueNAS and the SAS controller the tape drive is connected to are passed through to their VMs.
digraph g {
rankdir=LR
node[style=filled, shape=box]
subgraph cluster_pve {
label="Proxmox VE host"
tnas[label="TrueNAS\n(cron makes tars)"]
share[label="staging share"]
tapevm[label="tape VM\n(mbuffer, 4 GB)"]
drive[label="LTO-6 drive"]
monitoring[label="Prometheus\nGrafana"]
}
tnas -> share
share -> tapevm [label="SMB"]
tapevm -> drive [label="SAS"]
tapevm -> monitoring [label="metrics"]
}
- Making the tars. Every week, cron jobs on TrueNAS build tars of the datasets I back up, each named after the dataset and the date. Not every tar goes to tape every week. The tars go to a staging share, which holds only tars and nothing that is executed.
- Writing the tape. On the tape VM, a script reads the tar from the share over SMB and writes it to the tape through mbuffer with a 4 GB buffer.
- No buffer problems. A tape drive needs a steady stream of data, or it has to stop and reposition the tape. The 4 GB buffer is enough here. The drive’s own performance data shows that it holds the host back about 72% of the time because its buffer is full, so the source is faster than the drive. The last writes ran at 134–141 MB/s on LTO-5 cartridges, close to LTO-5’s native speed of 140 MB/s.
- But beware. This works because both VMs run on the same Proxmox VE host, so the SMB traffic never leaves the host. If the tars come over a real network, it must deliver more than the drive’s native speed all the time, or a larger buffer is needed.
Labels Against Accidental Overwrites
The worst mistake with tape is writing a backup over the cartridge that holds the last good copy of something else. Labels at two levels, the tar and the cartridge, prevent this.
- The tar has a label. Every tar starts with a tar volume label with the dataset name and the date. It is not a file in the archive, only a header in its first block. The tape script refuses a tar without a label, a tar whose label does not match its file name, and a tar that does not end properly, which catches a tar that was cut short.
- The cartridge has a label. Since the tar is written from the start of the tape, the tar’s label becomes the cartridge’s label. Reading only the first block of a cartridge shows which dataset and date it holds.
- A new cartridge is initialized first. Initializing writes a special label as the first block. Before it does this, the script shows what the cartridge holds and asks me to type its barcode.
- The write checks the cartridge’s label. A dataset is written only onto an initialized cartridge or onto one that already holds the same dataset. A cartridge that holds another dataset is refused.
- An unreadable cartridge is refused. A blank cartridge and one encrypted with a key I no longer have look the same to the drive, so treating unreadable as blank could overwrite real data. A blank cartridge must be initialized.
- The result is read back. After the write, the script rewinds the tape, reads the first block and compares its label with the tar’s. This proves the tape can be read and holds this backup, not its old contents.
Keeping Track of Cartridges
The drive knows a lot about each cartridge, and after every write the script saves it in an index on the tape VM, kept forever:
- The write log, with the dataset, the size, the time it took and the drive’s status.
- The cartridge’s statistics, which the cartridge itself stores: how much was ever written to it and read from it, how many times it was loaded, and how many errors were recovered or not.
- Where the cartridge comes from: manufacturer, production lot and its factory serial number. The barcode is only a sticker and can be changed, but the serial number cannot.
From this index, a report shows the wear and the origin of every cartridge. The scripts also retire cartridges automatically. A cartridge is refused once it has any unrecovered error or has been loaded or used too many times.
Performance Data
During a write, the drive also keeps performance counters for the current mount, such as the write speed, how often it held the host back because its buffer was full, and how often it had to reposition the tape. The script saves these counters after every write. This is how I know that the source keeps up with the drive, and it gives me a baseline for each cartridge.
Monitoring
The tape VM exports the results to Prometheus, and a Grafana dashboard shows them:
- The time since the last successful backup of each dataset, with an alert when a backup is overdue.
- The wear and the last write’s retries and performance of every cartridge.
- Alerts for a cartridge with unrecovered errors and for a drive that reports a fault or needs cleaning.
Conclusion
Tape is still a good cold, offline tier at home. The basic idea has not changed since 2023: make a tar and stream it to the drive. What changed is everything around it. TrueNAS makes the tars on a schedule, labels make sure a backup lands on the right cartridge, and every write leaves a record of the cartridge’s condition and the drive’s performance.
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.