Random Tips & Hints

Monthly Archives: June 2009

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

cd /mnt/usr

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: