copying just / (not /tmp, /usr, etc) (rsync -x failed)
jerrymc at msu.edu
Fri Dec 7 12:18:14 PST 2007
On Wed, Dec 05, 2007 at 10:10:20AM -0700, James Harrison wrote:
> On Wed, 2007-12-05 at 10:41 -0500, Jerry McAllister wrote:
> > On Tue, Dec 04, 2007 at 05:38:20PM -0700, Steve Franks wrote:
> > > I have / on one slice, and [usr,tmp,var] on others. I want to move
> > > just / to a new disk, which seemed to be what rsync -x ("do not cross
> > > filesystems") was intended for. It failed, however, as df shows 20k
> > > blocks in /, and rsync filled up the target slice with 50k blocks, so
> > > obviously it blew right past the 'end' of / - did I miss something? Is
> > > there no other way except to umount [tmp,usr,var]?
> > I would use dump/restore.
> > Build the filesystem in the new disk partition with fdisk, bsdlabel
> > and newfs as needed. Then mount the new partition somewhere -
> > example:
> > mkdir /newpart
> > mount /dev/ad1s1a /newpart
> > (presuming new disk is ad1, slice is 1, partition is a)
> > Doesn't hurt to do an fsck on it here before writing to it, but it
> > probably isn't really needed.
> > Then, run the dump/restore
> > cd /newpart
> > dump 0af - / | restore -rf -
> > This will get all of / as you want. The other mountpoints for /tmp, /usr
> > and /var will be copied, but not the contents of those filesystems. You
> > probably want that.
> > ////jerry
> > >
> > > Thanks,
> > > Steve
> Everyone's recommending dump/restore for copying file systems, and
> there's something that I've never really been clear on.
The advantage of dump/restore is that it will handle all file situations
correctly. Most of the other copy schemes miss on something, such as
hard links. It is easy to use.
> The nice thing about rsync is that it's network aware. Can dump dump a
> file system across a network?
Rsync is OK, especially if you want to set up something for a regular
scheduled copy/update, but may be too much for making a single copy.
More information about the freebsd-questions