Date: Sun, 10 Jun 2012 17:05:28 -0600 (MDT) From: Warren Block <wblock@wonkity.com> To: "Ronald F. Guilmette" <rfg@tristatelogic.com> Cc: freebsd-questions@freebsd.org Subject: Re: Making a bootable backup (hard)disk... how? Message-ID: <alpine.BSF.2.00.1206101640290.78656@wonkity.com> In-Reply-To: <48302.1339366497@tristatelogic.com> References: <48302.1339366497@tristatelogic.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 10 Jun 2012, Ronald F. Guilmette wrote: > > In message <alpine.BSF.2.00.1206100543280.75580@wonkity.com>, > Warren Block <wblock@wonkity.com> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1206101640290.78656>