Backing Up FreeBSD using tar

Linh Pham []

This article was originally submitted in December 2002 for an issue of the Dæmon News Print Magazine. This is a cleaned-up version of the article with minor style edits and made it HTML5 compliant; else, the content has not been changed.

Although FreeBSD is known for it's reliability and stability, there is always a chance that files or directories can get accidentally deleted or corrupted (be it running rm -R .* on accident, a failed make world, or a filesystem corrupted beyond repair). It is always important to backup critical application files, logs and configuration files on a regular basis, preferrably on to something that isn't located on the same system. In this article, I will go over the basics of using the tar utility to backup and restore data, as well as tips on copying the tar files to a remote share on a Windows/Samba server via smbfs.

There are other utilities that can be used to backup and restore data under FreeBSD, including dump, restore, pax and AMANDA, but I will not be discussing those tools in this article.

Backing Up Data

The tar utility, which stands for tape archiver, allows you to archive and restore files and directories to/from a single file or a tape. By default, tar will look at the $TAPE environment variable to see which tape device it will use; if the variable is not set, then it will default to /dev/sa0 (which is a SCSI sequential access tape drive). If you have a tape drive that you would like to tar to use, that isn't /dev/sa0, you will need to set the $TAPE in your login script or the script that you will use to run the backup. To find out the tape device name for your tape drive, check out the contents of /var/run/dmesg.boot.

Another little bit about tape drive devices is that not only is there just the main tape drive device, but also two additional devices for the tape device that are used to determine how the tape drive behaves. When the main device node (or sa0 for most SCSI tape drives) is used, the tape will rewind when it is done. If you use the device node prefixed with a `n' (or nsa0 for a SCSI drive), the tape will not be rewounded when the archive process is done. If you use the device node is prefixed with an "e" (or esa0 for a SCSI drive), the tape will be ejected when the process is done, only if the drive is capable of that. Most of the time, the base device node and the tape drive node prefixed with an "e" should do you find. For more information about the different device node types can be found in the device's manual page.

To backup data using tar to a tape drive, use the following command syntax to backup files (you must be root, or part of the operator group, in order to read from or write to a tape drive):

	tar c files ...

where files ... is a list of files and/or directories that you want to backup to tape. If you want to use a different tape drive than what is set in $TAPE, you can supply an additional flag to the tar command as shown below:

	tar cf /dev/ast1 files ...

You can replace /dev/ast1 (which refers to a second IDE tape drive in a system) with the tape device you want to use. If you do not have a tape drive (or want to create a tar file, a.k.a. a tarball), you can use the command above, just replace the tape device with either a filename ending in .tar or a full path where you want to create a tarball. The following example tells tar to create a tarball, /u02/backup/etc.tar, from the contents of /etc:

	tar cf /u02/backup/etc.tar /etc

If one or more of the files you want to create a tarball starts with a /, tar will display the following message:

	tar: Removing leading `/' from member names

The reason why tar removes the beginning slash is key when you restore files from the resulting archive or tarball. Say you want created a tarball containing the contents of /var/log and want to restore it on a different server, if the beginning slash was there, tar would overwrite the existing files under /var/log with the contents of the tarball. Instead, without the beginning slash, tar would extract the files to the current directory, leaving the contents of /var/log alone.

You can also tell tar to compress the resulting archive or tarball using either gzip or bzip2 compression by using either the "z" or the "j" flags respectively. Depending on the type of files you are archiving, the compression ratio can be fairly high or very low. Compressing the archive might allow you to squeeze more data onto a tape or a disk, but also keep in mind that using either of the two compression tar flags will use up more processing power than without using compression.

Additional tar Flags

In addition to the "c", "f" and the compression flags, there are a couple of other flags that can provide to be quite useful. Below is a brief look at the more common ones; for a more in-depth look at the flags and options available for tar, please check out the manual page for tar(1).

Lists the file on a tape archive or in a tarball (when used before the "f" flag).

After you backup files or create a tarball, you can run tar with the "d" flag to compare the files in the archive with the files on the system. Without the "v" flag below, tar will only display messages if files do not match (which can be expected when comparing log files or mailboxes).

It is critical that you test your backups on a regular basis to make sure that you can restore the data if/when you lose data on the system.

Append files to an archive or tarball (according to the manual page, this option will not work with QIC, or Quarter-Inch Cartridge, tapes).
Append files to an archive if the listed files have been updated since they were included in the archive or tarball (this option also does not work with QIC tapes).
This flag makes tar print out the files that are being backed up, extracted, or compared.
When using this flag, tar will not strip the beginning slash from the filenames that are being archived. Use this flag with the utmost caution as this can come back to bite you in the future!
If the destination files and/or directories, along with the destination tarball, exists, unlink the destination file (which in essence deletes the file pointer) and writes out the destination file.

The tar flags, like for many other utilities and applications, are case sensitive, so "P" will tell tar to act differently then "p".

Backing Up Data to Another Server via smbfs

In some corporate networks, there are specific servers that handle backing up Windows servers and shares but are unable to work natively with FreeBSD without installing Samba and a fair amount of tweaking. Instead, you can use tar in conjunction with smbfs (which allows you to mount to Windows/Samba file shares from within FreeBSD) to create tarballs onto Windows shares that are routinely backed up.

Starting with FreeBSD 4.4-RELEASE, smbfs was integrated into the kernel, which allows one to mount Windows shares without the need of first installing the net/smbfs port. To mount an Windows share onto a FreeBSD machine, you would run the following command as root:

	mount_smbfs [-W WORKGROUP] //user@server/share /mount/point

If you are in a Windows NT domain environment, you will need to include the "-W" flag and replace WORKGROUP with the name of the NT domain. One thing to watch out for is that the server value will only accept hostnames under a certain length. Instead of using a fully-qualified domain name for server, use the "-I" flag along with the full hostname and use the Windows name of the server in place of server.

Once the machine has created a connection to the Windows machine, it will then prompt for a password; if it accepts the password and no errors come up, you should be able to browse to /mount/point and work with the files and directories as if it were any other files and directories on the local machine. You can also supply additional options on how it handles permissions and ownership. More information on those options can be found in mount_smbfs(8).

To backup files from the local machine to a tarball located on the mounted Windows share, all you need to do is specify the path where you want to stick the tarball. For example, to backup /etc to a directory called fbsd_backup on the Windows share, run the following as root:

	tar cf /mount/point/fbsd_backup /etc

When you are done with the mounted share, use the umount command to unmount the share and the mount point. To unmount the share used in the above examples, run the following command as root (also make sure that noone including yourself are not using files in that share nor are sitting somewhere within the mount point):

	umount /mount/point

To mount and use a Windows share in a shell script without being prompted for a password, you can create a file called .nsmbrc, place it into the home directory of the user doing the backup (which could be root or another user), and make sure to change the permissions on the file so that only the owner can read and write to the file (this can be done by running "chmod go-rw .nsmbrc"). The file's content should look something like:




One thing to keep in mind when replacing the values italicized above is that the values are case-sensitive and that WORKGROUP, SERVER, and USERNAME have to be in upper-case letters. The password needs to be in plain-text, which makes it even more important to restrict who can read the contents of the .nsmbrc file. The addr setting is used to associate a full hostname for the server so that you won't have to update /etc/hosts nor supply it along with the `-I' flag when running mount_smbfs. These settings can also be stored in /etc/nsmb.conf and the file should also be set so that the root user is the only user capable of viewing the contents of the file (along with being able to write to the file). By storing the workgroup name and password in the .nsmbrc, you can shrink down the length of the command to mount a share and suppress the need to enter a password (a huge must when automating backups).

Automating Your Backups

Once you've decided what you would like to backup on a regular basis, now it's time to automate the process so that you won't have to manually (or forget) to do it. One way to automate the backup process is to create a shell script that contains the commands that handle the backups, add it to crontab, and let it go.

If you will be backing up data using a tape drive, you will need to figure out how much data you have to backup and how much data you can fit onto a single tape. To find out how much data you need to backup, use the du command along with the "-h" flag to get more human readable results. You can shrink down the size of the backup by enabling compression, but it may not have a lot of affect if you are backing up pre-compressed files (such as: gzipped tarballs, GIF or JPEG images and binary files). If you still cannot fit a full backup onto a single tape, you may want to modify what you backup and when to schedule the next set so that you can swap out the tapes.

If you will be backing up data out to the same tarball each time, you may want to take a look at the "U" tar flag as mentioned towards the beginning of this article. This will reduce the need to delete the destination tarball before you start the tar process.

Once you have figured out how you will handle splitting up the files and/or directories to backup (if necessary), the next step is to create a shell script that will handle the backup for you. Below is an example C shell script that backs up the most critical files on a server to a SCSI tape drive (but ejects the tape for off-site storage when done), then creates a bzip2-compressed tarball of just the system logs out to a to-be mounted Windows/Samba share, and finally unmounts the share.

	# backing up files

	tar cf /dev/esa0 /etc /var /usr/local/etc /home >& /dev/null
	mount_smbfs //backup@file2/bsdbackup /mnt/bsdbackup
	tar Ujcf /mnt/bsdbackup/syslogs.tar.bz2 /var/log >& /dev/null
	umount /mnt/bsdbackup

The italicized portions of the script above redirect tar's warning of, "tar: Removing leading `/' from member names" to /dev/null rather than returning it to the standard output (which is syslog if you will be running this script via cron); though you may want to omit it when testing out the script to make sure that it works. Also make sure that you enable the execute bit on the script by using "chmod +x script" where script is the path and/or filename of the backup script.

The final step is to add the tested and working script to root's crontab (root is required if you are planning on mounting and unmounting Windows/Samba shares) by using the "crontab -e" command. The following shows that the backup script at /u01/scripts/backupServer running everyday at 4:00 AM.

	# run the backup server script at 4:00 everyday
	00	04	*	*	*	/u01/scripts/backupServer

You will need to modify the time and path of the shell script to match what you have decided upon. Save and exit out of the editor, and let the scheduled script run through once. Once it has been executed, check out syslog to see if any fatal errors occurred. If everything is okay, you should be all set to go, but always keep an eye out on syslog just to make sure everything is running and doesn't require any attention.

Restoring Data

Getting data out of a tar archive (be it from a tape or a tarball) is about as easy as backing up the files. To restore an uncompressed tar archive, you would replace the "c" flag with the "x" flag. For example, to extract the entire contents of the archive (from the tape in /dev/sa0 or the drive set in $TAPE) into the current directory, just run the following command (again, either as root or a user that is part of the operator group):

	tar x

To selectively extract files from an archive, all you will need to do is list the files after the "x" flag in the command. For example, to extract only /etc/rc.conf and /etc/sysctl.conf from the archive to the current directory, run:

	tar x etc/rc.conf etc/sysctl.conf

If you have used either of the compression flags ("z" for gzip or "j" for bzip2) when creating the archive that you also include it in the command, like:

	tar jxf /u02/backup/etc.tar.bz2 etc/rc.conf etc/sysctl.conf

Remember that the paths stored in the archive is relative to where the archive was created (or relative to the root directory if you had included the beginning slash in list of the files or directories to include in the archive; unless if you included the "P" flag in the tar archive command). If you created an archive using the "P" flag, use the "P" flag to remove the beginning slash from the filenames when they are being extracted.

To restore data from a tarball located on a Windows/Samba file share, just follow the steps above but make sure that you mount the file share which the tarball is located before running tar.


Using tar to backup a FreeBSD system is a great and fairly simple way to get one of the most important task of a system administration done. There are a handful of gotchas when it comes to using tar and working with smbfs. Once you work with it enough and get familiar with it, it will become second nature to you. Remember that you should get into the habit of backing up your system on a regular basis and making sure that you test your backups to make sure that you can restore from them. Also if you are backing up to tapes, make sure that you rotate your tapes as well as clean the tape drive on a regular basis (per the tape manufacturer's requirements) to insure that the backups are in as tip-top shape as possible.

Article copyright © 2002–2010 Linh Pham. All rights reserved. Re-production of portions of this work, or its entirety, requires permission of the copyright holder.