Locations of visitors to this page

Using Unison with BackupPC to backup laptops

These instructions are provided in the hope that they'll be useful to others. If you find them useful, please drop me a note: stephen [at] physics.unc.edu. Similarly, if you implement this setup on platforms other than Windows and wish to contribute your code (either under GPL, or transferring copyright to me) please do so.

The Problem

One common problem plaguing IT professionals is how to backup data on laptops and other mobile devices. There is considerable value in mobile data, but many users seldom, if ever, bring their laptops back to the corporate or academic campus where it may be regularly backed up.

BackupPC is an excellent open-source product for backing up computers. It excels at backing up desktops and servers, but laptops (as moving targets) are especially difficult. By default, BackupPC can be configured to wake up periodically, say hourly, and look for laptops that have appeared on the network. This is not without issues (some of which can be worked around), but these are compounded when laptops do not have static IP addresses.

A better solution is to allow users to backup valuable data on the laptops on-demand. This page details my solution to do this.

Design Requirements

In order to allow users to backup mobile data on-demand, a large cache area is needed. I dedicate a fast 750GB drive for this purpose. Note that this is in addition to, and separate from the BackupPC data directory, which should be on a RAID. I can get away with such a small cache directory because users are instructed to store valuable data in one directory on the laptop (C:\BackMeUp) and that is the only directory which is backed up. It is possible to back up more of the laptop's disk if you have enough disk space (it is even possible to use VSS to backup all of C: if you want!). Remember, the more data that is backed up, the longer the backups will take.

In operation, users use Unison, a fairly user-friendly rsync GUI, to sync their laptop with their directory on the cache disk. Instead of waiting for the laptop to be present on the LAN to begin a backup, BackupPC backs up the data from the cache disk to its data archive. Users perform backups whenever they desire, from wherever they desire--even behind firewalls and NAT devices!--(as long as they can SSH to the BackupPC server), can perform restores from the cache easily, and can log into the BackupPC GUI (if the admin has allowed it) to retrieve older versions of needed files.

Software Required

On the BackupPC server On the clients (end-user laptops)

Puttygen and the GTK+ installer may be removed after initial setup, if desired.

Note that Unison is a cross-platform application. There is nothing, other than writing appropriate scripts, to stop this same process from working on mobile MacOS or Linux laptops. The scripts that I publish are for Windows. If anyone implements this scheme on MacOS X or Linux, please contribute your scripts. Similarly, I have only tested this on Windows XP at this point. I am interested in feedback from Vista users.

In most of my directions, my directory paths adhere to the FHS. If you change any of the directory paths, please be certain to change them in all relevant locations! Grep is your ally! Further, I assume you're using Debian, or a derivative on your BackupPC server. If you're not, you'll have to satisfy certain dependencies via your distro's package manager or by installing from source.

Server Steps

  1. Install BackupPC if you have not already done so.
    NOTE: If you install BackupPC so that its data directory is not /srv/on-demand/archive you will need to adjust the paths in the predump and postdump scripts as well as use your location when configuring clients' RsyncShareNames.
  2. Install and Configure Apache2 if you have not already done so. SSL encryption for logins is strongly recommended!
  3. Install unison on the BackupPC server.
  4. Configure BackupPC for on-demand backups

Client Steps for Windows XP Clients

  1. Download the application and script archive and unzip the contents into C:\unison. When you're done, C:\unison\bin should contain 2 .bat files, and 5 .exe files. C:\unison\etc should contain 2 .prf files. It is important that the user(s) that will be performing the backups be able to write to C:\unison\etc, but the C:\unison\bin directory can be made read-only if desired.
  2. Make a C:\BackMeUp folder to store important data. The procedure documented here only backs up the contents of the C:\BackMeUp folder, however this is fairly easy to change in the Unison profiles.
  3. Run the GTK+ installer (required by the Unison GUI) and install on the client. It is located at C:\unison\bin\gtk+-2.10.6-1-setup.exe. You may then delete the gtk+-2.10.6-1-setup.exe file if you like. It is important to REBOOT before using the Unison application.
  4. Edit the following files and change all occurances of "REPLACEME.physics.unc.edu" to the fully qualified name of your BackupPC server:
  5. Optionally edit C:\etc\backmeup.bat and customize the error messages which are displayed when something goes wrong. I advise you replace "your IT support desk" with your IT department's email address.
  6. Set up passwordless SSH between the Windows laptop and the BackupPC server
  7. On the Windows client, test that passwordless SSH logins work. You'll probably be asked if you'd like to save the server's key in your cache. You must answer yes for future passwordless logins, and on-demand backups, to work.
    C:> C:\unison\bin\plink.exe fully-qualified-name-of-your-BackupPC-server -i C:\unison\etc\private.ppk -l laptop-user
    Linux foobar 2.6.18-5-686 #1 SMP Mon Mar 26 17:17:36 UTC 2007 i686
    This system is running Linux debian 4.0 i686

    laptop-user # exit

Repeat the steps above for each client you'd like to be an on-demand client. Once you understand them and have performed them correctly on a client or two, almost all of the steps may be scripted so as to be nearly automatic on both client and server.


At this point, you should be able to run "C:\unison\bin\backmeup.bat backup" to perform a backup and "C:\unison\bin\backmeup.bat restore" to perform a restore.

If you're configured BackupPC correctly, it should notice that a new on-demand Unison backup session has left files the next time it wakes. I recommend waking every hour as most often there will be nothing for BackupPC to do. If you've configured BackupPC to allow users to log in, then they should be able to visit https://fully-qualified-name-of-your-BackupPC-server/cgi-bin/BackupPC_Admin to see the backups associated with their laptop(s).

Convenient shortcuts to "C:\unison\bin\backmeup.bat backup" and "C:\unison\bin\backmeup.bat restore" should be created in your enterprise standard location. Files suitable for this are in the C:\unison\start folder.

Security Concerns, Considerations, and Ideas

It is quite possible to get this procedure working, but have things configured in an insecure way. I strongly encourage you to double-check that you've performed all the steps and to cast a critical eye on my procedure. I encourage feedback for enhancing security without compromising the way this works.

Obviously, to utilize this backup mechanism, clients must be able to initiate SSH sessions to your BackupPC server. Depending on your circumstances, you may be able to limit the scope of IPs from which sshd will accept connections. If you must leave it wide open, the use of a utility such as DenyHosts or Fail2Ban to lock out any IP with an excessive number of bad login attempts is strongly advised.

You may wish to run sshd on an alternate port for client connections.

It is possible for users of laptops being backed up with this method to obtain shell access to the BackupPC server. Therefore it pays to double-check your file access permissions on your $cache/$laptop-user/c directories. They should be 700 and owned by $laptop-user. Similarly, the BackupPC data directory should be 700 and owned by the backuppc user. Fail to check these permissions and risk users being able to read each others' private files (basically treat these areas as strigently as you do normal user home directories and you should be fine).

You may wish to actively discourage your users from getting shell access. A cron job to kill any end-user job that doesn't include "/opt/unison/bin/unison" is probably a safe thing to run periodicly. (grep the process IDs from ps, sleep 2-5 seconds to give legitimate transient script commands a chance to complete, then attempt to kill the process ID if it still exists). If I write such a script I'll publish it here. If you write one, please contribute it! Other ideas include chroot jails and restricted shells.