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.
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/sa0tar to use, that isn't
/dev/sa0$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.
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).
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.
tar print out the files that are being backed up, extracted, or compared.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!
The tar flags, like for many other utilities and applications, are case sensitive, so
"P" will tell tar to act differently then "p".
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:
[default] workgroup=WORKGROUP [SERVER] addr=server.some.domain.com [SERVER:USERNAME] password=password
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).
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.
#!/bin/csh # 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.
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.