# Copying FreeBSD to a different disk



## balanga (Mar 24, 2016)

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)`


----------



## wblock@ (Mar 24, 2016)

Please don't use dd(1) to copy disks.  It ignores trim on SSDs, blindly copies every block whether used or not, and will result in corrupted GPT partition tables.  Used as shown, it will also copy very slowly.

See Backup Options For FreeBSD.


----------



## SirDice (Mar 24, 2016)

This is more suited: sysutils/clonehdd. Never used it myself and I'm guessing it only supports UFS, not ZFS.


----------



## Maxnix (Mar 24, 2016)

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.


----------



## obsigna (Mar 24, 2016)

SirDice said:


> This is more suited: sysutils/clonehdd. Never used it myself and I'm guessing it only supports UFS, not ZFS.


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.


----------



## phoenix (Mar 24, 2016)

Partition the new disk however you want it to be.
Format the filesystems as needed.
Mount the filesystems to a temp location.
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.  
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.


----------



## wblock@ (Mar 24, 2016)

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.


----------



## obsigna (Mar 25, 2016)

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.



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}`


----------



## wblock@ (Mar 25, 2016)

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.


----------



## chrbr (Mar 25, 2016)

I am happy with dump(8) as well. But I do this in single user mode to be on the safe side. And one should not forget the files which are marked not to be dumped by chflags(1).


----------



## SirDice (Mar 25, 2016)

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


----------



## ANOKNUSA (Mar 27, 2016)

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.


----------



## wblock@ (Mar 27, 2016)

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.


----------



## obsigna (Mar 28, 2016)

wblock@ said:


> ... .  sysutils/cpdup might work, but now that little board is busy building -CURRENT.



sysutils/cpdup does not take care of Extended Attributes and ACL's.


----------

