> From owner-freebsd-questi...@freebsd.org Sat Jun 9 21:33:57 2012
> To: Arthur Chance <free...@qeng-ho.org>
> Date: Sat, 09 Jun 2012 19:30:53 -0700
> From: "Ronald F. Guilmette" <r...@tristatelogic.com>
> Cc: freebsd-questions@freebsd.org
> Subject: Re: Making a bootable backup (hard)disk... how?
>
>
> In message <4fd38b9a.4010...@qeng-ho.org>,
> Arthur Chance <free...@qeng-ho.org> wrote:
>
> >There's a BFI (brute force and ignorance) way of doing it in the base
> >system - dd. Provided your system disk is quiescent (ideally when
> >running from a live CD or all partitions mounted read-only, otherwise
> >pray to the deity of your choice) and the backup disk is a) at least as
> >large as the system disk, and b) has the same sector size, then a simple
> >dd from the system disk to the backup should work.
>
> Thank you Arthur, and yes, trying to back up a partition that's currently
> mounted r/w using dd will almost certainly not produce the desired results.
>
> And of course, as you correctly note also, the target partition had best be
> at least as big as the source (and perhaps even identical in size).
>
> I don't care to take own my system to make backups... and don't believe
> that I should have to do so, and thus, this is one of the reasons why I
> would prefer to use something like cpio.
>
> Also, I don't like backups taking longer than absolutely necessary, and
> this is why I am specifically _not_ attracted to either the dd solution
> or to dump/restore, because as I understand it, with either of these methods
> you end up copying perhaps a metric buttload worth of unallocated free
> disk space. (I would prefer not to do that. It just seems wasteful...
> of time, if nothing else.)
Dump does *NOT* copy 'unallocated free disk space'. It does a directory-
based traversal. And copies only the contents of the files encountered.
does not copy 'deleted but still open' files, nor does it include deleted
directory entries in the copy of the directory.
dump _can_ be used on a r/w-mounted filesystem. It is smart enough to
make multiple passes, note files that have changed since the prior pass,
and re-copy those changed files into the archive. As long as changes
are relatvely 'infrequent', and to 'small' files, dump will generally
manage to outrun the changes. Since dump works through the O/S, it also
catches data and/or meta-data changes that are buffered/cached in O/S
memory that have not actually made it to disk, yet.
Using dump on a mounted, active, writable filesystem is "not recommended",
but it -does- work adequately, assuming the write activity on the filesystem
is low.
*IF* the filesystem is fairly full, with source and dest arranged such that
they do not saturate I/O controller capabilities, 'dd' (or, preferably 'ddd'
which is a double-buffered drop-in replacement) with large buffers (several
times the size of the 'on disk' cache'), _is_ the fastest way to make a
backup of the data.
> Also, in one case, one of my partitions has one directory that contains
> a really massive amount of stuff, and I specifically _don't_ need any of
> that particular stuff (in that one directory) backed up. So again, I'm
> looking at tar or cpio or perhaps pax. (Of course cpio is more full-featured
> than tar, and I don't really know anything about pax, so that leaves me
> with cpio.)
Pax (the portable archiver) is the "new, improved, with miracle whitener"
cpio -- does everthing tradtional cpio does, and more. it will read/write
four different (and mutually incompatable) 'cpio' formats, and two different
'tar' formats.
One can replace pretty much any use of 'cpio' or 'tar' (or their cousins)
with pax. It _is_ worth investigating.
> when. (Sigh. The good old daze.... when men were men, and the bits ran
> scared!)
>
> Moral of the story is that sometimes it actually does pay to be a smartass.
>
>
> Regards,
> rfg
>
>
> P.S. It really is a Damn Shame[tm] that nobody ever hacked FreeBSD cpio
> to make it be able to copy (a) the extra file flag/mode bits and/or (b)
> file ACLs and/or (c) file attributes.
If pax doesn't already support extended flags, it would be a relatively
trivial hack to get it to do so. Ditto for ACLs. pax uses libarchive ("man
3 archive") which has the capabilities for handling those things in the
description of an archive entry. One would probably want to declare it as
a separate archive 'type' -- to support auto-detect of the inclusion of that
'extended' metadata.
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
