What This Error Means (30 seconds to understand)
You're backing up to tape and Windows throws 0x80000022, or STATUS_NO_DATA_DETECTED. That translates to: the tape drive hit a spot where there's no more written data — but it wasn't supposed to be empty yet. Think of it as the drive saying "I reached the end of the file, but you asked me to read past that."
I saw this first with an LTO-5 drive on a Dell PowerVault TL2000. The backup would run for hours, then fail at 93% every time. The client was ready to buy a new server. Ended up being a dirty read head.
Here's the thing: 90% of the time this error is caused by one of three things — a dirty drive head, a misconfigured backup app, or a worn-out tape. Rarely is it a dead drive. So work through these in order.
Quick Fix: Clean the Tape Drive (30 seconds to 2 minutes)
Dirty read/write heads cause all sorts of nonsense, and 0x80000022 is a classic. Magnetic particles shed off the tape and stick to the head. The drive misreads and thinks there's no data when there is.
Grab a cleaning tape. Every LTO drive has one. Pop it in, let it run its cycle (usually 30–60 seconds), and eject. That's it. Then try your backup again.
Don't skip this even if the drive is new. I had a brand-new LTO-6 drive that failed the same way — factory grease on the head. A cleaning tape fixed it permanently.
Moderate Fix: Check Your Backup Software Settings (5 minutes)
If cleaning didn't help, the error is likely coming from your backup app not understanding the tape format. This happens a lot when you're reusing a tape that was previously written by different software or a different drive.
For Windows Backup (wbadmin) or NTBackup, make sure you're not trying to append to a tape that's already been finalized. Check if the tape is set to append vs overwrite. Overwrite will erase the old data and start fresh. Append might hit that end-of-data marker and throw this error.
If you're using something like Veritas Backup Exec or Veeam, look for the tape media pool settings. A tape that's marked as "read-only" or "write-protected" can cause this. Right-click the tape in the management console and choose "Mark as Free" or "Recycle" — that resets the end-of-data marker.
Also verify the tape isn't write-protected. Flip the little switch on the front of the cartridge. If it's set to lock, the drive can't write, and some drives report that as an end-of-data error.
Advanced Fix: Replace the Tape or Update Firmware (15+ minutes)
Still failing? Time to look at the physical media or the drive itself.
Step 1: Swap the tape. Tape cartridges have a limited number of passes. An LTO tape rated for 260 full backups might die after 150 if you're always doing incremental jobs. Look for visible wear on the tape edge or any creases. If you have a spare tape, try that. If the spare works, the original is toast. Recycle it.
Step 2: Update the drive firmware. You wouldn't believe how many tape errors get fixed by a firmware update. I've seen LTO-7 drives ship with bugs that cause premature end-of-data errors on certain tape brands. Check the drive manufacturer's website (HP, IBM, Quantum, Dell) for the latest firmware. Download it, run the updater — typically a Windows executable that flashes the drive via SCSI or SAS. Takes 10 minutes, but worth it.
Step 3: Check the SCSI/SAS connection. A flaky cable can cause data corruption that the drive interprets as no data. Reseat both ends of the cable, and if it's a SAS cable, try a different port. While you're at it, run the drive's built-in diagnostic (usually via the backup software's drive tool) to confirm the head is still good.
If after all this you're still getting 0x80000022, the drive's read/write head is probably dying. That's a hardware replacement. But honestly, in my experience, 7 out of 10 times it's the cleaning, 2 out of 10 it's the tape, and 1 out of 10 it's something weird. So start with the quick fix and work your way down.
Real-world note: One client had this error every Monday morning. Turns out the janitor unplugged the tape library to vacuum, and the drive's temp read buffer was corrupted. A reboot fixed it. But I only found that after a week of chasing firmware and cleaning. Lesson: check the simple stuff first.