Dump/Restore for system migration

[Polytropon]

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, ...