Saturday, April 23, 2011

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



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.

No comments:

Post a Comment