What's the point of using tar *for backup* today?
in [Shell]
|
From: Barry Margolin on 2 Jan 2010 21:42 In article <sjk217-2gb.ln1(a)nntp.tecneeq.de>, Karsten Kruse <tecneeq(a)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, barmar(a)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 ***
From: Barry Margolin on 2 Jan 2010 21:43 In article <slrnhjtgpj.51k.usenet-nospam(a)guild.seebs.net>, Seebs <usenet-nospam(a)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. -- Barry Margolin, barmar(a)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 ***
From: Keith Thompson on 2 Jan 2010 22:27 Barry Margolin <barmar(a)alum.mit.edu> writes: > In article <slrnhjtgpj.51k.usenet-nospam(a)guild.seebs.net>, > Seebs <usenet-nospam(a)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) kst-u(a)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"
From: Wayne on 3 Jan 2010 03:36 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 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
From: Wayne on 3 Jan 2010 03:40
Wayne wrote: > 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 |