Date: Tue, 20 Jan 2015 01:05:51 +0100 From: Polytropon <freebsd@edvax.de> To: Chris Maness <chris@chrismaness.com> Cc: "freebsd-questions@freebsd.org" <freebsd-questions@freebsd.org> Subject: Re: Dump/Restore for system migration Message-ID: <20150120010551.c17d9f50.freebsd@edvax.de> In-Reply-To: <CANnsUMESEWsEXyyKwqyrnTMiEEYuExTgD0Z4NBuJF0cYSWDChQ@mail.gmail.com> References: <CANnsUMESEWsEXyyKwqyrnTMiEEYuExTgD0Z4NBuJF0cYSWDChQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 - <SOURCE> | (cd <TARGET> && 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, ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150120010551.c17d9f50.freebsd>