Copying FreeBSD to a different disk

B

balanga

I have a working version of FreeBSD on an SSD disk which for some reason no longer wants to boot. I have checked the disk itself and found no errors. Can I try coping the installation to a different disk? The SSD disk is 150GB and the new disk is 320GB so it should fit.

Should I expect to get away with?

dd if=(first disk) of=(second disk)
 
If the problem is related to your installation itself, I doubt that simply copying it to another disk will be resolutive. Before copying it, I would investigate the boot problem more.
 
SirDice said:
This is more suited: sysutils/clonehdd. Never used it myself and I'm guessing it only supports UFS, not ZFS.
Click to expand...
sysutils/clonehdd is a perl script that utilizes fdisk(8) for slicing and dump(8)/restore(8) for copying the slices. clonehdd makes a lot of assumptions about the structure of the disk to be cloned, and with the advent of the GPT partitioning scheme which became the default with FreeBSD 9.0, these assumptions are most probably wrong.
 
  1. Partition the new disk however you want it to be.
  2. Format the filesystems as needed.
  3. Mount the filesystems to a temp location.
  4. Use sysutils/rsync with the appropriate options to copy all the data from one disk to the other. Be sure to add --exclude=/path/to/temp/mountpoint so you don't end up with a recursive rsync. :)
  5. Use the appropriate gpart(1) commands to install bootcode, if needed.

We've used the above many times at work to migrate to larger harddrives and to clone systems.
 
Compare your source and target disk space used. Without a long and complicated set of options, directories with links like /rescue will balloon with rsync. Use dump(8)/restore(8) for anything with complex system filesystem-type stuff. dump(8) also doesn't cross mounts. Or zfs send/ zfs recv for ZFS.
 
wblock@ said:
Compare your source and target disk space used. Without a long and complicated set of options, directories with links like /rescue will balloon with rsync. Use dump(8)/restore(8) for anything with complex system filesystem-type stuff. dump(8) also doesn't cross mounts. Or zfs send/ zfs recv for ZFS.
Click to expand...

Without a long and complicated set of options, dump/restore would be slow to a crawl.

Use rsync -axAHX /path/to/src/ /path/to/dst/

The option -H takes care for the hard links.
The option -x (small letter x) tells rsync(1) not to cross file systems. So there is no need to exclude mountpoints.

PS:

rsync can be used to clone live filesystems*, while dump/restore takes another dubious option which makes cloning even much more slow**.

* it copies file by file, and of course it won't revisit a changed file system item 'A.something' while it is cloning 'x.anotherthing'.
** because dumping became so extremely slow, I used the -L option only once in my life. Without that, the cloned volume needs to be fixed using fsck_ufs -fy /dev/{devicenode of the cloned volume}
 
My list of options are -axHAXS --delete --fileflags --force-change and it still was not necessarily effective. The nice thing about dump(8) is that it natively understands UFS, while file copy utilities like rsync or sysutils/cpdup do not. The backup options for dump are shown in the article above, but -C2 -b64 -0uanL -h0 -f - are mostly as bad as it gets. Many of those can be left out for a one-time copy, and others just do not exist because of dump's built-in knowledge of UFS.
 
I tend to use tar(1) for this. The nice thing about tar(1) is that it's always available, rsync(1) may not.
tar -C / --one-file-system -cf - * | tar -C /some/new/root -xvf -
ssh user@orig.host tar -C / --one-filesystem -cf - * | tar -C / -xvf - # pull
tar -C / --one-file-system -cf - * | ssh root@some.host tar -C / -xvf - # push
 
I just used rsync to transfer ~1.6T of data from an install backup disk a couple days ago. Took about 5 hours. I then booted into the LiveCD and dumped the unmounted backup partition, piped it through restore(8) to a new 2-disk mirror, and it took about the same amount of time. But in my experience, just dumping an unmounted filesystem to a backup image is exponentially faster than rsync. Having the source filesystem mounted and tacking restore to the end is what slows things down.

So in the particular case of cloning a disk, dump/restore might not be substantially faster than any other method, but I'd definitely say its easier than figuring out which of the 400 rsync flags you need. Plus time estimates you get with dump are nice.
 
To give an alternate, alternate view... yesterday I started a dump/restore on this Minnowboard from a SATA drive to a microSD card in a USB 2.0 card reader. Took forever to really start, then was obviously going to take many hours to complete. When I checked it today, it had crashed during the night, with about 7.5G out of 15G copied. So I used rsync to copy the rest. Which it did, except for the few files in /bin and /sbin with the schg flag set. The current version of rsync gives an error and aborts on those. A couple of years ago, I entered a bug for that and it was fixed, but it came back. sysutils/cpdup might work, but now that little board is busy building -CURRENT.
 
You must log in or register to reply here.
Back
Top