Every LTO tape drive comes with a datasheet listing a maximum native transfer rate. These numbers are real \u2014 but they describe a theoretical ceiling, not a realistic operating point. In practice, every installation falls short of them. The only question is by how much.<\/p>\n\n\n\n
This article explains the reasons why.<\/p>\n\n\n\n
Three LTO generations are currently on the market. LTO-7 remains technically available but is approaching end of life.<\/p>\n\n\n\n The examples in this article use LTO-9<\/strong> as the reference point. The same principles apply to all generations \u2014 but the faster the drive, the greater the absolute impact of each negative factor. A bottleneck that costs 50 MB\/s on an LTO-8 system costs the same 50 MB\/s on an LTO-9 system, but represents a larger share of a higher theoretical ceiling.<\/p>\n\n\n\n All analysis in this article is based exclusively on the native (uncompressed) transfer rate<\/strong> \u2014 400 MB\/s for LTO-9. The compressed figure of 1,000 MB\/s is deliberately excluded, for two reasons.<\/p>\n\n\n\n First: in media and archive environments, data is already compressed.<\/strong> H.264, H.265, JPEG, camera RAW formats, ZIP archives, and encrypted files yield little or no additional compression when the tape drive’s hardware compressor processes them. The 2.5:1 ratio that produces the 1,000 MB\/s figure simply does not materialize with this type of content. The native rate is the only number that translates into reality.<\/p>\n\n\n\n Second: including the compressed rate makes every negative factor look proportionally worse, not better.<\/strong> If the theoretical ceiling is raised from 400 MB\/s to 1,000 MB\/s, but the actual throughput in a given environment is 180 MB\/s, the gap between spec and reality widens from 55% to 82%. Citing compressed speeds in the context of performance analysis serves only to make the shortfall appear more dramatic \u2014 or to obscure it by making 180 MB\/s sound like it is still “close to” a number no real workload ever reaches.<\/p>\n\n\n\n The native rate is the honest baseline. All deviations discussed below are measured against it.<\/p>\n\n\n\n The rated 400 MB\/s for LTO-9 is measured under ideal laboratory conditions: a single large file, perfectly compressible data, a lossless data feed, a full-height drive, and hardware that can sustain the required throughput without interruption. None of these conditions exist simultaneously in a production environment.<\/p>\n\n\n\n Although theoretically 400 MB\/s is possible, actual LTO-9 write speeds under realistic conditions are more likely to be 300\u2013370 MB\/s \u2014 and network latency and server load reduce write speed further.<\/p>\n\n\n\n That gap between spec and reality is not a defect. It is the cumulative effect of the factors described below \u2014 all of which reduce throughput, none of which increase it beyond the rated maximum.<\/p>\n\n\n\n An LTO-9 drive writes at the speed it receives data. If the source \u2014 a disk array, NAS, or backup server \u2014 cannot deliver data at 400 MB\/s continuously, the drive slows down to match. Common bottlenecks on the source side include spinning HDD arrays with insufficient IOPS, 1 GbE network connections to NAS systems (theoretical max: 125 MB\/s), CPU saturation on the backup server, and file system overhead when processing large numbers of small files.<\/p>\n\n\n\n Backup software is gated largely by environmental factors. If the system is seeing significant deviation from the LTO-9 drive’s 400 MB\/s, the bottleneck typically lies in the host environment, not the drive itself.<\/p>\n\n\n\n Tape is a sequential medium optimized for writing large, contiguous data. In P5’s native backup format, the tape drive always sees a continuous stream \u2014 file count has no direct impact on tape throughput. However, the overhead appears on the source side: every file requires an open, stat, and read call on the source filesystem. For a directory containing hundreds of thousands of small files, this metadata traversal accumulates into a measurable reduction of the data rate that P5 can feed to the drive.<\/p>\n\n\n\n A workload of 500,000 small project files, thumbnails, or audio stems will therefore saturate the source filesystem and backup server CPU before it saturates the tape drive \u2014 even if the total data volume is the same as a handful of large MXF files.<\/p>\n\n\n\n This distinction matters for LTFS as well, but there the file count problem is compounded further: LTFS writes per-file markers and block alignment padding directly to tape, meaning the tape drive itself is additionally impacted \u2014 not just the source side. The next section covers this in detail.<\/p>\n\n\n\n LTFS (Linear Tape File System) formats a tape cartridge like a file system, making it mountable on any compatible operating system without proprietary software. That portability comes at a throughput cost that does not exist when writing with purpose-built backup software in native tape format.<\/p>\n\n\n\n Every LTFS volume maintains an XML-based index of all files and metadata. This index must be written to tape at unmount, and can be configured to sync at intervals during a session. Each sync requires the drive to seek to the index partition, write the updated index, and then reposition to resume writing.<\/p>\n\n\n\n On a densely populated LTO-9 tape (18 TB, many files), the index itself becomes large, and each write adds measurable latency. LTFS Format Specification 2.5 (ISO\/IEC 20919:2021) introduced an incremental index approach that records only changes between full syncs, reducing but not eliminating this overhead. A full index write at unmount remains mandatory regardless.<\/p>\n\n\n\n A significant drawback of LTFS is the loss of read and write performance caused by additional file markers, the mandatory alignment of files to block boundaries, and the forced updating of the index. These elements result in very inefficient use of tape capacity, especially for smaller files.<\/p>\n\n\n\n LTFS is not suitable for workloads dominated by small files. Seek time during readback can be up to a minute per file, making access times extremely high. The standard recommendation is to create a tar archive first and write that to the LTO-9 tape via LTFS, rather than writing individual small files directly.<\/p>\n\n\n\n LTFS is the right format for specific use cases: large-file sequential workflows (video originals, RAW image sets) written once and read back as complete sets, and data interchange scenarios where tapes must be readable across different systems without shared proprietary software. For these cases, the overhead is manageable and the portability benefit is real. For everything else, a native backup format will deliver better throughput.<\/p>\n\n\n\n One further caveat worth noting: LTFS also allows a tape to be used as a directly mounted filesystem \u2014 browsing and opening individual files via Finder or Explorer. In that access pattern, LTO seek times of 10 to 100 seconds per file become the dominant factor, making the throughput considerations discussed above largely irrelevant compared to the latency problem. This use case opens an entirely different set of performance issues that go beyond the scope of this article.<\/p>\n\n\n\n Knowing the theoretical factors is one thing. Determining which of them is responsible for a specific performance shortfall in a specific environment requires a methodical approach.<\/p>\n\n\n\n Consider a typical setup: a P5 backup job reading from a NAS volume over a 10 GbE network and writing to an LTO-9 drive. The 10 GbE interface has a theoretical maximum of 1,250 MB\/s, but practical TCP throughput for large sequential reads from a well-configured NAS is realistically around 800\u2013900 MB\/s \u2014 well above what LTO-9 needs. With the drive’s native rate at 400 MB\/s, a reasonable real-world expectation for this configuration is around 250 MB\/s<\/strong>, accounting for typical software overhead and speed matching.<\/p>\n\n\n\n If the actual job throughput is only 120 MB\/s, something is wrong. The question is what.<\/p>\n\n\n\n A production environment has too many variables active simultaneously to isolate any one cause by observation alone. Network, NAS, HBA, OS scheduler, backup software, file structure, tape, drive firmware \u2014 any of these could be the bottleneck, and several could be contributing at once. Changing one setting and re-running a full production job is slow, and the result still carries all the noise of the other variables.<\/p>\n\n\n\n The correct approach is to build a controlled testbed, establish a baseline under optimal conditions, and then introduce variables one at a time.<\/p>\n\n\n\n The goal of the initial testbed is to eliminate as many potential bottlenecks as possible, establishing a clean reference point for what the drive and software can actually deliver on this specific hardware. A minimal effective configuration:<\/p>\n\n\n\n This removes the NAS and the network entirely. The data path for backup is: NVMe \u2192 P5 \u2192 SAS HBA \u2192 LTO-9 drive. For restore: LTO-9 drive \u2192 SAS HBA \u2192 P5 \u2192 NVMe. Any remaining shortfall from the expected ~350\u2013370 MB\/s at this stage points to a local issue: HBA configuration, driver, OS scheduling, P5 settings, or the drive itself.<\/p>\n\n\n\n P5’s job monitor shows a throughput indicator during the backup, but the definitive measurement is the total job duration<\/strong>. Divide the data volume by the net backup time \u2014 excluding the job preparation phase (tape mount, positioning, initialization) which can account for 30\u2013120 seconds depending on the tape’s current position.<\/p>\n\n\n\n For 1 TB of test data at 350 MB\/s, the expected backup time (excluding preparation) is approximately 48 minutes<\/strong>. At 120 MB\/s, the same job takes approximately 2 hours 20 minutes<\/strong>. The difference is unambiguous.<\/p>\n\n\n\n Once the baseline is established, variables are introduced one at a time, re-running both the backup and a full restore<\/strong> after each change and recording the result:<\/p>\n\n\n\n At each step, if throughput drops materially relative to the previous step, the variable just introduced is a contributing factor. Testing backup and restore separately at each stage is important \u2014 a bottleneck that only affects writes will be invisible in backup measurements and only appear during restore.<\/p>\n\n\n\n A common customer observation: backup runs at expected speed, but restore is significantly slower. The cause is almost always on the write side of the restore path, not the tape.<\/p>\n\n\n\n During backup, P5 reads from a filesystem and writes a sequential stream to tape. The tape is the bottleneck candidate. During restore, P5 reads sequentially from tape \u2014 which continues to work well \u2014 but writes to a filesystem. That filesystem write path has its own constraints:<\/p>\n\n\n\n In the testbed, restoring to a local NVMe volume eliminates all of these variables simultaneously. If backup and restore both run at ~350 MB\/s to and from NVMe, but restore to the production NAS is significantly slower, the NAS write performance is the confirmed bottleneck \u2014 not the tape, the drive, or P5.<\/p>\n\n\n\n At the NVMe baseline<\/strong>, throughput significantly below 350 MB\/s for both backup and restore suggests a local bottleneck: verify that the SAS HBA is not shared with other devices, check HBA driver version, and confirm the drive firmware is current. If backup is fast but restore to NVMe is slow, suspect a P5 restore configuration issue or a driver problem affecting write performance.<\/p>\n\n\n\n When replacing NVMe with spinning disks<\/strong>, a drop is expected and normal. The question is whether it drops below the disk array’s measured sequential read and write speeds, which can be verified independently with When adding the NAS over 10 GbE<\/strong>, measure NAS read and write performance independently before running P5 jobs. A tool like One result that sometimes surprises: the testbed with 1 TB of large media files performs well, but the production backup of a real project directory \u2014 nominally the same size \u2014 takes noticeably longer.<\/p>\n\n\n\n It is important to distinguish what is actually happening here. P5 writes to tape as a continuous stream, regardless of how many individual files the backup contains.<\/strong> The tape throughput itself is not degraded by file count \u2014 P5’s native format does not write per-file markers or alignment padding the way LTFS does. The drive sees a stream and writes accordingly.<\/p>\n\n\n\n What does increase with file count is the overhead on either side of that stream:<\/p>\n\n\n\n When measuring backup performance by total job duration, both of these can make a high-file-count job appear slower than its tape throughput actually was. If this discrepancy appears, separating the tape write phase from the indexing phase in the job log gives a clearer picture of where the time is going.<\/p>\n\n\n\n The LTO-9 datasheet says 400 MB\/s native. Every factor below moves the needle in one direction only.<\/p>\n\n\n\n A slow data source does not immediately stop a backup. Modern LTO drives respond by dynamically adjusting their tape speed to match the incoming data rate \u2014 a mechanism known as speed matching or data rate matching. This reduces the frequency of backhitch events compared to older drive generations, but it does not eliminate them.<\/p>\n\n\n\n Speed matching has a lower bound. According to IBM’s official drive specifications:<\/p>\n\n\n\n If the incoming data rate falls below<\/strong> the minimum threshold, the drive can no longer compensate by slowing the tape further. The tape stops, the drive waits for the data buffer to refill, then repositions the tape a short distance back and resumes writing \u2014 a backhitch (also known as shoe-shining). The data is written correctly, but throughput drops sharply.<\/p>\n\n\n\n A concrete example: a 1 GbE network connection has a real-world throughput of around 100\u2013110 MB\/s \u2014 already below the LTO-9 minimum of 180 MB\/s. Any LTO-9 installation reading from a source over 1 GbE will backhitch continuously, regardless of how well everything else is configured.<\/p>\n\n\n\n Note:<\/strong> Falling below the minimum streaming rate does not cause immediate damage or data loss. What it does cause is a chronically inefficient operating mode: increased mechanical wear on the head assembly and tape transport mechanism from repeated stop\/reposition cycles, higher error correction activity as the drive repeatedly repositions and realigns, and reduced media efficiency as tape is consumed by repositioning overhead rather than user data. A system that runs in this condition persistently will see shorter drive and media service life over time \u2014 even if individual backups complete successfully.<\/p>\n<\/blockquote>\n\n\n\n The minimum threshold increases with each generation: the faster the drive, the higher the floor, and the more demanding the requirements on the host environment.<\/p>\n\n\n\n The factors discussed above share a common characteristic: they are all operational \u2014 caused or influenced by the environment the user builds and maintains. A slow NAS, a congested network, a high file count, an LTFS pool \u2014 these are conditions that exist in a running installation and can be measured, isolated, and addressed.<\/p>\n\n\n\n The following factors also affect LTO throughput in principle, but lie outside this scope:<\/p>\n\n\n\n Drive form factor (full-height vs. half-height):<\/strong> Full-height drives reach higher peak speeds within the same generation. This is a hardware procurement decision, not something that changes in a running installation. It only becomes relevant when operating at the very upper limit of what the environment can deliver.<\/p>\n\n\n\n LTO generation (e.g., LTO-10 vs. LTO-9):<\/strong> LTO-10 offers no native speed improvement over LTO-9. Relevant as a purchasing decision, not as a factor in an existing installation.<\/p>\n\n\n\n LTO-9 media optimization:<\/strong> A one-time characterization pass required on new, unwritten LTO-9 cartridges. Affects only the first write session on a fresh tape and has no bearing on ongoing backup performance.<\/p>\n\n\n\n Specifications sourced from lto.org and IBM manufacturer announcements (2025).<\/em><\/p>\n","protected":false},"excerpt":{"rendered":" Every LTO tape drive comes with a datasheet listing a maximum native transfer rate. These numbers are real \u2014 but they describe a theoretical ceiling, not a realistic operating point. In practice, every installation falls short of them. The only<\/p>\n","protected":false},"author":7,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[20,9,58,56,43,55,135],"tags":[54,53,26,95,162,163],"class_list":["post-5628","post","type-post","status-publish","format-standard","hentry","category-archive","category-backup","category-how-to","category-operating-systems","category-p5","category-storage","category-technology","tag-archive","tag-backup","tag-lto","tag-lto-tape","tag-p5-archive","tag-p5-backup"],"yoast_head":"\nGeneration<\/th> Native Speed<\/th> Compressed Speed (2.5:1)<\/th> Native Capacity<\/th> Backward Compatible With<\/th><\/tr><\/thead> LTO-8<\/td> 360 MB\/s<\/td> 900 MB\/s<\/td> 12 TB<\/td> LTO-7 (read\/write)<\/td><\/tr> LTO-9<\/td> 400 MB\/s<\/td> 1,000 MB\/s<\/td> 18 TB<\/td> LTO-8 (read\/write)<\/td><\/tr> LTO-10<\/td> 400 MB\/s<\/td> 1,000\u20131,200 MB\/s<\/td> 30 TB \/ 40 TB<\/td> none<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
\n\n\n\nA Note on Which Speed We Are Talking About<\/h3>\n\n\n\n
\n\n\n\nThe Theoretical Maximum Is Just That: Theoretical<\/h3>\n\n\n\n
\n\n\n\n1. The Source Cannot Keep Up<\/h3>\n\n\n\n
\n\n\n\n2. Small Files: Filesystem Overhead on the Source<\/h3>\n\n\n\n
\n\n\n\n3. LTFS Adds Its Own Layer of Overhead<\/h3>\n\n\n\n
Index writes interrupt the data stream<\/h5>\n\n\n\n
File markers and block alignment<\/h5>\n\n\n\n
Small files compound the problem<\/h5>\n\n\n\n
When LTFS is the right choice anyway<\/h3>\n\n\n\n
\n\n\n\n4. Diagnosing Performance Problems: A Structured Approach<\/h3>\n\n\n\n
The scenario<\/h5>\n\n\n\n
Why guessing is inefficient<\/h5>\n\n\n\n
The testbed: starting from the best possible baseline<\/h3>\n\n\n\n
\n
Measuring correctly<\/h3>\n\n\n\n
Successive introduction of variables<\/h3>\n\n\n\n
\n
Why restore is often slower than backup \u2014 and how to find out<\/h3>\n\n\n\n
\n
What to look for at each stage<\/h3>\n\n\n\n
dd<\/code> or fio<\/code>. A gap between disk capability and P5 throughput points to filesystem or I\/O scheduler issues \u2014 or a higher small-file count than expected.<\/p>\n\n\n\nrsync<\/code> or a simple cp<\/code> of a large file gives a reliable reference point. If P5 backup matches the NAS read speed but restore falls well below the NAS write speed, the NAS write path \u2014 not the tape \u2014 is the bottleneck.<\/p>\n\n\n\nThe file structure problem \u2014 and why it affects P5 differently<\/h3>\n\n\n\n
\n
\n\n\n\nSummary<\/h2>\n\n\n\n
Factor<\/th> Why It Reduces Throughput<\/th><\/tr><\/thead> Slow source I\/O \/ network<\/td> Hard ceiling \u2014 LTO-9 drive throttles down to match incoming data rate<\/td><\/tr> Many small files (native format)<\/td> Filesystem overhead on source and P5 indexing \u2014 tape throughput itself is unaffected<\/td><\/tr> LTFS: index writes<\/td> Periodic and unmount-time interruptions of the data stream<\/td><\/tr> LTFS: file markers \/ alignment<\/td> Overhead per file \u2014 severe with small file workloads<\/td><\/tr> LTFS: seek time<\/td> 10\u2013100 sec per seek; random access is slow by design<\/td><\/tr> —<\/td> <\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n What Happens When the Minimum Is Undercut: Speed Matching and Backhitch<\/h3>\n\n\n\n
Drive<\/th> Speed Matching Range (native)<\/th><\/tr><\/thead> LTO-8<\/td> 112\u2013360 MB\/s<\/td><\/tr> LTO-9<\/td> 180\u2013400 MB\/s<\/td><\/tr> LTO-10<\/td> 180\u2013400 MB\/s (not officially published; same native rate as LTO-9)<\/em><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n \n
\n\n\n\nFactors Outside the Scope of This Article<\/h3>\n\n\n\n
\n\n\n\n