What's the point of using tar *for backup* today?
Eze
as a single attachment file. I realize historically this "tape
archive" utility may have been needed for some technical reasons. But
I don't see the advantages of using tar to back up some files and copy
them to some external storage device. Couldn't you just cp? The files
would already been untarred...
I bring this up because it has been winner or runner-up of the Linux
Journal Readers' Choice Awards as Favorite Backup Utility for several
years. It is also recommended as a "quick and dirty" backup tool at
http://www.linuxquestions.org/linux/articles/Jeremys_Magazine_Articles/Quick_and_Dirty_Backups.
Would someone care to shed some light?
Thanks,
Eze
Sidney Lambe
If you'd just _try_ both methods, you'd soon learn the
answer to your question.
Why do you imagine that the whole rest of the unix/linux
world doesn't know what they are doing?
Sid
Karsten Kruse
> I don't see the advantages of using tar to back up some files and copy
> them to some external storage device. Couldn't you just cp? The files
> would already been untarred...
You could name your tar archives like that:
full_backup_friday.tar
incremental_backup_monday.tar
incremental_backup_tuesday.tar
incremental_backup_wednesday.tar
incremental_backup_thursday.tar
That's kind of hard to do with cp. So it's about organisation of your
backups.
Tar also has many options to choose, it can verify the archive with the
disk content, cp can't do that. It can save space with sparse files, it
works remote via rsh. It can also compress while archiving, unlike cp.
Karsten
--
() My homepage is http://www.tecneeq.de/ and your homepage sucks�!
<\/>
_/\_ �) Unless it has animated gifs from 1996, then it rocks!
Eze
> answer to your question.
I did try, successfully. In fact, lumping many files into one can
easily take you to >4GB, which makes it hard to use the rather common
FAT32 filesystem for external drives, while this is not an issue as
long as your individual files don't go over that limit. I know unix
experts would not use FAT32 at all, but so far I can only see
disadvantages. However, the popularity of tar tells me I'm missing
something.
> Why do you imagine that the whole rest of the unix/linux
> world doesn't know what they are doing?
If I imagined that I wouldn't be asking, but thanks anyway.
Eze
Sidney Lambe
I repeat: Why didn't you _try_ the two approaches? Without
doing that you are going to have a great deal of difficulty
understanding any answers you receeve here. And your questions
will be annoyingly ignorant.
You can't learn how to use the shell by just talking about it.
Are you the same person who just posted a script and asked everyone
if it looked like it would work without even trying it?
Sie
Seebs
> I see the point of using tar in order to, say, send a whole directory
> as a single attachment file. I realize historically this "tape
> archive" utility may have been needed for some technical reasons. But
> I don't see the advantages of using tar to back up some files and copy
> them to some external storage device. Couldn't you just cp? The files
> would already been untarred...
tar can preserve file ownership, permissions, timestamps, and so on.
Also, a tar file can be copied to anything -- say, a FAT32 drive with
no underlying representation for such traits.
-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
Eze
If you just _read_ my original reply you'd find the answer.
> Without doing that you are going to have a great deal of difficulty
> understanding any answers you receeve here. And your questions
> will be annoyingly ignorant.
People don't find ignorance annoying, even in its extreme form. (There
are exceptions, and something tells me you may fit the bill.) It is
the perplexing combination of arrogance and ignorance that annoys
greatly. You provide a sound example, with careless oracle-like
statements about people you don't know which are completely off the
mark. See, I did try the cp and tar methods (hint: "4GB"), and I don't
just talk about the shell. And as far as I know you don't know
anything about the shell either. Interestingly, you wrote as much as
Karsten while providing infinitely less insight. Quite a feat!
> Are you the same person who just posted a script and asked everyone
> if it looked like it would work without even trying it?
No.
Your replies are and encourage off-the-topic posts. I'll leave you the
final word as I want to go back to the shell. Have fun.
Eze
If you just _read_ my original reply you'd find the answer.
> Without doing that you are going to have a great deal of difficulty
> understanding any answers you receeve here. And your questions
> will be annoyingly ignorant.
People don't find ignorance annoying, even in its extreme form. (There
are exceptions, and something tells me you may fit the bill.) It is
the perplexing combination of arrogance and ignorance that annoys
greatly. You provide a sound example, with careless oracle-like
statements about people you don't know which are completely off the
mark. See, I did try the cp and tar methods (hint: "4GB"), and I don't
just talk about the shell. And as far as I know you don't know
anything about the shell either. Interestingly, you wrote as much as
Karsten while providing infinitely less insight. Quite a feat!
> Are you the same person who just posted a script and asked everyone
> if it looked like it would work without even trying it?
No.
Eze
> Also, a tar file can be copied to anything -- say, a FAT32 drive with
> no underlying representation for such traits.
Thank you, Seebs. It's great to see most people actually answering my
question instead of belittling me!
Seebs
Whoops! I'm sorry, I meant to cast aspersions on your sex life.
And you're right about the 4GB limit -- that's an issue, for sure.
Of course, not all filesystems have it.
Another issue is that compression of a tar archive may produce noticably
better compression than compression of all of the individual files.
Mostly, though, it's the preservation of metadata. A "backup" which
loses datestamps is much less valuable.
Wayne
The main reason to use tar instead of cp, is that not everything with a pathname
is a plain file. Files with holes, doors, FIFOs, hard links, etc, are usually
not handled correctly. (Some versions of "cp" have non-standard options to
handle such situations, notably Gnu, but even then it doesn't handle
everything the way you might expect.) So when copying directory trees,
cp is not good enough.
Then there's making archives for backup purposes, or for transporting a
directory tree across systems. This is difficult to do correctly with
standard utilities such as cp (although "scp" or "rsync" would work well
for many cases here). But it is easy to use something like this:
tar -czf - . |ssh user@host 'cd dir; tar -xzpf -'
Other archiving tools can be used such as cpio or pax. However pax is broken
on most Linux distros (it is a port from OpenBSD I think, and doesn't support
the "pax" archive format (required by POSIX/SUS/LSB), so can't handle ACLs
and/or extended attributes correctly). About the most widely supported archive
tool that does handle most things correctly is "star" by Joerg Schilling.
--
Wayne
Evergreen
>
> If you just _read_ my original reply you'd find the answer.
>
>> Without doing that you are going to have a great deal of difficulty
>> understanding any answers you receeve here. And your questions
>> will be annoyingly ignorant.
>
> People don't find ignorance annoying,
They do if it is the result of laziness.
(I dumped your other post to me.)
[delete]
Sid
Seebs
Eze: Don't mind this guy. Google him before you worry about his
criticisms, anyway.
Sidney Lambe
Seebs and Eze. Killfiled.
Current posts dumped.
Odds are high that they are the same person.
Sid
Younes Zouhair
You shouldn't care about what Sidney Lambe, he's just an ignorant troll.
Most of the time he doesn't know what he's talking about.
Seebs
> You shouldn't care about what Sidney Lambe, he's just an ignorant troll.
> Most of the time he doesn't know what he's talking about.
I object strongly to this characterization, on two grounds.
The first is that to be that consistently wrong, I think he'd actually
have to know a fair amount.
The second is that I think that the more conventional sorts of trolls are
going to view this as defamatory.
Mark Hobley
> Eze schrieb:
> You could name your tar archives like that:
>
> full_backup_friday.tar
> incremental_backup_monday.tar
> incremental_backup_tuesday.tar
> incremental_backup_wednesday.tar
> incremental_backup_thursday.tar
>
> That's kind of hard to do with cp. So it's about organisation of your
> backups.
You could still have untarred backup disks and label the disks as:
full_backup_friday
incremental_backup_monday
incremental_backup_tuesday
incremental_backup_wednesday
incremental_backup_thursday
>
> Tar also has many options to choose, it can verify the archive with the
> disk content, cp can't do that. It can save space with sparse files, it
> works remote via rsh. It can also compress while archiving, unlike cp.
You could also do all of the above with a copy utility (albeit you may have to
write one).
In fact, when I backup to CDR media, I tend not to create a tarball, but write
the untarred content straight to the .iso image. I wonder how many other
people do this.
Mark.
--
Mark Hobley
Linux User: #370818 http://markhobley.yi.org/
Younes Zouhair
> On 2010-01-02, Younes Zouhair<pob...@gmail.com> wrote:
>> You shouldn't care about what Sidney Lambe, he's just an ignorant troll.
>> Most of the time he doesn't know what he's talking about.
>
> I object strongly to this characterization, on two grounds.
>
> The first is that to be that consistently wrong, I think he'd actually
> have to know a fair amount.
>
> The second is that I think that the more conventional sorts of trolls are
> going to view this as defamatory.
>
> -s
Duly noted!
Eze
Usenet. (I promise I'll follow it!)
jellybean stonerfish
>> If you'd just _try_ both methods, you'd soon learn the answer to your
>> question.
>
> I did try, successfully. In fact, lumping many files into one can easily
> take you to >4GB, which makes it hard to use the rather common FAT32
> filesystem for external drives, while this is not an issue as long as
> your individual files don't go over that limit. I know unix experts
> would not use FAT32 at all, but so far I can only see disadvantages.
> However, the popularity of tar tells me I'm missing something.
For added confusion, you could pipe the output of "tar" through "spit"
to break up a huge archive into SIZE sized pieces.
tar -cz DIR/TO/SAVE | split -b $SIZE - dir.tar
superpollo
> On 2010-01-02, Eze <garzon...@gmail.com> wrote:
>>> tar can preserve file ownership, permissions, timestamps, and so on.
>>> Also, a tar file can be copied to anything -- say, a FAT32 drive with
>>> no underlying representation for such traits.
>
>> Thank you, Seebs. It's great to see most people actually answering my
>> question instead of belittling me!
>
> Whoops! I'm sorry, I meant to cast aspersions on your sex life.
>
> And you're right about the 4GB limit -- that's an issue, for sure.
isn't it possible to combine the tar approach with -- say -- 'split' or
'dd' and 'cat' and then have multiple <agb chunks to be restitched later?
John Koy
http://en.wikipedia.org/wiki/Archive_file
But for small backup tasks, you're right. Now (Gnu) cp command has
several backup related options, I use cp with them for personal backups.
The forum post you cite is almost 5 years old, not a current reference.
pk
GNU tar seems to have a --multi-volume switch that, together with --tape-
length might be useful (I haven't tested it, but there is extensive
information in the info page).
Barry Margolin
Karsten Kruse <tec...@tecneeq.de> wrote:
> Eze schrieb:
>
> > I don't see the advantages of using tar to back up some files and copy
> > them to some external storage device. Couldn't you just cp? The files
> > would already been untarred...
>
> You could name your tar archives like that:
>
> full_backup_friday.tar
> incremental_backup_monday.tar
> incremental_backup_tuesday.tar
> incremental_backup_wednesday.tar
> incremental_backup_thursday.tar
>
> That's kind of hard to do with cp. So it's about organisation of your
> backups.
Couldn't you do the same thing with the name of the toplevel directory
of the copy, e.g.
cp -R <directory> /backups/full_backup_friday
> Tar also has many options to choose, it can verify the archive with the
> disk content, cp can't do that. It can save space with sparse files, it
> works remote via rsh. It can also compress while archiving, unlike cp.
Of course, all these things could be done by scripting the copies, or by
writing a dedicated backup application.
--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
Barry Margolin
Seebs <usenet...@seebs.net> wrote:
> Mostly, though, it's the preservation of metadata. A "backup" which
> loses datestamps is much less valuable.
cp has an option to preserve timestamps and other metadata.
Keith Thompson
> In article <slrnhjtgpj.51k...@guild.seebs.net>,
> Seebs <usenet...@seebs.net> wrote:
>> Mostly, though, it's the preservation of metadata. A "backup" which
>> loses datestamps is much less valuable.
>
> cp has an option to preserve timestamps and other metadata.
Yes, but not all media are able to store that information. Others
have mentioned FAT32, which isn't very good at storing ownership and
permission information.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Wayne
> Seebs ha scritto:
>
> isn't it possible to combine the tar approach with -- say -- 'split' or
> 'dd' and 'cat' and then have multiple <agb chunks to be restitched later?
I don't see how split helps. Tar still thinks it is creating a too-large
archive and will choke. Or, if the source system's tar can handle large
archives, the tar at the destination will choke after combining the chunks.
You need a modern tar (and/or cpio) at both ends if your archives are
going to be large. Other issues can limit portability too, such as
whether or not Unicode filenames are supported (and the charset they're
stored in withing the archive; else the names be be converted if you
have a different locale set at each end).
Split is useful when you need to send large archives (or other files) as
email attachments when your email system imposes a size limit per
attachment and/or per email. Otherwise look into Gnu tar's multi-volume
options.
--
Wayne
Wayne
> The main reason to use tar instead of cp, is that not everything with a pathname
> is a plain file. Files with holes, doors, FIFOs, hard links, etc, are usually
> not handled correctly. (Some versions of "cp" have non-standard options to
> handle such situations, notably Gnu, but even then it doesn't handle
> everything the way you might expect.) So when copying directory trees,
> cp is not good enough.
>
Actually I'm not sure which tools do correctly handle files with holes. As
neither tar nor cpio are standardized it may depend on your OS and tool version.
the pax standard man page for SUS at the opengroup.org site doesn't say anything
about files with holes.
--
Wayne
Karsten Kruse
> Actually I'm not sure which tools do correctly handle files with holes.
GNU-tar does what one would expect with sparse files. So, if you are on
Linux you are lucky because you probably have GNU-tar, otherwise you
might have to install it yourself.
Karsten
--
() My homepage is http://www.tecneeq.de/ and your homepage sucks�!
<\/>
_/\_ �) Unless it has animated gifs from 1996, then it rocks!
jellybean stonerfish
> superpollo wrote:
>> Seebs ha scritto:
>>> And you're right about the 4GB limit -- that's an issue, for sure.
>>
>> isn't it possible to combine the tar approach with -- say -- 'split' or
>> 'dd' and 'cat' and then have multiple <agb chunks to be restitched
>> later?
>
> I don't see how split helps. Tar still thinks it is creating a
> too-large archive and will choke. Or, if the source system's tar can
> handle large archives, the tar at the destination will choke after
> combining the chunks.
You don't combine the chunks into a file. You combine them with "cat'
and pipe the output through "tar" to un-archive. 'tar' works on a stream of
characters. Un-archiving a huge archive is not a problem.
jellybean stonerfish
>
> You don't combine the chunks into a file. You combine them with "cat'
> and pipe the output through "tar" to un-archive. 'tar' works on a
> stream of characters. Un-archiving a huge archive is not a problem.
Or so I've been told.
Ben Finney
s/characters/bytes/
> Or so I've been told.
Decades of confusion propagated by the C language doesn't change the
fact that characters are not bytes, and vice versa :-)
--
\ “I may disagree with what you say, but I will defend to the |
`\ death your right to mis-attribute this quote to Voltaire.” |
_o__) —Avram Grumer, rec.arts.sf.written, May 2000 |
Ben Finney
Kaz Kylheku
> as a single attachment file. I realize historically this "tape
> archive" utility may have been needed for some technical reasons. But
> them to some external storage device. Couldn't you just cp? The files
> would already been untarred...
cp requires a filesystem, which is a structured organization of data.
tar uses ... a structured organization of data. Hmm!
The difference is that tar's data structure is not mounted by your kernel
into the usual filesystem space, so you are using a different ``API''.
But that can be changed with a suitable piece of software, like
tar support in the kernel, or through a user space loop like Linux's FUSE.
Jerry Peters
Or mc. I often use mc if I just want 1 or 2 files out of a large
tarball.
Jerry
Alan Curry
Let me add something: not going through the kernel is an advantage
sometimes. Since the tarball is seen by the kernel as a single big file,
creating it doesn't require the creation of a zillion inodes, all being
individually cached in kernel memory for some unpredictable amount of time
during and after the backup, which is what you get with cp -a.