BackupPC
Installation And Configuration in Debian
What is backupPC ?
BackupPC is a high-performance, enterprise-grade system for
backing up Linux and WinXX PCs and laptops to a server's disk.
BackupPC is highly configurable and easy to install and
maintain.
BackupPC Features
A clever pooling scheme minimizes disk storage and disk I/O.
Identical files across multiple backups of the same or different
PCs are stored only once resulting in substantial savings in
disk storage and disk I/O.
One example of disk use: 95 laptops with each full backup
averaging 3.6GB each, and each incremental averaging about
0.3GB. Storing three weekly full backups and six incremental
backups per laptop is around 1200GB of raw data, but because of
pooling and compression only 150GB is needed.
Optional compression support further reducing disk storage.
Since only new files (not already pooled) need to be compressed,
there is only a modest impact on CPU time.
No client-side software is needed. The standard smb protocol is
used to extract backup data on WinXX clients. On linux clients,
tar over ssh/rsh/nfs is used to backup the data. With version
2.0.0, rsync is also supported on any client that has rsync or
rysncd.
A powerful web (http/cgi) user interface allows administrators
to view log files, configuration, current status and allows
users to initiate and cancel backups and browse and restore
files from backups.
A full set of restore options is supported, including direct
restore (via smbclient, tar, or rsync/rsyncd) or downloading a
zip or tar file.
Supports mobile environments where laptops are only
intermittently connected to the network and have dynamic IP
addresses (DHCP).
Flexible configuration parameters allow multiple backups to be
performed in parallel, specification of which shares to backup,
which directories to backup or not backup, various schedules for
full and incremental backups, schedules for email reminders to
users and so on. Configuration parameters can be set system-wide
or also on a per-PC basis.
Users are sent periodic email reminders if their PC has not
recently been backed up. Email content, timing and policies are
configurable.
Tested on Linux, Freenix and Solaris hosts, and Linux, Win95,
Win98, Win2000 and WinXP clients.
Detailed documentation.
Open Source hosted by SourceForge and freely available under GPL.
BackupPC Download
http://sourceforge.net/projects/backuppc/
BackupPC
Documentation and FAQ
http://backuppc.sourceforge.net/faq/BackupPC.html
BackupPC Installation
in Debian
#aptitude install backuppc rsync libfile-rsync-perl
libfile-rsyncp-perl par2 bzip2
Reading Package Lists... Done
Building Dependency Tree
Reading extended state information
Initializing package states... Done
Reading task descriptions... Done
The following NEW packages will be automatically installed:
libarchive-zip-perl libcompress-zlib-perl perl-suid wwwconfig-common
The following NEW packages will be installed:
backuppc bzip2 libarchive-zip-perl libcompress-zlib-perl
libfile-rsync-perl libfile-rsyncp-perl par2 perl-suid wwwconfig-common
0 packages upgraded, 9 newly installed, 0 to remove and 0 not
upgraded.
Need to get 1049kB of archives. After unpacking 3560kB will be
used.
Writing extended state information... Done
This time it will prompt you for some basic questions answer
them first one may be adding aliases for /backpc folder to your
apache config files this will create you a default web interface
username and password like below
Web administration default user created
BackupPC can be managed through its web interface:
http://localhost.localdomain/backuppc/
For that purpose, a web user named 'backuppc' with 'OE9URkwt' as
password has been created. You can change this password by
running 'htpasswd /etc/backuppc/htpasswd backuppc'.
BackupPC Configuration
BackupPC's main configuration file is found at /etc/backuppc/config.pl.
You should consider this file to contain BackupPC's default
settings, since we will create additional configuration files to
over-ride settings on a per-client basis.
Adding a New Client
Create a client configuration file with the hostname of the
client you want to backup
# vi /etc/backuppc/examplehostname
If you don't find the above file location
check below
/var/lib/backuppc/examplehostname/config.pl
and the best thing would be to put that file as a symlink to
/etc/backuppc/examplehostname in order to manage these config
file in /etc dir (thanks to father Paolo)
You can over-ride almost any default setting on a per host basis
within the host's configuration file, but a typical
configuration would be as follows
# Minimum period in days between full and incremental backups:
$Conf{FullPeriod} = 6.97;
$Conf{IncrPeriod} = 0.97;
# Number of full and incremental backups to keep:
$Conf{FullKeepCnt} = 2;
$Conf{IncrKeepCnt} = 6;
# Note that additional fulls will be kept for as long as is
necessary
# to support remaining incrementals.
# What transport to use backup the client [smb|rsync|rsyncd|tar|archive]:
$Conf{XferMethod} = 'rsync';
# The file system path or the name of the rsyncd module to
backup when
# using rsync/rsyncd:
$Conf{RsyncShareName} = '/';
# If this is defined only these files/paths will be included in
the backup:
$Conf{BackupFilesOnly} = undef;
# These files/paths will be excluded from the backup:
$Conf{BackupFilesExclude} = ['/proc', '/dev', '/cdrom',
'/media', '/floppy', '/mnt', '/var/lib/backuppc', '/lost+found'];
# Level of verbosity in Xfer log files:
$Conf{XferLogLevel} = 1;
# Commands to run for client backups:
# Note the use of SSH's -C attribute. This enables compression
in SSH.
$Conf{RsyncClientCmd} = '$sshPath -C -x -l root -o
PreferredAuthentications=publickey $host $rsyncPath $argList+';
# Commands to run for client direct restores:
# Note the use of SSH's -C attribute. This enables compression
in SSH.
$Conf{RsyncClientRestoreCmd} = '$sshPath -C -q -x -l root $host
$rsyncPath $argList+';
# Compression level to use on files. 0 means no compression. See
notes
# in main config file before changing after backups have already
been done.
$Conf{CompressLevel} = 3;
Now add the newly configured archive host in to BackupPC's hosts
file
#vi /etc/backuppc/hosts
Sample file looks like below
#
# The first non-comment non-empty line gives the field names and
should
# not be edited!!
#
host dhcp user moreUsers # <--- do not edit this line
#farside 0 craig jill,jeff # <--- example static IP host entry
#larson 1 bill # <--- example DHCP host entry
examplehostname 0 backuppc
And finally restart BackupPC so your changes take effect
#/etc/init.d/backuppc restart
Off Site Backup
A number of different ways to go about off
site backup when using BackupPC are discussed below.
TAR Archives using an 'archive' host
The simplest way to handle off-site backup is
to use BackupPC's archive host feature to produce tar archives,
and to then copy these archives to removable media.
BackupPC is configured to create tar archives by creating a new
host with it's XferMethod set to archive. The name of the host
should be appropriate to the type of archives the archive host
will be configured to create. For example dvd archive or tape
archive.
Create a new host configuration file as shown below:
# ee /etc/backuppc/dvdarchive
# Set this client's XferMethod to archive to make it an archive
host:
$Conf{XferMethod} = 'archive';
# The path on the local file system where archives will be
written:
$Conf{ArchiveDest} = '/mnt/archives';
# the type and level of compression used on the archive:
$Conf{ArchiveComp} = 'gzip';
$Conf{CompressLevel} = 1;
# The amount of parity data to create for the archive using the
par2 utility.
# In some cases, corrupted archives can be recovered from parity
data.
$Conf{ArchivePar} = 0;
# A size in megabytes to split the archive in to parts at.
# This is useful where the file size of the archive might exceed
the
# capacity of the removable media. For example specify 700 if
you are using CDs.
$Conf{ArchiveSplit} = 650;
# The full command to run to create archives:
$Conf{ArchiveClientCmd} = '$Installdir/bin/BackupPC_archiveHost'
. ' $tarCreatePath $splitpath $parpath $host $backupnumber'
. ' $compression $compext $splitsize $archiveloc $parfile *';
$Conf{ArchivePreUserCmd} = undef;
$Conf{ArchivePostUserCmd} = undef;
# Logging verbosity:
$Conf{XferLogLevel} = 1;
Now add the newly configured archive host in to BackupPC's hosts
file
# vi /etc/backuppc/hosts
Sample hosts file looks like below
#
# The first non-comment non-empty line gives the field names and
should
# not be edited!!
#
host dhcp user moreUsers # <--- do not edit this line
#farside 0 craig jill,jeff # <--- example static IP host entry
#larson 1 bill # <--- example DHCP host entry
archive 0 backuppc
And finally restart BackupPC so your changes take effect
#/etc/init.d/backuppc restart
The archive host will now appear within the web-based interface
along with all your other hosts, except that instead of allowing
you to start backups this host's interface will allow you to
create archives of your other hosts.
Archives you create in this way will contain the most recent
backup of a host, not a full set of historical backups. Its a
good idea to cycle your removable media in such a way that you
maintain a certain number of historical backups, and so that you
are never in the situation where you are over-writing your most
current backup with the new one.
Once the archive process has completed the tar archive can then
be copied to removal media of one of the types suggested below,
and then taken off site.
Archives can be created automatically using a cron job.
Direct Restore Procedure
The following procedure is suitable for performing a full
restore directly from BackupPC's web-interface.
Base Debian install
Begin with a base Debian installation. Either install in the
normal manner; from disk or across the network, or if you use a
serial console then re-image.
Prepare the Target Host
Login to SSH on the target host:
# ssh target.example.com Install your favourite editor:
# aptitude install vim
Next backup the base-install configuration.
You might need to re-instate a couple of these files once you
have restored your file system from backup.
# cd /
# tar zcvf /root/etc.tar.gz /etc
Configure the hosts file, adding the DNS name
for your backup box as a minimum
# vi /etc/hosts
Enable public key authentication in SSH
# vi /etc/ssh/sshd_config
To do so, simply uncomment the lines below
PubkeyAuthentication yes
AuthorizedKeysFile %h/.ssh/authorized_keys
And then create the authorized keys file, just as it was on the
backed-up host:
# vi /root/.ssh/authorized_keys
# chmod 600 /root/.ssh/authorized_keys
Restart SSH:
# /etc/init.d/ssh restart
Install RSync
# aptitude install rsync libfile-rsync-perlPrepare the Backup
Client
Remove any existing host key entries identifying the target
host, since the host key will change:
# vi /root/.ssh/known_hosts
# vi /var/lib/backuppc/.ssh/known_hosts
Test that you can ssh to target host as root
#backuppc ssh -o preferredAuthentications=publickey root@test
Restore the File System
Restore the following parts of the file system from the BackupPC
web-interface to the target host
/bin
/etc
/home
/lib
/opt
/sbin
/tmp
/usr
/var
If the kernel from the backup is compatible with the hardware
you are restoring to then you might also want to restore it. But
otherwise you can simply omit the parts of the file system shown
below and stick with the kernel installed during Debian
installation.
/boot
/sys
/initrc
Note that we haven't restored
/root
Its up to you to do this after this process is complete, if
necessary.
Pre-Reboot Configuration Changes
It may be necessary to make some configuration changes to the
freshly restored host before you reboot.
First we need to extract the backup we made of the
base-configuration
# cd /root
# tar zxvf etc.tar
The partition and file system schema of your restore target host
might not match that of the backed-up host, so re-instate the
file created during Debian installation
# cp /root/etc/fstab /etc/fstab
Similarly, the network configuration of the backed-up host might
not be suitable for the restore target host, so re-instate the
network configuration created during Debian installation
# cp /root/etc/network/interfaces /etc/network
For me it was necessary to also re-instate the files below, but
you probably wont need to.
# cp /root/etc/profile /etc
# cp /root/etc/inittab /etc
we also deleted mail in Postfix's mail queue, since I knew that
this mail had already have been delivered, and didn't want to
deliver duplicates
# postsuper -d ALL
TAR Restore Procedure
The following procedure is suitable for performing a full
restore from a TAR archive that was created using BackupPC's
archive host feature.
Base Debian install
Strictly speaking it's not necessary to begin with a base Debian
install, but there are a couple of reasons why you might want to
The installer takes care of things like the master boot record,
making the procedure simpler for less experienced users.
The installer will create new configuration files to suit the
hardware you are restoring to, which may be different to that of
the backed-up host. Its then easier to interchange configuration
files as necessary.
Install Debian Sarge to the target host in the normal manner, or
re-image the server using your serial console.
Prepare the target host
Connect to target host
# ssh target.example.comInstall your favourite editor
# aptitude install vim
Configure hosts file
# vi /etc/hosts
Make a backup of your base-install
configuration, in case you should need to restore anything
having over-written with your backed-up file system
# cd /
# tar zcvf /root/etc.tar.gz /etc
Restore the File System
If your tar archive is stored on physical media such as
TAPE/CD/DVD then you can simply mount the media and extract
directly from the media to the file system
# mount /dev/cdrom /cdrom
# cd /
# tar --numeric-owner -zxvpf /cdrom/host.1.tar.gz
Or if your tar archive is located on an NFS export first install
the necessary NFS client packages, then mount the export and
extract from it directly to the file system
# aptitude install nfs-common
# mkdir /mnt/archives
# mount nfs.example.com:/home/archives /mnt/archives
# cd /
# tar --numeric-owner -zxvpf /mnt/archives/host.1.tar.gz
To restore to a remote server, you could simply copy the tar
archive across using scp and then extract it as shown above.
However, while there may be sufficient storage space on the
restore target host for the extracted file system, there may be
insufficient for the extracted file system AND the tar archive.
One solution is to extract the tar archive on the local backup
server and pipe the output through SSH to the restore target, as
shown below
# ssh target.example.com "cd /; tar --numeric-owner -zxvpf -" <
/home/archives/host.1.tar.gz
Pre-boot configuration changes
It may be necessary to make some configuration changes to the
freshly restored host before you reboot.
First we need to extract the backup we made of the
base-configuration
# cd /root
# tar zxvf etc.tar
The partition and file system schema of your restore target host
might not match that of the backed-up host, so re-instate the
file created during Debian installation
# cp /root/etc/fstab /etc/fstab
Similarly, the network configuration of the backed-up host might
not be suitable for the restore target host, so re-instate the
network configuration created during Debian installation
# cp /root/etc/network/interfaces /etc/network
For me it was necessary to also re-instate the files below, but
you probably wont need to.
# cp /root/etc/profile /etc
# cp /root/etc/inittab /etc
We also deleted mail in Postfix's mail queue, since we knew that
this mail had already have been delivered, and didn't want to
deliver duplicates:
# postsuper -d ALL
Left Over Files
You might notice that some packages from the Debian base-install
which had been removed from the backed-up host are still present
after you complete the restore from TAR process. For instance,
you might have replaced exim4 with postfix, yet when you reboot
exim tries to start.
This is because the file system restore process only creates and
over-writes files. It doesn't remove files from the restore
target that were not present in the backup.
You cannot use aptitude to remove the packages because aptitudes
state has been restored from backup: it doesn't think the
package is installed.
None of this should present any real world problems. Your
restore should still succeed and leave you with a fully
functional server, but it is a little untidy. Your mileage may
vary.
# aptitude reinstall postfix