From owner-freebsd-questions@FreeBSD.ORG Sun Jun 10 23:05:29 2012 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 561CF106564A for ; Sun, 10 Jun 2012 23:05:29 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id EB6E18FC08 for ; Sun, 10 Jun 2012 23:05:28 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.5/8.14.5) with ESMTP id q5AN5SbS078742; Sun, 10 Jun 2012 17:05:28 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.5/8.14.5/Submit) with ESMTP id q5AN5SaM078739; Sun, 10 Jun 2012 17:05:28 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Sun, 10 Jun 2012 17:05:28 -0600 (MDT) From: Warren Block To: "Ronald F. Guilmette" In-Reply-To: <48302.1339366497@tristatelogic.com> Message-ID: References: <48302.1339366497@tristatelogic.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Sun, 10 Jun 2012 17:05:28 -0600 (MDT) Cc: freebsd-questions@freebsd.org Subject: Re: Making a bootable backup (hard)disk... how? X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2012 23:05:29 -0000 On Sun, 10 Jun 2012, Ronald F. Guilmette wrote: > > In message , > Warren Block wrote: > >> On Sun, 10 Jun 2012, Ronald F. Guilmette wrote: >>> 1) In your example under the heading "Copying Filesystems", the second >>> shell command line shown is: >>> >>> dump -C16 -b64 -0uanL -h0 -f - /usr | (cd /mnt && restore -ruf -) >>> >>> Is that correct? Shouldn't it actually be this instead? >>> >>> dump -C16 -b64 -0uanL -h0 -f - /usr | (cd /mnt/usr && restore -ruf -) >>> ... >> The mount command above that is >> >> mount /dev/da0s1f /mnt > > Ah! OK. I failed to notice that. Yes, that clarifies things entirely. > >>> ... I mean if I do the pipeline from dump >>> to restore as you have shown in your examples in your "Copying Filesystems" >>> section, then what must I do in order prevent dump from dumping files that >>> haven't changed? (And likewise, how do I prevent restore from trying to >>> restore files under /mnt/usr that have not changed? Or is that answer to >>> that question that I simply have to do the first thing, i.e. force dump >>> not to dump any of the unchanged files?) >> >> See the dump man page about dump levels. > > OK, I'm looking at it, and to be honest, the subject of dump levels is > not covered at all well there. (Neither does it seem to be covered well > in other online documents, found via Google, that purport to describe > dump & restore.) The reference to "modified Tower of Hanoi algorithm" > and the subsequent suggested dumplevel sequence are especially opaque > and perplexing. It's diffs. One complete copy to start, then a partial dump, just the files that have changed since the first. And then another partial, just the files that have changed since the second. Start over with a full dump every so often, because that reduces the amount of backups that have to be restored until you get to the final version of the file. As far as I can recall, I've always used level zero. > What I don't understand (and what I wish someone would enlighten me about) > is just this: It would seem that in order to implement these dump levels, > dump must be keeping a record somewhere, for each file in the filesystem, > of the level at which that file was last dumped. But where is this infor- > mation stored, exactly?? I won't be able to sleep until I know. > > (Aside: One of the reasons I hate Windoze is that everything is hidden. > One of the reasons I love UNIX is that everything is out in the open, > which is to say "documented". But even after reading the dump(1) man > page, it ain't in the least bit obvious to me where dump is recording > the last dump level for each node in the filesystem. This info must be > stored SOMEWHERE. But where?) Sorry, I've never checked. File dates, maybe. The source for dump would be the place to look. >> rsync will do it, and would be my choice for that; start with -aH for >> options, and --exclude might be used for some directories that don't >> need to be copied. > > Humm... well, I am reminded of all of the reasons why I have been convinced > (now) to use dump/restore, specifically the security of knowing that _all_ > info will be copied across, in particular (a) extra mode bits/flags and (b) > ACLs and (c) file attributes. (This is not to even mention correct handling > of other obscure filesystem things like, e.g. sparse files.) > > So the obvious question is: If I am going to use rsync to keep my backup > disk up-to-date, does rsync handle all of these additional small but > important filesystem details properly too? If not, then I had best just > stick with dump/restore, and use the dumplevels. It does many of those things, enough that many people use it for backup. > Right. There's that. So I will need to diddle the /etc/fstab in the backup. > >> Use gpart(8) GPT labels... > > Ummm... I don't know pooh about this, but I am reading about it now, and > the idea make me _very_ nervous. Apparently, `MBR' is traditional, and > I am very much of a traditionalist. (Mostly I find that I only get into > trouble when I try to buck pre-existing conventions.) > >> or tunefs(8) filesystem labels. > > I guess you must mean the "-L volname" option. I'm not at all sure that I > see how that would help anything. When a mountpoint is /dev/gpt/myrootfs, it doesn't matter whether the drive shows up as ada0 or ad4 or da2, the mount still works. >> Likewise with the >> Ethernet board, so see rc.conf(5) about ifconfig_DEFAULT. > > Something else (the Handbook?) mentioned something about the ethernet card(s) > in the context also. I just don't get it. Why would I even need to think > about that in this context? My current system disk is alive & well and > already has all of the proper ifconfig stuff in /etc/rc.conf to make the > local ethernet card work properly on my network. I am engaged in making a > _verbatim_ backup of my main system disk to another hard disk that, in > an emergency, would be plugged in to the exact same system (with the exact > same ethernet card) and if I have made the verbatim backup properly, then > it also will have the proper stuff in _its_ /etc/rc.conf file to make that > same ethernet card work. So what exacty is the issue? I don't get it. Lightning strikes the machine and only the backup disk is available. Labels and a generic ifconfig let that disk boot and work on a different system. Those details can make recovery significantly easier. Of course, the more we talk about this, the more it sounds like you might as well just create a mirror and let the system do all the duplication in real time.