this post was submitted on 26 Jan 2025
1 points (100.0% liked)

It's A Digital Disease!

23 readers
1 users here now

This is a sub that aims at bringing data hoarders together to share their passion with like minded people.

founded 2 years ago
MODERATORS
 
The original post: /r/datahoarder by /u/gargravarr2112 on 2025-01-26 14:51:42.

So I've got a tape setup and it's generally working okay. I'm using Bacula to store encrypted backups.

However, I seem to have a box of LTO-6 tapes that won't write their full capacity (2.5TB). I've tried several methods but they never seem to go past about 37GB when being written by Bacula. It's 4 or 5 tapes and I think they're from the same manufacturer, possibly the same batch, so I'm willing to conclude that the tapes are physically faulty. However, as they're fairly expensive for a home user, I wonder if there's any way to fix them. They were bought new, but I don't have a warranty on them.

# mt -f /dev/nst1 status
SCSI 2 tape drive:
File number=0, block number=0, partition=0.
Tape block size 0 bytes. Density code 0x5a (LTO-6).
Soft error count since last status=0
General status bits on (41010000):
 BOT ONLINE IM_REP_EN

Things I've tried:

Bacula's btape program with a rawfill command:

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Write failed at block 576603. stat=-1 ERR=No space left on device
25-Jan-2025 23:20:15 btape: btape.c:408-0 Volume bytes=37.19 GB. Write rate = 44.17 MB/s
25-Jan-2025 23:20:18 btape: btape.c:611-0 Wrote 1 EOF to "LTO6" (/dev/tape/by-id/scsi-DRIVE-nst)

dd:

# dd if=/dev/zero bs=1M | pv -paerts 2500G | dd of=/dev/nst1 bs=1M
dd: error writing '/dev/nst1': No space left on device==================================================================>                                                                         ] 55% ETA 6:02:19
7:35:34 [52.2MiB/s] [52.2MiB/s] [=======================================================================================>                                                                         ] 55%
0+22815195 records in
0+22815194 records out
1495216553984 bytes (1.5 TB, 1.4 TiB) copied, 27336.1 s, 54.7 MB/s

I think I've also tried tar and LTFS, as well as using mt to retension the tape. As much as I could continue experimenting, I also know that each cycle is adding mechanical wear to the tape.

It's not consistent where the tape stops writing when I use additional tools. Trying to seek to EOM on these tapes seems to hit the above limitation - the tape returns EOM far too soon. Is there any way to force the tape to seek past this?

Anyone have any advice?

no comments (yet)
sorted by: hot top controversial new old
there doesn't seem to be anything here