From owner-freebsd-questions@FreeBSD.ORG Mon Mar 4 20:19:10 2013 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3697AD3D for ; Mon, 4 Mar 2013 20:19:10 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 0BBD811C7 for ; Mon, 4 Mar 2013 20:19:09 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id 5F79A3B669 for ; Mon, 4 Mar 2013 12:19:09 -0800 (PST) From: "Ronald F. Guilmette" To: freebsd-questions@freebsd.org Subject: Re: backups using rsync In-Reply-To: <20130304125634.8450cfaf.freebsd@edvax.de> Date: Mon, 04 Mar 2013 12:19:09 -0800 Message-ID: <10012.1362428349@server1.tristatelogic.com> X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 20:19:10 -0000 In message <20130304125634.8450cfaf.freebsd@edvax.de>, Polytropon wrote: >On Mon, 04 Mar 2013 03:35:30 -0800, Ronald F. Guilmette wrote: >> Now, unfortunately, I have just been bitten by the evil... and apparently >> widely known (except to me)... ``You can't use dump(8) to dump a journaled >> filesystem with soft updates'' bug-a-boo. > >There are other tools you can use, for example tar or cpdup >or rsync, as you've mentioned in the subject. tar I already knew about, but I think you will agree that it has lots of limitations that make it entirely inappropriate for mirroring an entire system. This cpdup thing is entirely new to me. Thanks for mentioning it! I really never heard of it before, but I just now installed it from ports, and I'm perusing the man page. It looks very promising. Too bad it doesn't properly handle sparse files, but oh well. That's just a very minor nit. (Does it properly handle everything else that rsync claims to be able to properly handle, e.g. ACLs, file attributes, etc., etc.?) >The same problems that apply when dumping live systems can >bite you using rsync, What problems are we talking about, in particular? I am guessing that if I use rsync, then I *won't* encounter this rather annoying issue/problem relating to UFS filesystems that have both soft updates and journaling enabled, correct? >but support for this "on file system >level" seems to be better in rsync than what dump does "on >block level". What exactly did you mean by "this" ? >> If I use all of the following rsync options... -a,-H,-A, -X, and -S .... >> when trying to make my backups, and if I do whatever additional fiddling >> is necessary to insure that I separately copy over the MBR and boot loader >> also to my backup drive, then is there any reason that, in the event of >> a sudden meteor shower that takes out my primary disk drive while leaving >> my backup drive intact, I can't just unplug my old primary drive, plug in >> my (rsync-created) backup drive, reboot and be back in the sadddle again, >> almost immediately, and with -zero- problems? > >You would have to make sure _many_ things are consistent >on the backup disk. Well, this is what I am getting at. This is/was the whole point of my post and my question. I want to know: What is that set of things, exactly? >Regarding terminology, that would make the disk a failover disk OK. Thank you. I will henceforth use that terminology. >The disk would need to have an initialized file system and >a working boot mechanism, both things rsync does not deal with Check and check. I implicitly understood the former, and I explicitly mentioned the latter in my original post in this thread. But is there anything else, other than those two things (which, just as you say, are both clearly outside of the scope of what rsync does)? Anything else I need to do or worry about in order to be able to use rsync to create & maintain a full-blown fully-working system failover drive? If so, I'd much rather learn about it now... you know... as opposed to learning about it if and when I actually have to _use_ my failover drive. Regards, rfg