Backup Options For FreeBSD

One of the nice usability features of FreeBSD is that ctrl-T sends a SIGINFO to the controlling process. With dump, this means you can press ctrl-T and get a "percent completed" report. That report will also be printed automatically every five minutes, if you’re the patient sort.

Giving dump a larger cache with the -C option can help speed things up. Be a little cautious: since dump forks multiple processes, the cache size will be used multiple times. If you overcommit memory and the computer starts to swap, the dump will change from "annoyingly slow" to "glacially agonizing". The dump(8) man page recommends 8 to 32 megabytes. It also recommends always using -C when the -L snapshot option is used.

-b64 is also used to increase buffer size and improve performance.

Directories to be skipped in a dump can be marked with the nodump flag:

Because the Ports Collection is easy to recreate and often contains large distfiles, it’s a prime candidate to skip in backups. (On computers with poor net access where those distfiles are hard to download, you might want to back it up; as always, it depends on your situation.)

Other large directories with easy-to-recreate or unnecessary data could include /usr/src and various types of cache, like web browser cache or the files created by devel/ccache.

restore has many useful options, including the ability to interactively choose individual files for restoration. Here, we’ll only show restoring a whole filesystem, but please see the restore(8) man page.

Back up a single system to an external hard drive. The external hard drive is UFS-formatted, so file size limits are not a problem.

The external drive is mounted at /mnt, then the /, /var, and /usr filesystems are dumped to files on it.

Restoring this backup is also pretty simple. This example restores the /var filesystem into a temporary directory. This is the type of restore used when you’re looking for some files that were accidentally deleted. If you were restoring a whole system, you’d restore the data over the filesystem where it originated.

See the restore(8) man page for the -i option, which provides a shell-like interactive session for selecting files and directories to restore.

Like the previous example, but dump output is piped through gzip, creating compressed dump files.

gzcat is used to decompress these files for restoration. This example restores to a temporary directory so the backed-up directories and files are available but don’t overwrite the current files.

ssh allows dump to send files to another system on the network, which is very handy, at least if you have more than one system.

otherhost is the system receiving the backup files, and user is the username on that other system. As before, gzip compresses the files, but then ssh logs in to the other system and copies the input into a file in the user’s home directory with dd.

Backup speeds may be slower than to a directly-connected disk. dump and ssh prompts are mixed together, which can be confusing when ssh is waiting for a password. But the convenience of this method sometimes makes a FreeBSD notebook or netbook a better "backup device" than a simple external hard disk.

Restoring these files is a reversal of the dump command line:

Depending on the speed of the computers and the network, it may be faster to run the dump or restore on one computer and the compression on the other. For example, a restore that sends the compressed dump file over the network and decompresses it on the destination computer:

There are many possible variations. Networks and computers vary so widely that only testing will show what is effective on a particular system.

Filesystems can be copied directly from one disk to another by piping the output of dump right into restore. Source and target filesystems don’t have to be the same size, the target just needs to be large enough to hold all the data in the source.

This example copies a running FreeBSD system onto a new drive. Slices and partitions have already been set up on the new disk, da0. The target is the first slice, with a traditional FreeBSD partition layout: a is /, d is /var, e is /tmp, and f is /usr. See Disk Setup On FreeBSD for background.

/var and / are copied last. They are smaller and may have changed during the copy of the much-larger /usr filesystem.

It is possible to restore over a live system. For example, if a hard drive dies, do a minimal FreeBSD install on a new hard drive, then boot that system and restore the /usr, /var, and then / filesystems. I suggest that order because continuing to run after overwriting important data in / is probably something to avoid. After the restore and a reboot, doing a full buildworld/kernel/installworld cycle is a good idea, to make sure the whole system is consistent.

The New Huge Disk section of the FreeBSD FAQ shows a different technique for a similar operation.

Copy drive ad0 to ad4. ad0 is your source drive, right? And you’re positive about that, right? The drive numbers didn’t change after adding the second drive? Okay…

Setting the bs (block size) parameter to 64k will buffer the reads and writes and speed up the copy. Why not an even larger buffer? Because a larger buffer won’t speed up a typical drive. If you have a RAID setup or something faster than typical SATA or IDE, a larger buffer might be useful.

A lot of space on the average disk is empty, but the blocks still have old data in them. That random old data doesn’t compress well if you dd that drive into an image file. You can improve the situation by filling all unused space with zeros. The brute-force method—and dd is nothing if not brute force—is to just build a file full of zeros until you completely fill the disk. Then delete the file.

Unused space on the drive is now mostly compressible zeros.

While the image file is smaller, restoring it will still require a drive at least as large as the original.