Hey folks,
I'm reading up on gtar for tape archiving and it sounds kind of nasty and not something I really want to rely on.
It looks like star from the schily tools is preferred. I'm using Centos (and RHEL) 5.7 which seems to have star but not sdd.
Which leads me to believe that the Schily tools are maybe a bit "rogue"
My basic requirement with what I'm doing is to use standard tools and formats so that archives I write today can be readable in 10 years.
Is the use of Schily tools going to be contrary to my basic requirement? Is that considered a risk for future readability?
thanks, -Alan
On Mon, Feb 6, 2012 at 12:04 PM, Alan McKay alan.mckay@gmail.com wrote:
Hey folks,
I'm reading up on gtar for tape archiving and it sounds kind of nasty and not something I really want to rely on.
It looks like star from the schily tools is preferred. I'm using Centos (and RHEL) 5.7 which seems to have star but not sdd.
I don't think there is any such general consensus. Are you reading something that favors Solaris/*bsd over GNU based systems?
Which leads me to believe that the Schily tools are maybe a bit "rogue"
I doubt if they are as well maintained in linux distros as the GNU tool set, particularly in terms of having recent fixes backported into the versions carried in enterprise distros.
My basic requirement with what I'm doing is to use standard tools and formats so that archives I write today can be readable in 10 years.
I've never had any doubts that current GNU tar would extract archives made with it 10+ years ago - in fact I'm fairly sure I've done that. Or that I'd be able to obtain a copy of it in the future.
Is the use of Schily tools going to be contrary to my basic requirement? Is that considered a risk for future readability?
It shouldn't matter if you don't use either of the version's extensions, and for archiving you probably don't need them. For example, star and GNUtar use very different concepts for incremental backups - star is sort of like dump and must work on filesystem boundaries where GNUtar's --listed incremental needs a file to hold state but will work on arbitrary directories and can span mount points. But for archiving, you probably only care about the maximum size of a file it can handle.
Are you reading something that favors Solaris/*bsd over GNU based systems?
No, why, are the Schily tools standard over there?
I've never had any doubts that current GNU tar would extract archives made with it 10+ years ago - in fact I'm fairly sure I've done that. Or that I'd be able to obtain a copy of it in the future.
Yeah, that is the plus side. But it seems gtar is rather abysmal at recovering from errors in archives so if there is ever a problem, you're cooked.
Is there any truth to that?
On Mon, Feb 6, 2012 at 12:58 PM, Alan McKay alan.mckay@gmail.com wrote:
Are you reading something that favors Solaris/*bsd over GNU based systems?
No, why, are the Schily tools standard over there?
Not necessarily - just that GNUtar is not ubiquitous and there might be more concern about strict UStar format compliance.
I've never had any doubts that current GNU tar would extract archives made with it 10+ years ago - in fact I'm fairly sure I've done that. Or that I'd be able to obtain a copy of it in the future.
Yeah, that is the plus side. But it seems gtar is rather abysmal at recovering from errors in archives so if there is ever a problem, you're cooked.
Is there any truth to that?
I don't think so - I'm fairly sure I've seen GNUtar complain about bad headers, say 'skipping to next header' and then find something. It won't do that if you used the -z option because you generally can't recover from errors in compression. But, I've never seen a tape drive recover from an error and continue past it anyway so in practice that's not going to matter. If you are concerned about errors, keep more copies.
I don't think so - I'm fairly sure I've seen GNUtar complain about bad headers, say 'skipping to next header' and then find something. It won't do that if you used the -z option because you generally can't recover from errors in compression
Bam! As an aside to my current line of questioning, I was looking for an excuse not to compress and you just gave it to me! Yay!
Compressing makes it nigh impossible to know whether or not the data will fit on the tape without doing a test compress ahead of time, which can take several hours depending on the amount of data.
On Mon, Feb 6, 2012 at 3:04 PM, Alan McKay alan.mckay@gmail.com wrote:
Compressing makes it nigh impossible to know whether or not the data will fit on the tape without doing a test compress ahead of time, which can take several hours depending on the amount of data.
Tape drives generally have their own compression options that you can change with the mt command. Their speed can also vary wildly depending on the block size you use and whether you can supply the data fast enough to keep them streaming.
On 2012-02-06, Alan McKay alan.mckay@gmail.com wrote:
Bam! As an aside to my current line of questioning, I was looking for an excuse not to compress and you just gave it to me! Yay!
afio is an archiver (available from third-party repos, not base) which can compress yet still recover--it basically compresses each file individually instead of compressing the entire archive, so the file might be unrecoverable but the rest of the archive is still intact. I use it for my tape backups (though your point of not knowing if it'll fit on the tape is valid).
--keith
At Mon, 6 Feb 2012 16:04:18 -0500, Alan McKay wrote:
I don't think so - I'm fairly sure I've seen GNUtar complain about bad headers, say 'skipping to next header' and then find something. It won't do that if you used the -z option because you generally can't recover from errors in compression
Bam! As an aside to my current line of questioning, I was looking for an excuse not to compress and you just gave it to me! Yay!
Compressing makes it nigh impossible to know whether or not the data will fit on the tape without doing a test compress ahead of time, which can take several hours depending on the amount of data.
My experience with tapes ended shortly after DAT tape appeared (used 1/4" then 8mm), so this may be out of date; however, I associate tape backups of disk partitions with dump(8), restore(8), and rmt(8), along with cpio(1) for data files. Some shared software used to come on 1/4" tape in tar format. The only compression I recall (vaguely) was standard ("POSIX" on GNU/Linux) compress(1P). Anyway, I would never put non-standard compression on tape that might be used on a different POSIX system.
- Greg
Greg Peterson peterson@notredame.ac.jp
-
Alan McKay -
Greg Peterson -
Keith Keller -
Les Mikesell