Bug 21443

Summary:	I'm tired of telling people how to copy a disk.
Product:	Documentation	Reporter:	mwm
Component:	Books & Articles	Assignee:	freebsd-doc (Nobody) <doc>
Status:	Closed FIXED
Severity:	Affects Only Me
Priority:	Normal
Version:	Latest
Hardware:	Any
OS:	Any

Description mwm 2000-09-21 08:40:00 UTC

	Seems like we daily (ok, but more than once a week) get
	someone asking "I just put on <whopping big new disk>, how do
	I move my data to it?

Fix: 

Add this to the FAQ, under the "System Administration" section:

Q: How do I move my system over to my huge new disk?

A: The best way is to reinstall the OS on the new disk, then move the
user data over. This is highly recommended if you've been tracking
-stable for more than one release, or have updated a release instead
of installing a new one. You can install booteasy on both disks with
boot0cfg(8), and dual boot them until you are happy with the new
configuration. Skip the next paragraph to find out how to move the
data after doing this.

Should you decide not to do a fresh install, you need to partition and
label the new disk with either /stand/sysinstall, or fdisk(8) and
disklabel(8). You should also install booteasy on both disks with
boot0cfg(8), so that you can dual boot to the old or new system after
the copying is done. See the formatting-media tutorial at <URL:
http://www.freebsd.org/tutorials/formatting-media/index.html > for
details on this process.

Now you've got the new disk set up, and are ready to move the
data. Unfortunately, you can't just blindly copy the data. Things like
device files (in /dev) and symbolic links tend to screw that up. You
need to use tools that understand these things, which means dump(8)
and tar(1). I recommend doing the data moves in single user mode, but
it's not required.

You should never use anything but dump(8) and restore(8) to move the
root file system. Tar(1) may work - then again, it may not. You should
also use dump(8) and restore(8) if you are moving a single partition
to another empty partition. The sequence of steps to use dump to move
a partitions data to a new partition is:

	1. newfs the new partition.
	2. mount it on a temporary mount point
	3. cd to that directory
	4. dump the old partition, piping output to the new one

For example, if you are going to move root to /dev/ad1s1a, with /mnt
as the temporary mount point, it's:

	# newfs /dev/ad1s1a
	# mount /dev/ad1s1a
	# cd /mnt
	# dump 0uaf - / | restore xf -


If you are going to rearrange your partitions - say, splitting one
into two, or combing two into one, you may find yourself needing to
move everything under a subdirectory to a new location. Since dump(8)
works with file systems, it can't do this. So you use tar(8). The
general command to move /old to /new for tar is:

	(cd /old; tar cf - .) | (cd /new; tar xpf -)

If /old has file systems mounted on that, and you don't want to move
that data or unmount them, you just add the 'l' flag to the first tar:

	(cd /old; tar clf - .) | (cd /new; tar xpf -).
How-To-Repeat: 
	Read -questions, and answer them for a while (and if you
	aren't doing that, why aren't you?)

Comment 1 Oliver Fromme 2000-09-21 11:00:29 UTC

For what it's worth, cpdup works perfectly fine to copy a
disk (or any directory tree), even the root FS.  It's easier
to use and more efficient than dump/restore, and it's not
restricted to whole file systems.  Therefore I'd suggest
mentioning cpdup in this FAQ section (unfortunately I'm not
a native English speaker, otherwise I'd try to formulate
an appropriate paragraph myself).

cpdup is in the ports collection in the sysutils category
(I really wish it was in the base system).

Best regards
   Oliver Fromme

-- 
Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.

"All that we see or seem is just a dream within a dream" (E. A. Poe)

Comment 2 mwm 2000-09-21 11:27:46 UTC

Oliver Fromme writes:
> 
> For what it's worth, cpdup works perfectly fine to copy a
> disk (or any directory tree), even the root FS.  It's easier
> to use and more efficient than dump/restore, and it's not
> restricted to whole file systems.  Therefore I'd suggest
> mentioning cpdup in this FAQ section (unfortunately I'm not
> a native English speaker, otherwise I'd try to formulate
> an appropriate paragraph myself).
> 
> cpdup is in the ports collection in the sysutils category
> (I really wish it was in the base system).

Since I don't use it, I'm not really willing to recommend it myself
(ditto for pax and cpio). For a number of reasons, I won't recommend
using it on the root fs.

So how about adding a sentence along the lines of "You might prefer
cpio(1), pax(1) or cpdup (in ports/sysutils/cpdup) to tar." at the
appropiate point?

	<mike

Comment 3 ben freebsd_committer

2000-09-21 13:25:56 UTC

mwm@mired.org wrote:

> Q: How do I move my system over to my huge new disk?

*grumble*

It would be really nice if you could send this as an SGML diff to the
FAQ, with correct indentation and everything. ("correct" means what the
FDP Primer says, not what most of the FAQ is.  Some of the questions in
the FAQ are correct though, mostly the recent additions.)

But if you don't have time to do that, I'm sure a doc/ committer will
get around to it.  Mark, are you there? :-)

-- 
Ben Smithurst / ben@FreeBSD.org / PGP: 0x99392F7D

Comment 4 Oliver Fromme 2000-09-21 13:59:54 UTC

Mike Meyer wrote:
 > Since I don't use it, I'm not really willing to recommend it myself
 > (ditto for pax and cpio). For a number of reasons, I won't recommend
 > using it on the root fs.

I'd suggest that you have a look at the manual page.  The tool was
written by Matt Dillon and Dima Ruban specifically for making an
_exact_ copy of a UFS directory tree or file system, including all
hardlinks, softlinks, devicenodes, sockets etc., preserving flags,
permissions and utimes.

I'm not aware of any reason not to use it for the root FS.

 > So how about adding a sentence along the lines of "You might prefer
 > cpio(1), pax(1) or cpdup (in ports/sysutils/cpdup) to tar." at the
 > appropiate point?

That would be OK.

Thanks
   Oliver

-- 
Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.

"All that we see or seem is just a dream within a dream" (E. A. Poe)

Comment 5 mwm 2000-09-22 00:22:00 UTC

Ben Smithurst writes:
> mwm@mired.org wrote:
> > Q: How do I move my system over to my huge new disk?
> *grumble*
> 
> It would be really nice if you could send this as an SGML diff to the
> FAQ, with correct indentation and everything. ("correct" means what the
> FDP Primer says, not what most of the FAQ is.  Some of the questions in
> the FAQ are correct though, mostly the recent additions.)

SGML is great stuff, and I use it all the time. However, when I asked
on docs for information on submitting a new FAQ, I got told "just send
a PR". I couldn't find anything obvious on how to do it in SGML, other
than instructions for joining the doc project. That was distinctly
overkill for adding a single FAQ entry; especially when compared to
things like the Python FAQ Wizard.

So - give me a pointers to a DTD I can install for psgml to use and
the primer for formatting, as well as a place to grab the source for
just the FAQ, and I'll mark up my text, add it and send a diff.

	<mike

Comment 6 mwm 2000-09-22 01:12:39 UTC

Oliver Fromme writes:
> Mike Meyer wrote:
>  > Since I don't use it, I'm not really willing to recommend it myself
>  > (ditto for pax and cpio). For a number of reasons, I won't recommend
>  > using it on the root fs.
> I'd suggest that you have a look at the manual page.  The tool was
> written by Matt Dillon and Dima Ruban specifically for making an
> _exact_ copy of a UFS directory tree or file system, including all
> hardlinks, softlinks, devicenodes, sockets etc., preserving flags,
> permissions and utimes.

Oh, I believe it's good stuff. I've worked with both of them before,
and know what they can do. However, much more than a pointer in a FAQ
entry seems wrong something in the ports tree.

> I'm not aware of any reason not to use it for the root FS.

The odd stuff in /dev is why the root file system gets special
treatment. While other things can handle them, they do change at
times. That's why my personal preference is to use dump, which is
tightly coupled to the fs structure. I feel it's less likely to be
overlooked when these things change.

However, the real problem is that cpdup is a port. That means that it
isn't automatically updated and rebuilt in the process of doing a make
world. Sometimes, the port doesn't even change - but it needs to be
recompiled. I've been bit by this with cdrecord, but don't have any
alternatives :-(.

	<mike

Comment 7 marko freebsd_committer

2000-09-22 19:41:02 UTC

State Changed
From-To: open->closed

Committed (with the reference to cpio that was missing from the diff). Thanks!!