From owner-freebsd-questions@FreeBSD.ORG Tue Jan 20 00:06:03 2015 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ADA00ACE for ; Tue, 20 Jan 2015 00:06:03 +0000 (UTC) Received: from mx01.qsc.de (mx01.qsc.de [213.148.129.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6C933DFE for ; Tue, 20 Jan 2015 00:06:02 +0000 (UTC) Received: from r56.edvax.de (port-92-195-61-84.dynamic.qsc.de [92.195.61.84]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx01.qsc.de (Postfix) with ESMTPS id EF0283CE4A; Tue, 20 Jan 2015 01:05:52 +0100 (CET) Received: from r56.edvax.de (localhost [127.0.0.1]) by r56.edvax.de (8.14.5/8.14.5) with SMTP id t0K05peD002059; Tue, 20 Jan 2015 01:05:51 +0100 (CET) (envelope-from freebsd@edvax.de) Date: Tue, 20 Jan 2015 01:05:51 +0100 From: Polytropon To: Chris Maness Subject: Re: Dump/Restore for system migration Message-Id: <20150120010551.c17d9f50.freebsd@edvax.de> In-Reply-To: References: Reply-To: Polytropon Organization: EDVAX X-Mailer: Sylpheed 3.1.1 (GTK+ 2.24.5; i386-portbld-freebsd8.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "freebsd-questions@freebsd.org" X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 00:06:03 -0000 On Mon, 19 Jan 2015 10:50:28 -0800, Chris Maness wrote: > I have used dump/restore for system migration a couple of time and noticed > it is pretty good, but every once in a while it will miss or corrupt a > file. There is a reason for this. Are you dumping from a live file system? If you can accept filesystem downtime, dump unmounted filesystems. For filesystems which support the use of snapshots, -L can be used. Note that journaled file systems (SU+J) currently doesn't have that feature. A common command line is # dump -0Lauf - | (cd && restore -rf -) where the SOURCE is the device name which you dump from, and TARGET the mounted directory you restore to. And have a look at this excellent advice: http://www.wonkity.com/~wblock/docs/html/backup.html You can see further options there. It's also worth having read "man dump" and "man restore" for understanding the options in use here. > Is there a better way to do this? Usually not, because dump + restore is _the_ way to do it. Except of course you're using ZFS. :-) > I would imagine having a system > mounted r/o would help, but this is not always possible. This is where -L is useful: Instead of dumping the actual file system, a snapshot, "fixed in time" of invocation, will be dumped. It's usually considered to be safe, but personally I believe in the immutability of the dumped data, so mounting ro or not mounting at all will steer you away from any doubts. > Is there a way to > check the deltas between systems manually after migration to see if any > files need to be merged or copied. There are tools to get checksums of the sources and targets, and then compare them. But this is an _additional_ step. > I would imagine the files that are in > jeopardy are ones that are being written to while the dump is taking > place. Correct, that's the danger, because dump simply isn't designed to read data that's changing, and restore isn't designed to create consistent copies of something that's changing. How could that even work?! :-) Again, use -L to prevent this, and know the corner case where -L does _not_ work. > I had a file the keeps track of rss feeds end up missing on the > target system. Obtain it manually from the source. You could even run a cpdup (in ports) session to get all the files that have changed since the dump + restore session, which again somehow defeats the purpose of dump + restore... :-) -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...