Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Hello Dears,
I have problem with reading files backed up on a tape
I have three backed up files, when I run tar tvf /dev/nst0, the first file returns, then when I run the same command again, the following error returns:
tar: /dev/nst1: Cannot read: Input/output error
tar: At beginning of tape, quitting now
tar: Error is not recoverable: exiting now
But when I run the same command for the third time, it returns the second file.
Is nst1 a typo or did you actually copy / paste the message in your post. If you copied / pasted the error message then you used the wrong device id. Make sure you used /dev/nst0 every time you ran the tar command.
The thing you are running up against is called tape marks.
A tape contains files recorded starting from the beginning of the tape, and continuing until the end of file mark (a tape mark). A "end of volume" is identified by two tape marks with no file in between.
Running "tar -xvf /dev/nst1" reads the first file (a tar file) from the tape, and stops after reading the tape mark.
Running it again hits the second tape mark.. (usually the name nst1 means "no rewind on drive st1"), causing the EOT/BOT(end-of-tape/beginning-of-tape) error message. Running it a third time puts you AFTER the marked EOT (the two tape marks already read) and it attempts to read the next file.
That last read is not necessarily a valid read... What is usually done after creating a tar tape is that the tape is rewound at the end (causing the second tape mark). This second tape mark USUALLY corrupts the beginning of any following data, but doesn't have to - if the new file recorded from the beginning of tape is a bit shorter than an old file, the two tape marks CAN just occur before the second old file. Sometimes this is EXACTLY what you want (as in recovering data from a damaged tape, or an accidentally overwritten tape).
Before writing a tape, you must first position the tape to the right place. By default that is the beginning of tape. IF the tape is rewound at this point, two tape marks are recorded (the EOT), thus there are actually 3 tape marks there, one for the end of file for the first file, and two to mark the end of tape. In normal recording, the last two are then spaced backwards to position the tape after the first tape mark. A second file can then be recorded, which will overwrite the EOT.
But whenever the tape is rewound will leave the two tape marks marking the end of tape.
To record two (or more) files on the tape in different sessions, you must position the tape at the EOT, so that the new file added will overwrite the EOT mark.
Running "tar -xvf /dev/nst1" reads the first file (a tar file) from the tape, and stops after reading the tape mark.
Close, but not quite right. What actually happens is that tar recognizes the all-zero header block that marks the end of the archive and stops reading before encountering EOF. That leaves the tape positioned just before the file mark. The next process that reads from the tape gets an immediate EOF.
The solution is either (a) advance the tape beyond the file mark either by reading from it or by running "mt fsf /dev/nst0", or else (b) use the "-i" or "--ignore-zeros" option to tell tar to ignore the all-zero block and read to EOF.
Not reliable at all. My dad keep his old VHS tapes in the attic you know what happened.
I personally have a zipp tape drive and 5 1/4 floppy (from thrift stores) for the capability of loading old data but would never rely on them for current data. And, true BD only 22\25 gigs (annoying for lots of data but last for ever compared to tape), hard drives tho, are cheap and bigger but it's your\their data.
Last edited by jamison20000e; 08-26-2013 at 08:51 PM.
A blu-ray that'll hold 1.6Tb per media? Nope.
A blu-ray that'll let me mount 8 media in one go and have my backup segmented on to defined media? Nope.
Quote:
Originally Posted by jamison20000e
hard drives tho, are cheap and bigger but it's your\their data.
~$25 for an LTO4 tape that'll hold 800Gb uncompressed is pretty cheap. Our current backup/storage runs to approximately 200 tapes including long-term backup as well as daily rotation and I'd not be happy with 8 hard disks (no matter how securely packaged) being shiped between site/archive once a week.
So while hard disk may be suitable for home/hobby level backup I'll stick with my LTO4 tapes.
Industries can spend more (but don't need to the readers cost a fortune) because they make more so as long as you don't want any tapes lasting more than 15\30 years and paying more than disk (even for the tapes only according to Wikipedia)...
P.s: sorry for getting this thread a little of track (no pun intended) aside from the title of which I still LL
:Edits.
Last edited by jamison20000e; 08-27-2013 at 01:05 PM.
Over the lifetime of a drive (which alone is rather expensive) gets amortized by the volume of tapes used. Usually between 300-1000 per drive (which would be between 450TB to 2,500 TB depending on actual compression rates). Most sites using tapes for backup will have roughly 7000 to 9000 tapes for every 4 drives. The site I worked at had about 30,000 tapes for 6 drives. So the primary expense was the tapes, not the drives.
And tapes are cheaper than disks - little to no electronic parts (the LTO drives do have a usage/error monitor flash memory unit).
The cost of the drive is in the motion control - the drives transfer data as fast, if not faster, than disks - limited mostly to whatever the controller-memory interface can do. And the drive does onboard data compression/decompression, which disks can't do (it tends to destroy the block nature of a disk - no space is saved by compressing disk blocks). The only speed penalty is the initial seek to a file location, and since the tapes now have directory entry capability, seeks over 1.5 TB is under 45 seconds. After that, no seeks required, allowing continuous I/O around 140MB/sec, or better.
If disks can evolve, so can tapes. Both are based on the same technology. The advantage of tapes is their mechanical stability over time (fewer moving parts).
Drop a tape, and it still works. Drop a disk... and it doesn't work, usually.
And the cost advantage is in favor of tapes - if you use thousands. Also uses less power.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.