This is useful to keep identical copies of your data on a 2nd disk. It’s NOT a replacement for using RAID1 mirroring – but it can be useful. e.g. you can access data from the previous backup on a per-file basis. You could also use it to mirror a current disk to a new disk to go into a seperate server (disk cloning).
What it is REALLY useful for is to copy your data from a smaller disk to a larger disk – but you should do that offline not live. The examples here are all done using a live filesystem. To do a non-live filesystem, boot into single user mode, mount the old drives as readonly with mount -o ro -a, then mount the new drive as normal and run the same commands to dump/restore.
Ok, so i’m going to assume that you want to dump the /usr filesystem into /mnt/usr (a filesystem mounted on a seperate disk)…
dump -L -0 -f- /usr | restore -r -f-
This will dump ALL files in /usr into /mnt/usr. Status updates are written to the screen every 5 minutes.
As this can be run on a live filesystem, you can run backups during normal operation (although the disk performance hit should be taken into account)
What is really useful is that you can pipe the restore command via ssh to restore to a remote server anywhere on the internet… an example would be…
dump -L -0 -f- /usr | ssh -2 -C -l remoteuser 10.0.0.1 restore -r -f-
That would restore the files into the home directory of ‘remoteuser’ on the remote server.
Sometimes the default formatting options aren’t what you need, so i’ll explain a few of them here.
soft-updates are enabled with the -U option. Soft updates are generally a good idea, but you might run into problems if you enable them on a smaller partition as it can fill up before the system has had time to release free space to the user.
block size, frag size and inode size can be useful to change depending on your intended data usage. A single file will always use a minimum of the block size. If your intended data is likely to be a lot of small files (e.g. a maildir dump disk), then a 64kb block size is insane as a 100byte file will occupy 64kb of disk storage. inodes can be exhausted if your intended data is likely to be a lot of files. e.g. if your disk is likely to contain a few thousand large zip files then you need fewer inodes which frees up space for data.
for a disk that needs a lot of small files, i would go for something like:
newfs -O2 -U -b 4096 -f 512 -i 2048 /dev/da0s1a
for a disk that needs fewer files but generally has large files, you could increase the block and inode size:
newfs -O2 -U -b 65536 -f 8192 -i 65536 /dev/da0s1a
The defaults (at least in FreeBSD 7) are…
newfs -O2 -U -b 16384 -f 2048 -i 2048 /dev/da0s1a
Here’s how to manually partition and format a disk in FreeBSD manually.
I’m going to assume you want to use the entire disk (/dev/da0) in 1 partition and all data on it will be destroyed…
First, lets wipe out any data that might be on it… we’ll destroy the GPT table (if one exists), and blank out the first chunk of the disk to destroy any MBR partition tables that might exist:
gpt destroy /dev/da0
dd if=/dev/zero of=/dev/da0 bs=1m count=128
Now we will create a single (bootable/active) partition spanning the entire disk. You may not want it to be bootable, but it doesn’t hurt anyway so why not:
fdisk -BI /dev/da0
Now we will write a standard (bootable) freebsd disk label to the 1st partition. The standard label has the entire space usable as “a”:
bsdlabel -wB /dev/da0s1
Now we will format it for FreeBSD to use. We will use UFS2 with soft updates…
newfs -O2 -U /dev/da0s1a
Now all you need to do is mount it… e.g. to mount it as /mnt:
mount /dev/da0s1a /mnt
if you want it to mount on every boot, add it to /etc/fstab like this:
/dev/da0s1a /mnt ufs rw 2 2
All done 🙂