BackupPC 配置

数据备份

Overview

This page covers installing and configuring . I've been using BackupPC since early 2004 and have been pretty happy with it.

Overview

This page covers installing and configuring . I've been using BackupPC since early 2004 and have been pretty happy with it.

Preparation

Backups will be stored under /var/lib/backuppc. If you want to have that correspond to a specific partition or disk it's easiest to do it before installing BackupPC. I created an LVM group/volume mounted at that location just for BackupPC data.

Installation

BackupPC requires a version of Apache to be installed. (Other web servers may also work, but you will be on your own.) If you don't have Apache installed then Apache 1.3 will be installed for you. If you want a different version of Apache then install that before installing BackupPC.

apt-get install backuppc libfile-rsyncp-perl

The installation creates a backuppc user. In order to receive emails sent to that account consider creating a .forward in ~backuppc (which is /var/lib/backuppc).

Configuring Apache

If Apache just got freshly installed, consider updating /var/www/index.html.

The installation process creates a backuppc system account and web login. The password for the weblogin should be changed with htpasswd /etc/backuppc/htpasswd backuppc. The password for the system account is already secure and doesn't need changing.

The BackupPC web interface is now accessible at .

Configuring BackupPC

The main config file is /etc/backuppc/config.pl. Very little needs to be changed in this file! Most settings that seem like that might need changing (e.g. backup method) are often best configured on a per-client basis in separate files. I changed the following:

$Conf{FullKeepCnt} = 1;

Changed to $Conf{FullKeepCnt} = [1, 0, 1]; so as to keep a full backup that was approximately one month old in addition to the current one.

$Conf{BlackoutGoodCnt} = 7;

This setting specifies for how many backups in a row a machine has be available to be considered an "always-on" machine. I reduced it to 2. I occasionally (but rarely) turn my machine off at night and don't want one night's outage to cause 7 days of mid-day instead of night-time backups.

$Conf{BlackoutPeriods}

I extend the Blackout to be all hours of every day of the week except for 2:00am to 8:00am.

$Conf{BlackoutPeriods} = [
    {
       hourBegin =>  8,
       hourEnd   =>  2,
       weekDays  => [1, 2, 3, 4, 5, 6, 7],
    },
];

That's it!

Specifying Clients

First add each machine to be backed up to /etc/backuppc/hosts. All my entries look like this:

calvin      0       backuppc

Now create a machinename.pl file for each machine that is to be backed up. A generic config file for a Linux box looks like this:

$Conf{XferMethod} = 'rsync';
$Conf{BackupFilesExclude} = ['/sys', '/proc', '/cdrom', '/dvd', '/floppy'];

As a general rule, don't use trailing slashes when specifying directories to exclude.

Mac OS X

A good set of excludes for Macs are

$Conf{BackupFilesExclude} = ['.Trash', '/Trash', '/automount', '/Network', '/private/var/automount', '/private/var/run', '/private/var/vm', '/private/var/tmp', '/private/tmp', 'Caches', 'CachedMessages'];

Also, if using tar on Mac OS X (which you probably won't, see below) you need to inform BackupPC that the binary is now in the usual /bin/tar location:

$Conf{TarClientPath} = '/usr/bin/tar';

Mac OS presents a problem: Many apps (e.g. Quark, Quicken) store important data in resource forks. But the versions of tar and rsync that ship with Mac OS X only support single-stream files (this may change with Mac OS X 10.4 Tiger).

Aside from ignoring resource forks there are two basic ways to deal with them. One is to use a $Conf{DumpPreUserCmd} (see below) to make single-stream copies of important files containing resource forks by using BinHex or something similar. A better approach is to make either tar or rsync resource-fork aware. Such a resource-fork aware version would simply map dual-stream files into two single-stream files.

The steps to back resource forks up using tar are:

1. Install on the Mac(s) to be backed up.
2. If you're using BackupPC prior to 2.1.1 then on the BackupPC server, in /usr/share/backuppc/bin, apply with the commands

   mv BackupPC_tarExtract BackupPC_tarExtract.orig
   patch -o BackupPC_tarExtract BackupPC_tarExtract.orig BackupPC_tarExtract.diff
   chmod 755 BackupPC_tarExtract

   This patch was written by Craig Barratt himself.
3. In the client config file include the following line:

   $Conf{TarClientPath} = '/usr/bin/xtar';

Currently (2005-01) rsync is not an option. Andrew Reynhout has created a . However the Perl rsync emulator in BackupPC does not (yet) work with it. To install the new rsync just place it in /usr/bin, rename the existing rsync (e.g. to rsync_Apple) and make a symlink named rsync to the new version. Fix up the permissions and you're set.

marshmallow:/usr/bin root# ls -alF | grep rsy
lrwxr-xr-x    1 root  wheel        23 15 Aug 22:56 rsync@ -> rsync-2.6.2+hfsmode-1.1
-rwxr-xr-x    1 root  wheel    625696 15 Aug 22:54 rsync-2.6.2+hfsmode-1.1*
-rwxr-xr-x    1 root  wheel    211860  9 Aug 16:08 rsync_Apple*

Windows

Windows is tricky since you're unlikely to find an SSH server running and rsync or tar binaries handy. The best solution is to install rsyncd on your Windows machines. You can get a simple Windows rsyncd installer from the BackupPC site. See the for more information. The config file for the machine will look like this:

$Conf{XferMethod} = "rsyncd";
$Conf{RsyncdUserName} = "BackupPC";
$Conf{RsyncdPasswd} = "******";
$Conf{RsyncShareName}  = "cDrive";

$Conf{BackupFilesExclude} = ['/winnt/tmp', '/pagefile.sys', '/hiberfil.sys', 'Temporary Internet Files/', '*Cache/', 'Thumbs.db', 'IconCache.db', '~*', 'desktop.ini', 'NTUSER.DAT', 'USRCLASS.DAT', '/RECYCLER', 'Virtual Machines/'];

Alternatively smbclient can be used to access a standard Windows share. Simply replace the rsync config lines with these:

$Conf{XferMethod} = 'smb';
$Conf{SmbShareName} = 'C$';
$Conf{SmbShareUserName} = 'BackupPC';
$Conf{SmbSharePasswd} = '******';

Note that there's a major limitation with this approach: it doesn't let you properly exclude files. You can only specify a single exclude and you don't have full regular expression support. I found that to exclude directory "foobar" I had to use $Conf{BackupFilesExclude} = ['?foobar']; (foobar by itself or anything I could think of using or / didn't work).

The smb approach seem to also require much more RAM than the rsync method. Backing up lots of files with smb has been seen to cause the Linux kernel to start killing random tasks.

If you must use smb you might be better off mounting the remote file system beforehand and then backing up with tar as if it were part of the localhost backup.

Granting Access

Using rsync or tar assumes that the backuppc user on the BackupPC machine has permisison to SSH to the client machine and log in as root without entering a password. See for more information. When complete you should be able to execute sudo -u backuppc ssh root@client on the BackupPC server and get logged in to the client without any password prompt.

Extras

$Conf{DumpPreUserCmd} is a handy way to prepare the client for the backup. I use the following to take a snapshop of my MySQL database before backing up:
$Conf{DumpPreUserCmd} = '$sshPath -l root $host /usr/bin/mysqldump -A -p****** > /var/backups/mysql_snapshot.sql';

Troubleshooting

The is a good resource. The most important thing it mentions it to try running

sudo -u backuppc /usr/share/backuppc/bin/BackupPC_dump -v -f tomato

in order to view the full output of a verbose backup session on the command line.

Error writing to tar file - Connection reset by peer

I got this sometimes with really big (2GB) files stored on a Windows box (smbclient backup method). I ended up just excluding the files.

NT_STATUS_ACCESS_DENIED opening remote file

I was convinced this was BackupPC's fault but actually the permissions were messed up on my Windows box. To fix, go to parent directory, set permissions properly if needed, and explicitly propagate down overwriding sub folders (via Advanced button). Default permissions for a standard folder are:

	Administrators (RIAAdministrators)
		Inherit Allow all except special permissions
	CREATOR OWNER
		Inherit Allow special permissions
	Lorrin (RIALorrin)
		Inherit Allow special permissions
		Note: this gets set to the CREATOR OWNER. So for C:
		it defaults to Everyone instead of a specific user.
	SYSTEM
		Inherit Allow all except special permissions
	Users (RIAUsers)
		Inherit Allow Read & Execute, List Folder Contents, Read, special permissions

Also "Backup Operators" don't have permission to read the user folders inside "Documents and Settings". If you made the BackupPC account a Backup Operator instead of an Administrator and want to back up those folders add a Backup Operators (RIABackup Operators) entry with the permissions to Read & Execute, List Folder Contents, Read.

Endless runs (tons of data)

Make sure you're not inadvertantly backing up mounted remote volumes (note all the excludes for Mac OS X above)

Endless runs (no data)

Perhaps you're getting stalled at

The authenticity of host 'calvin (192.168.123.3)' can't be established.
RSA key fingerprint is 0b:b2:fa:54:64:05:2c:6a:41:e5:1d:e5:4a:f4:a6:8d.
Are you sure you want to continue connecting (yes/no)?

Either manually ssh from backuppc's account to the host to be backed up or manually add the hosts info to ~backuppc/.ssh/known_hosts.

This can also happen if you're accidentally backing up mounted remote volumes that are on a slow WAN and take impossibly long to traverse.

File RsyncP module doesn't exist

Install the libfile-rsyncp-perl package.

fileListReceive failed

This means something went seriously wrong with rsync. Check the client's dmesg - you might be running out of memory. rsync uses quite a bit (hundreds of MB) if you have many files and are doing a full backup. Note to self: make your swap parition bigger next time... I also saw this with a buggy non-release version of rsync.

You'll also see this if you forget to install rsync on the client. :-)

aborted by signal=ALRM

Make sure you're not backing up a folder full of non-file data such as /proc.

Check the $Conf{ClientTimeout} setting; it's meant to be the timeout between signals of life during the backup process but in certain cases acts as a timeout for the entire backup operation. The default is only 7200 seconds (2 hours) and a backup can easily need more time than that.

Also consider breaking the backup into smaller pieces. That requires two steps in the host's .pl file:

1. Define RsyncShareName to have multiple values instead of just /:

   $Conf{RsyncShareName} = ['/', '/var/documents', '/var/media/pictures', '/var/media/music'];

2. Copy the RsyncArgs from config.pl and add the --one-file-system argument to it:

   $Conf{RsyncArgs} = [
               #
               # Do not edit these!
               #
               '--numeric-ids',
               '--perms',
               '--owner',
               '--group',
               '--devices',
               '--links',
               '--times',
               '--block-size=2048',
               '--recursive',
   
               #
               # If you are using a patched client rsync that supports the
               # --checksum-seed option (see ),
               # then uncomment this to enabled rsync checksum cachcing
               #
               #'--checksum-seed=32761',
   
               #
               # Add additional arguments here
               #
               '--one-file-system',
   ];

Restores fail

There are three places to check for details on what went wrong:

• the main LOG file (does it show the restore starting?)
• the per-PC LOG file (does it show the restore running?)
• the RestoreLOG file. It's available by clicking on the restore number on the per-PC summary page, and then clicking on the LOG link.

/usr/bin/xtar:: option requires an argument -- C

This shows in the restore log on a direct restore when the "Restore the files to share" field is left blank (instead of e.g. /) in the web form.

Tar exited with error 256 () status

This happens when the SSH connection fails to open.

"unknown host" error when starting a backup

This can happen if you have added a host to conf/hosts but forgotten to reload the config file.
Attachments: