Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 15 Oct 2009 03:52:49 +0200
From:      Polytropon <freebsd@edvax.de>
To:        PJ <af.gourmet@videotron.ca>
Cc:        Manolis Kiagias <sonicy@otenet.gr>, freebsd-questions@freebsd.org
Subject:   Re: clone-dump-restore
Message-ID:  <20091015035249.785abc2e.freebsd@edvax.de>
In-Reply-To: <4AD67B06.9090408@videotron.ca>
References:  <4AD640F5.20303@videotron.ca> <20091015000740.53ccdd0a.freebsd@edvax.de> <4AD67B06.9090408@videotron.ca>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 14 Oct 2009 21:29:42 -0400, PJ <af.gourmet@videotron.ca> wrote:
> I believe that my problems arise out of subliminal refuse syndrome: the
> brain refuses to comprehend dump and restore TOs and FROMs.
> In other words, I'm beginning to see that
> dump -0af TO ( - or device/file) FROM (device or directory/file)
> and
> restore -rf  (TO curr.dir FROM device or file) 
> 
> or
> dump -0af  - (FROM device or file) | restore  -rf - (TO device or directory)
> 
> or do I still not have it right?

Not entirely. Let me give this little "cheat sheet":

	# dump -0 -a -f <dumpfile> <source-device>
	if <dumpfile> is -, then write to standard output

	# cd <target-directory>
	# restore -r -f <dumpfile>
	if <dumpfile> is -, then read to standard input

	and combined:
	# cd <target-directory>
	# dump -0 -a -f - <source-device> | restore -r -f -

A common command line parametron for dump -0Lauf ("Lauf"
means "(the) run" or imperative "run!" in German, so it's
easy to remember, "Null-Lauf!" or "Zero Lauf"). Check
the manpage at "man dump" for the meaning of the different
options which are often used for some welcome "side effects".

And now: Lauf! Lauf! Lauf! :-)



> It's the stdout and stdin that makes me stumble.

It's quite easy if you recognize what stdin and stdout are.
One program (dump) outputs to stdout, the | (pipe) method
redirects this stdout of one program to another program to
which it is the stdin, so this other program (restore) reads
the stdin.



> Do I really need to mount the partitions or can I just dump and restore
> from device to device directly?

No. For direct full device operations, you would need dd.

The reason is that dump reads from a partition. This partition
should be unmounted, but may be mounted if you specify -L in
order to tell dump that it will dump a live file system and
should therefore create a snapshot, because it simply cannot
dump data that is constantly changing. The restore program
reads dump files and creates directories and files (with all
the stuff like owner:group, permissions and flags), so it has
to operate on a mounted file system.

That's why the rule: source not mounted or -L, destination
mounted and writable (and empty).

The dd program operates on blocks of variable size. It has no
concept of files and directories. It should not be used on
mounted partitions. Unlike dump | restore, dd allows you to
duplicate disks fulwise, this means you don't even have to 
care for slices and partitions. This method is very often used
in forensic settings where you need to duplicate a whole disk.
But you can, if needed, just dd a whole (at file level defective)
partition, as I had to do. The dd program does not care for
such problems. There are "extended dd variants" that can cope
with massive reading errors if the source drive is already
physically failing.



> The manual says I should be able to dump & restore across the lan too...

Yes, that's easy. For example, you can use ssh to connect to
another machine where you get the dump files from. The handbook
even lists an example, if I remember correctly. In such a
setting, you usually prepare the target (slice, partition,
format), mount it, connect to the backup server and let
restore take the dump files from there. This process can
even be scripted, so you simply put a CD or an USB stick into
a new computer and let it rock automatically. :-)



-- 
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?20091015035249.785abc2e.freebsd>