From owner-freebsd-questions@FreeBSD.ORG Mon Mar 4 14:00:35 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 BAADCC64 for ; Mon, 4 Mar 2013 14:00:35 +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 496D51A10 for ; Mon, 4 Mar 2013 14:00:35 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.6/8.14.6) with ESMTP id r24E0YNU066840; Mon, 4 Mar 2013 07:00:34 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.6/8.14.6/Submit) with ESMTP id r24E0TuQ066837; Mon, 4 Mar 2013 07:00:34 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Mon, 4 Mar 2013 07:00:29 -0700 (MST) From: Warren Block To: "Ronald F. Guilmette" Subject: Re: backups using rsync In-Reply-To: <6126.1362396930@server1.tristatelogic.com> Message-ID: References: <6126.1362396930@server1.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]); Mon, 04 Mar 2013 07:00:34 -0700 (MST) Cc: freebsd-questions@freebsd.org 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 14:00:35 -0000 On Mon, 4 Mar 2013, 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. Until SUJ has been deemed 100%, I avoid it and suggest others do also. It can be disabled on an existing filesystem from single user mode. > 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? It works. I use this to "slow mirror" SSDs to a hard disk, avoiding the speed penalty of combining an SSD with a hard disk in RAID1. Use the latest net/rsync port, and enable the FLAGS option. I use these options, copying each filesystem individually: -axHAXS --delete --fileflags --force-change --delete removes files present on the copy that are not on the original. Some people may want to leave those. --exclude= is used on certain filesystems to skip directories that are full of easily recreated data that changes often, like /usr/obj. Yes, the partitions and bootcode must be set up beforehand. After that, it works. Like any disk redundancy scheme, test it before an emergency. > P.P.S. Before anyone asks, no I really _do not_ want to just use RAID > as my one and only backup strategy. RAID is swell if your only problem > is hardware failures. As far as I know however it will not save your > bacon in the event of a fumble fingers "rm -rf *" moment. Only frequent > and routine actual backups can do that. Yes, RAID is not a backup. Another suggestion I've been making often: use sysutils/rsnapshot to make an accessible history of files. The archive go on another partition on the mirror drive, which likely has more space than the original. rsnapshot uses rsync with hard links to make an archive that lets you easily get to old versions of files that have changed in the last few hours/days/weeks/months.