# Drive cloning



## ddaley (Mar 12, 2012)

I am looking into the collective wisdom of the FreeBSD forums for advice on keeping my current, primary drive cloned to a secondary drive.  My FreeBSD machine has become my primary work computer and I would like to keep a clone of my current file system.  I have installed a second drive and partitioned it to match my primary drive and have cloned the file systems.  I would like to keep secondary as current as possible.  I issued this for the initial cloning (obviously mounting the secondary partitions under /mnt/<mount point>):


```
#!/usr/local/bin/bash

dump -0 -a -L -f - / | ( cd /mnt/root ; restore ruvf - )
dump -0 -a -L -f - /var | ( cd /mnt/var ; restore ruvf - )
dump -0 -a -L -f - /tmp | ( cd /mnt/tmp ; restore ruvf - )
dump -0 -a -L -f - /usr | ( cd /mnt/usr ; restore ruvf - )
```

I am planning to do this on a regular basis


```
#!/usr/local/bin/bash

dump -1 -a -L -f - / | ( cd /mnt/root ; restore ruvf - )
dump -1 -a -L -f - /var | ( cd /mnt/var ; restore ruvf - )
dump -1 -a -L -f - /tmp | ( cd /mnt/tmp ; restore ruvf - )
dump -1 -a -L -f - /usr | ( cd /mnt/usr ; restore ruvf - )
```

Is this an ok approach?  Is there a better solution?

BTW, I am not interested in RAID.  I want to do the clone when I know that my current system is in good shape (such as prior to upgrading ports or other critical components).

I also only plan to mount the secondary drive when I plan to do the clone.  I don't plan to always have the secondary mounted.


----------



## jb_fvwm2 (Mar 12, 2012)

If you read the manpage for dump, it has a sequence (0 3 2 5 4 ...) I've never had to restore from it, but past about "5" I delete it all before starting anew (otherwise it would run out of space...); OTOH search the forums for --bwlimit; I'd suggest augmenting the dump with an 
	
	



```
/usr# rsync ... ... . /mnt/usr # note the dot denoting the current [FILE]/usr[/FILE] source 
...
(rsync with the bwlimit parameter so you can do other stuff in the meantime)
```
  as it can be easier to restore from for the occaisional lost file or directory.  (Others may post the various other ways...)
[In the example above, you'd probably want a different /mnt than that targeted by your dump files, since rsync would delete the latter probably if they were not present in the source directory]


----------



## wblock@ (Mar 12, 2012)

rsync(1) won't delete files on the target by default.  It might be faster than dump for this.


----------



## ddaley (Mar 12, 2012)

Thanks for the info.  I am going to look into using rsync.  I found this as an example on their site, so I figure this may be a good starting place.  It is almost exactly what I want to do (with the exception of my file systems being named differently).  I don't think I'll use the --delete at first though.


*backup to a spare disk*

_I do local backups on several of my machines using rsync. I have an
extra disk installed that can hold all the contents of the main
disk. I then have a nightly cron job that backs up the main disk to
the backup. This is the script I use on one of those machines._


```
#!/bin/sh

    export PATH=/usr/local/bin:/usr/bin:/bin

    LIST="rootfs usr data data2"

    for d in $LIST; do
	mount /backup/$d
	rsync -ax --exclude fstab --delete /$d/ /backup/$d/
	umount /backup/$d
    done
```


----------



## jb_fvwm2 (Mar 12, 2012)

I use the --bwlimit parameter to decrease rsync's speed; I can browse normally with the 10,000 > 2,000 to-disk crash-avoidance fix (PCI SATA controller would otherwise hang or corrupt the target filesystem... ) and sometimes also to-USB. (The long line, which includes another fix for another issue, I've posted in other threads (maybe several times) ).


----------



## ctengel (Mar 12, 2012)

jb_fvwm2 said:
			
		

> I use the --bwlimit parameter to decrease rsync's speed; I can browse normally with the 10,000 > 2,000 to-disk crash-avoidance fix (PCI SATA controller would otherwise hang or corrupt the target filesystem... ) and sometimes also to-USB. (The long line, which includes another fix for another issue, I've posted in other threads (maybe several times) ).



Can you elaborate on the SATA controller hanging and the fix you did, or point me to those threads?  I think I may be having something similar. (Manifested not in rsync() but in tar().)


----------



## jb_fvwm2 (Mar 13, 2012)

simply search (the toolbar at the top of the forum page) "bwlimit", I see upwards of ten or so threads...


----------



## wblock@ (Mar 13, 2012)

Use the -H option so rsync(1) preserves hard links and the copy doesn't get bigger.


----------



## jb_fvwm2 (Mar 13, 2012)

ctengel said:
			
		

> Can you elaborate on the SATA controller hanging and the fix you did, or point me to those threads?  I think I may be having something similar. (Manifested not in rsync() but in tar().)



Not an exact elaboration (see the search results), but I use currently the following code to copy files to a USB (ufs) filesystem so that the copy doesn't hang, resulting in forced shutdown and a 
	
	



```
fsck_ffs /dev/da0
```
 of the usb stick...

```
for f in $(gnuls *.tbz -1); do (cp -v "$f" /mnt/All && sleep 2); done
```
which works super copying multiple large files (vs rsync/bwlimit for huge folders, for example)


----------



## Chris_H (Mar 25, 2012)

Greetings,
 Why not
[CMD=""]dd if=/dev/da0s1 of=/dev/da1s1[/CMD]
Much faster than other options, and could be easily run from a nightly cron(8) job (when you're sure you'll be asleep, of course).


----------



## wblock@ (Mar 25, 2012)

Chris_H said:
			
		

> Greetings,
> Why not
> [CMD=""]dd if=/dev/da0s1 of=/dev/da1s1[/CMD]
> Much faster than other options,



Buffering with bs=64k will help, but it still copies every block of the first partition, whether the filesystem has data on it or not.  dump(8) will only copy used blocks.  rsync(1) copies even less, just files that are different, and will go much faster after the first time.


----------



## Chris_H (Mar 26, 2012)

D'OH! Great points!
My bad. :r


----------

