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.
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.
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.
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.
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.
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.