Dump/Restore for system migration
freebsd at edvax.de
Tue Jan 20 00:06:03 UTC 2015
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
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:
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
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... :-)
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...
More information about the freebsd-questions