Backing Up with Rdiff-Backup

1. Format a big drive as UDF.
2. Install rdiff-backup
3. rdiff-backup –exclude-globbing-filename $HOME/.excludes $HOME /path/to/drive
4. Automate that command with cron

There are several good backup applications aimed at local and network backups. Some are geared toward sys admins managing entire VFX houses, others are geared toward the advanced home user, and still others are aimed at regular, humble, everyday artists like us. No matter the audience, the best solutions can be automated so that you don't have to remember to do it, or wait for huge data dumps when you finally do remember to backup. A steady, automated, “always on” backup scheme tends to be the smartest backup plan.

The most straight-forward and flexible backup application available is rdiff-backup, available from It has one dependency, librsync, which is also available on

This section assumes that you are interested in backing up your personal data, not the entire system, since the OS is free and can be re-constructed.

There is a case for backing up the entire system (quicker recovery in the event of a full system disaster being the main one), and this can be done; just replace /home/$USER in this chapter with / and run your backups as root. See for more information on what directories you should exclude when doing a full system backup.

Rdiff-backup is a terminal command only; it has no graphical user interface. If you are not comfortable using the terminal, it's still ok to use rdiff-backup because the point of it is that you don't have to use it much; you automate it. That's what we'll do together here, and once you get through this chapter, you will never have to use rdiff-backup directly again, except to recover data but under those circumstances, you probably won't mind learning a new command or two.

If you still doubt this prescription, you are welcome to try out LuckBackup but be aware that fancy graphical (luckybackup included) are more subject to change than backup commands, which have often been around, basically unchanged, for decades. If longevity is not a concern, feel free to explore different backup options than what Slackermedia recommends.

Rdiff-backup Plans

Local Backup

☛ If you own the drive to which you want to backup, then do these steps before continuing.

☛ If you run your own home server (or you otherwise have physical access to the server acting as your backup destination), then this setup should occur on the server, not your local computer.

☛ If you are backing up to a server off site that you have no physical access to, skip this entirely and read the section on remote backups.

1. Format your hard drive to be used as a backup drive.

If you are intimately familiar with hard drive formats (“file systems”) and have your own preferred file system, you may use that, but Slackermedia recommends the UDF file system for your backup drive because it is easy to configure, it handles large drives well, its paths are easy to specify, and it is universal so that no matter what you have available to you, you can get to your data.

Read the section on udf to learn how to safely create a UDF drive. Give your UDF drive an id of safehouse (–vid=safehouse).

When you format it, give your UDF drive an id of safehouse (–vid=safehouse).

When coming up with a naming scheme for your backups, it's best to use a unique (but sensible) term, because the word “backup” gets used so frequently by so many applications. You want to be able to recognise your backup, so pick a somewhat unique name for it; look in a thesaurus or use your artistic creativity to think of a word that means “backup” (examples: carbonite, keepsafe, safehouse, vault, bunker, silo, attic, booty, hoard).

Slackermedia uses the naming scheme “safehouse” as the backup location. This avoids confusion over whether we are talking about “backup” the action or “backup” the place, and so on.

2. Add the drive to /etc/fstab.

There are several advantages of doing this; it will make the drive automatically mount if it is attached at boot time, and it also ensures that you have an easy way of finding your backup location no matter when the drive is attached.

First, add a directory for the drive. This will make the drive more integrated with the system (meaning that your computer will not have to create dynamic directories for it in /run/media as it does for most external drives).

$ su -c 'mkdir /safehouse'

Next, add the drive to the file system table, located at /etc/fstab. Open this file in your favourite text editor with kdesu and add this line to it (it's ok to copy and paste this exact line; it is verbatim what you should add):

LABEL=safehouse     /safehouse    udf   user,rw  0 0

Save the file and reboot to make sure that the drive mounts automatically if connected. Technically, it's not necessary to reboot, but you might as well reboot just to verify that all goes well.

3. Perform an initial backup.

The first backup is the largest and slowest backup because it is copying everything over to your backup drive. Subsequent backups will be much much smaller, because it will only copy changes to that base layer.

It is vital that this initial backup is done the exact same way it's going to be done on all future backups, for many reasons, but essentially because you need to get confirmation that everything has been set up correctly before you try to automate it. If you do a backup with a drive connected to your computer, and then try to switch to a networked backup, you might do user permissions wrong, or file paths might be inconsistent, or any number of problems, and you won't ever realise it because you'll have automated the process, never knowing that all you have automated is failure.

Do not do that.

Make your first backup the initial test of your backup process. If it fails, refine your process, troubleshoot, and try again. When you get it right, you'll know it, and you'll know exactly what to automate.

The basic command to backup your home directory (where all of your personal data lives):

For a locally attached drive:

$ rdiff-backup --terminal-verbosity 8 --print-statistics \
--exclude-globbing-filelist /home/klaatu/.excludes /home/klaatu/ \

You might have exclusions that you don't want to have backed up (for instance, do you ever want your trash bin backed up?). For this, read the section on exclude options.

Or for a server:

$ rdiff-backup --terminal-verbosity 8 --print-statistics \
--exclude-globbing-filelist /home/klaatu/.excludes /home/klaatu/ \

Notice that the server path contains two :: between the hostname and the destination path.

This command backs up your entire home directory to the /safehouse location. Do not bother creating the destination file (in this example's case, the /safehouse/klaatuWork folder); rdiff-backup will [attempt] to create that for you and warn you if it cannot write to the drive.

No matter what, your first backup will take a long time, so just let it work.

You have completed the setup phase.

Backup to a Local Drive

If your computer is a workstation (or “desktop” or “tower”) then it makes sense to backup your data to a drive that you just leave plugged in to the computer. The advantage is that the backups occur in the background, without any special action required of you. The dis-advantage is that the drive is physically connected to your computer, so if accidentally erase your entire computer and everything connected to it, then you have blown away both your data and the backup copies of your backup data (the likelihood of you devising such a command by accident is extremely rare).

As with any local backup, this method also is not fire-, flood-, or Velociraptor-proof. That is, if something catastrophic happens to your house or apartment, then your data is gone and so is your backup.

On the other hand, if you accidentally delete a file an hour before your deadline, you can pull the most recent version off of a drive sitting under your desk and move on with your life.

As always with devising a backup plan, the cost-to-benefit factor is your own to ponder.

The backup scheme for such a setup is simple.

1. Verify that the drive has been mounted to /safehouse as expected:

mount | grep safehouse

If nothing is listed, then the drive has not mounted successfully. Verify that you have labelled it properly with the vid flag (if using UDF as recommended; if you are using ext{2-4}, try using e2label).

2. Change a file or add a new test file, and then run the your backup command again.

$ rdiff-backup -v 8 /home/klaatu/ /safehouse/klaatuWork/

This time, the process is relatively fast, since it has only copied over the changes.

☛ You might have exclusions that you don't want to have backed up (for instance, do you ever want your trash bin backed up?). For this, read the section on exclude options.

☛ Assuming everything is working as expected, automate the process and never think about it again.

☛ For information on recovering data from a backup, read the section on restoring files.

Backup Upon Connection of a Local Drive

If your computer is a laptop, then having a drive that is always connected probably is not realistic. You can, however, create a system such that when you plug in a specific hard drive, your system uses it as a backup drive. This way, all you have to do to initiate a backup is attach your backup drive; you don't even have to necessarily run a command (depending on your preference).

The dis-advantage to this method is that you might forget to attach the drive with any regularity, so your backups may end up being few and far between. Reducing the perceived workload of “it's time to backup” to the simple act of plugging in a portable drive does simplify things, but if you don't attach the drive, then even a simple solution like this does you no good.

As with any local backup, this method also is not fire-, flood-, or Storm Trooper-proof. That is, if something catastrophic happens to your house or apartment or planet, then your backup drive is gone. If your laptop is on your person, you do have your original data, so in a way this scheme (because a laptop is inherently portable) enforces the “never keep your originals and your backups in the same place” rule (except when your laptop and the drive are in the same place).

On the other hand, if you accidentally delete a file an hour before your deadline, you can pull the most recent version off of a drive sitting under your desk and move on with your life.

As always with devising a backup plan, the cost-to-benefit factor is your own to ponder.

Easy (the "It's better than nothing" solution)

You need to identify your backup drive to your system, so that your computer knows to backup to it when it gets plugged in. The easiest way to do this is to lie to your computer and tell it that your backup drive is always attached; any backup attempts made when the drive is not attached will fail, while any backup attempt when the drive happens to be attached will succeed. To implement this method, just use the backup to a local drive method, and then skip down to the automation section.

The danger of using this easy method is that if you have your computer set to backup every 4 hours, for example, and you attach your drive but only leave it attached for 3.75 hours, then you miss a backup cycle. Keep doing that, and you may end up with far fewer backups than expected. It practise, it's better than nothing, and as long as you remember to leave your laptop on and awake overnight with your backup drive attached, you are sure to hit one or two backup cycles (depending on how often you sleep).

udev (the "I spent my weekend with udev" solution)

The more difficult solution is to use udev, the sub-system in Linux that supplies your computer with “device events”. It's the system that labels things like DVD-ROM drives, network cards, external hard drives, mousen, keyboards, joysticks and gamepads, and so on. That makes it a very handy utility, and like everything else in Linux, it's very well exposed to the user so you can manually script it to, for instance, perform certain tasks when a certain hard drive is plugged in.

The script

First, you need a script to launch when your drive is attached.

Start with something that will simply confirm that yes, udev is detecting a drive when it is plugged in, and is triggering a corresponding script. Since we cannot guarantee that we will ever see the results of the script with our own eyes, make the script log that it was successfully triggered:


date > /tmp/udev.log

Place this in /usr/local/bin or some such place; call it and make it executable with chmod +x.

If udev triggers this script, there will be the timestamp of when it happened in /tmp/udev.log

Unique Device Identification

In order for the script to be triggered by a device event, udev must know under what conditions it should call the script. In real [human] life, we can look at our backup drive and say “Whenever I plug in this 3tb, gray drive, manufactured by TyCoon Corporation, I want the computer to back it up”; the computer can use, more or less, the same criteria, but it needs a more explicit way of identification.

The udev system can identify devices by serial number, vendor ID, and product ID (and more). As with so much in computers and art, we will make our first iteration very basic. Our criteria will begin as broad, non-specific, and all-inclusive as possible; we want first to catch nearly any valid udev event and trigger our script, just to confirm that we are on the right track.

With the udevadm monitor command, you can tap into udev in real-time and see what it sees when you plug in different devices. Become root, and try it:

$ su
# udevadm monitor

With udevadm monitor running, plug in your backup drive and watch as all kinds of information is spewed out onto your screen. Notice, particularly, that the type of event is an ADD event. That's a good way of identifying what type of event we want.

The udevadm monitor provides a lot of good info, but we can see it with prettier formatting with the command udevadm info -a -n, assuming you know where your drive is currently located in your dev tree. If not, unplug and then plug your thumbdrive back in and then immediately issue this command:

# dmesg | grep \/dev\/sd* | tail -n1

Assume that this command returns sdx, for instance; in that case, your thumbdrive has been assigned the sdx label (unlikely; it will probably be sdb or sdc or sdd or so) by the kernel. Now that we have established that, we can view the udev information about that device:

# udevadm info -a -n /dev/sdx | less

This will return a wealth of information. Focus on the first block of info, first.

The feedback from udevadm info -a -n starts with the device specified by the devpath, and then walks up the chain of parent devices. It prints for every device found, all possible attributes in the udev rules key format.

A udev rule must contain one attribute from one single “parent” device; parent attributes are things that describe a device from the most basic level, such as “it's something that has been plugged into a physical port” or “it is something with a size of XX” or “this is a removable device”.

That info, just under the udevadm info -a -n introductory paragraph, looks a little something like this:

looking at device '/devices/000:000/foo/bar//block/sdx':
   ATTR{stat}==" 2765 1537 5393"

Since the KERNEL label of sdx can change depending upon how many other drives you happen to have plugged in before you plug that drive in, that's not the optimal parent attribute for a udev rule, but it would work for testing. Another, better, candidate is the SUBSYSTEM attribute, which identifies that this is a “block” system device.

We now have enough to write a simple udev rule.

A “Hello World” Udev Rule

Construct a very simple and very generic proof-of-concept udev rule, just to make sure that everything is working as expected. The only goal at this stage is to trigger our basic script.

With kdesu, open a file /etc/udev/rules.d/80-local.rules (it will not exist, so create it) and place this text into it (it's OK to copy and paste this text; it is verbatim what you should put into the file):

SUBSYSTEM=="block", ACTION=="add", RUN+="/usr/local/bin/"

Unplug your drive, and reboot.

Once your computer is back up, plug in your drive. Wait a few moments, and then:

$ cat /tmp/udev.log
Wed Sep 19 22:23:22 EDT 2019

If you see the date and time returned from /tmp/udev.log, then the script has worked.

Refining the Rule into Something Useful

The problem with the rule right now is that it is generic to the point of being functionally useless. Plugging in a mouse, a thumbdrive, or someone else's thumbdrive will all indiscriminately trigger your script. Now is the time to start focusing in on the exact backup drive you want to have trigger your script.

The easiest way to do that is with the vendor ID and product ID. To get these numbers, you can use the lsusb command.

$ lsusb
Bus 001 Device 002: ID 8087:0024 Slacker Corp. Hub
Bus 002 Device 002: ID 8087:0024 Slacker Corp. Hub
Bus 003 Device 005: ID 03f0:3307 TyCoon Corp.
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 hub
Bus 001 Device 003: ID 13d3:5165 Tyrell Network Interface

The vendorID and productID are the set of numbers around the colon (:). Looking at the TyCoon Corp. line, the vendor id is 03f0 and the product is 3307.

You can include these attributes in your rule. With kdesu, open the file /etc/udev/rules.d/80-local.rules again and refine your rule (you need to customise this line to match what you see on your screen; do not copy-paste the text from here):

SUBSYSTEM=="block", ATTRS{idVendor}=="03f0", ATTRS{idProduct}=="3307", ACTION=="add", RUN+="/usr/local/bin/"

Reboot and test the new rule.

The results should be the same as before (except with a later timestamp), only now if you plug in, say, a drive manufactured by a different company (therefore with a different idVendor) or a mouse or a webcam, the script will not be triggered.

Keep adding in new attributes to further focus in on the one unique drive that you want to trigger your script. In theory, the more specific, the better, although in practise the vendor and product may be suitable, depending on how many of the exact same drives you own. Use udevadm info -a -n /dev/sdx to find out vendor name, serial number, product name, and so on.

For your own sanity, be sure to add only one new attribute at a time. Most mistakes made during this process come from throwing a bunch of attributes into a udev rule such that nothing ever matches it.

Refining the Script

Once you can comfortably confirm that your script is triggered by udev when you attach your backup drive, turn your attention to the functionality of the script. Right now it is useless, doing nothing more than logging the fact that it has been executed.

Here is an example backup-on-attach script. You can use it exactly as is EXCEPT for the last command; you need to change the path of the directory you want backed up (unless your username is also klaatu) and the destination (unless you also named your destination folder klaatu):


mount /safehouse

# wait for drive to mount and be writable
while [ "$COUNT" -lt "6" ]; do
    sleep 5
    if [ -b /safehouse ]; then
        if [ -w /safehouse/klaatu ]; then
            # everything is ok
            echo "Backup directory has incorrect permissions @ `date`" >> /tmp/safehouse.log
        echo "Drive not mounted @ `date`" >> /tmp/safehouse.log

    let "COUNT++"

# this is hopeless, get out
if [ "${COUNT}" == "6" ]; then
    echo "Could not locate SAFEHOUSE. Backup NOT complete. THIS IS BAD. `date`" >> $HOME/safehouse.log

# if we are here, everything is good to go
if [ "${COUNT}" -gt 6 ]; then
    rdiff-backup /home/klaatu /safehouse/klaatu

You might have exclusions that you don't want to have backed up (for instance, do you ever want your trash bin backed up?). For this, read the section on exclude options, and then add those options to the ##BACKUP COMMAND section.

☛ Try changing a file or adding a new test file, and then attach your hard drive. A backup process should be started by udev, this time copying over only the changes you have made to your home directory. Check for errors in /tmp and in your home directory.

☛ Assuming everything is working as expected, automate the process and never think about it again.

☛ For information on recovering data from a backup, read the section on restoring files.

Backup to a Personal Server

If you have a home server, or a server away from home that you can physically access, you might prefer to do your backups remotely. The advantage to remote backups is that you neither get tied down by having a hard drive attached to your computer, nor do you have to remember to attach it if you like a mobile lifestyle. If your server is off-site, then you have some insurance against disaster, since the likelihood of both your personal computer and your off-site server facing destruction is less likely when they are not physically located in the same building.

You should have gone through the setup steps before starting this process, so you should have a hard drive in the UDF format with the initial backup of your data on it. Your server should have a /safehouse mount point on it, and the drive should be set as mountable in fstab. Both your client and your server must have rdiff-backup installed.

For rdiff-backup to work remotely, both your client (the machine whose data is being backed up) and the server (the computer receiving the backup data for storage) must have rdiff-backup installed. That's two installs of rdiff-backup.

1. Mount the drive on your server:

$ mount /safehouse

2. Make the server accessible by ssh or rsync (for rsync, you'll also need to run the rsync daemon, which requires additional setup.

For security's sake, and because rdiff-backup will not prompt you for a password, you must use an ssh key to log into the remote server. For more information on ssh keys, see the automation section.

On the server, you should disable ssh-password sign-in (this option is found in /etc/ssh/sshd_config), and consider using Fail2Ban.

3. Attempt a remote backup:

$ rdiff-backup -v 8 $HOME

This time, the process is quite fast, since it has only copied over the changes.

☛ You might have exclusions that you don't want to have backed up (for instance, do you ever want your trash bin backed up?). For this, read the section on exclude options.

☛ Assuming everything is working as expected, automate the process and never think about it again.

☛ For information on recovering data from a backup, read the section on restoring files.

Backup to Someone Else's Server

Backing up to a server that you do not own or do not have physical access to can be tricky, because you may not have access to it in such a way that remote backups are allowed. Besides, the remote server must also have rdiff-backup installed on it, and it may not have that.

On the other hand, you might; it depends on what you are paying for, or what the sys admin is providing you.

If you have ssh access to the server, then you can treat it the same as your own private server in terms of setup.

Other methods of accessing the server will likely not work, since rdiff-backup must be on the remote server, and needs ssh access.

You might look into other backup solutions, like

Backup a la Carte

Some people generate more data than others. If you are, for example, a writer or any kind of artist dealing in small file formats, and you find it's easier to just backup files as you create them, then that's a valid backup option…as long as you remember to do it.

Consider purchasing a large-capacity thumbdrive and using it as either your master work directory or as your plug-and-backup destination. That way, every time you plug your drive into your computer, it gets backed up; you no longer have to remember to do it manually!

If you are using rdiff-backup, you can backup a single file between backup script occurrences:

$ rdiff-backup --include $HOME/foo.txt --exclude '**' $HOME /safehouse

Another option is to wield the power of the Internet, and use a good git service. There are several simple clients for git, including the very appealing SparkeShare or, if you have access to a server and the time to configure it, ownCloud. These both have Dropbox-style sync folders.


No matter what your backup plan, space is limited. There are bound to be things hanging around in your home directory that just aren't important to you. You can and should exclude these files from being backed up.

You could specify the directories and files you want excluded in your rdiff-backup command, but if you are automating the backups (and you should be), then what not to backup also should be automated.

The solution is to have a local ~/.excludes file, listing each directory or file you want excluded from the rdiff-backup process. Such a file is easy to create: just echo the path of a directory or file into ~/.excludes; if it does not exist, the file will be created for you, and the entry added.

$ echo '/home/klaatu/.local/share/Trash' >> ~/.excludes

As you find more files that you want to exclude, use the same command.

$ echo '/home/klaatu/stockFootage' >> ~/.excludes
$ echo '/home/klaatu/downloads' >> ~/.excludes

The only thing you must do is change the command you use to start the backups such that it knows where to look for a list of files to ignore:

rdiff-backup --exclude-globbing-filelist \
 /home/klaatu/.excludes \
 /home/klaatu/ \


Surprisingly, the hardest part about rdiff-backup or any backup plan is just determining how it should happen; once you have a hard drive dedicated to backing up your data, and have devised a way for that hard drive to be available, the automation part of the plan is simple.


Processes on Linux can be scheduled with cron. Each user has a cron table or crontab, which can be edited to run tasks at certain times.

$ EDITOR=emacs crontab -e

or if you prefer kate:

$ EDITOR=kate crontab -e

Your crontab will most likely be empty. Add a line like this (do not copy and paste this, modify it for your setup):

0 */6 * * * rdiff-backup --exclude-globbing-filelist /home/klaatu/.excludes /home/klaatu/ klaatu@example.local::/safehouse/klaatu/ 

This sets up an automatic backup every 6th hour (on the hour) of every day of every month, regardless of the day of the week.

The syntax for scheduling events in cron is:

  • Minute (0-59): This is almost never a (which would mean to perform an action every minute. It is combined with the hour field, such that the 0th minute of the 4th hour (4:00), some action would occur. * Hour (0-23): 24 hour clock; 4 is 4am, 16 is 4pm. Use the / (slash) to do things at increments. /4 means any hour that is cleanly divisible by 4 (so, every 4 hours). /3 is every three hours, and so on. means every hour at whatever minute is set in the minute field.
  • Day of Month (1-31): means every day. /2 would mean every other day, */3 every three days, and so on.
  • Month (1-12): Same principle as the day field.
  • Day of Week (0-6): 0 is Sunday and 6 is Saturday.

For example, to run a backup once a day at 23:00:

0 23 * * * rdiff-backup blah blah

To run backups every other hour only during 9:00 to 17:00 (business hours):

0 9,11,13,15,17 * * * rdiff-backup blah blah

The same, excluding weekends:

0 9,11,13,15,17 * * 1,2,3,4,5 rdiff-backup blah blah

And so on. If you are unclear, there are several good examples online, probably for the exact schedule you are planning.

Cron only works if your computer is on.

SSH Keys

If you are backing up to a local drive (that is, a drive attached physically to your computer), then you can skip this section.

If you are backing up to a server over SSH, then you presumably need to sign into that server. You are not prompted by rdiff-backup for a password, and even if you were, you wouldn't see it because you're automating the backup process.

Therefore, you must set up ssh key sign-in for your server.

Slackware makes this very easy. If you do not already have an ssh key on your Slackermedia machine, create one (it's free):

$ ssh-keygen

When prompted to create a passphrase, leave the passphrase empty. If you give you ssh key a passphrase, then you are defeating the purpose of using an ssh key for this use case.

If you already have an ssh key on your source machine, then you can use that. If, however, that key requires a password, then it's useless for automated backups. Create a new key, exclusively for the backup server. For example:

$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/klaatu/.ssh/id_rsa): /home/klaatu/.ssh/safehouse_rsa
Enter passphrase (empty for no passphrase): LEAVE THIS EMPTY
Enter same passphrase again: LEAVE THIS EMPTY
Your identification has been saved in /home/klaatu/.ssh/safehouse_rsa.

Now configure ssh to use your new safehouse_rsa key whenever you attempt to login to your backup host.

Open ~/.ssh/config in your favourite text editor. If that file does not exist (it probably won't) then create it. Here are two examples of valid configurations, one for a server with a fully-qualified domain name, and one for an internal home server:

        identityfile /home/klaatu/.ssh/safehouse_rsa
        protocol 2

     identityfile /home/klaatu/.ssh/safehouse_rsa
     protocol 2

Once your ssh key has been generated, copy it to your server:

$ ssh-copy-id -i /home/klaatu/.ssh/safehouse_rsa

Test it out by ssh'ing into the server: You should not be prompted for a password.

$ ssh klaatu@"

Assuming success, you now have password-less entry into your backup server (and so does rdiff-backup, since it will be running under your username).

Restoring (Recovering) Files

Once you have a backup, you obviously are able to restore files that you have either lost or changed beyond repair.

The command to get a file back off of a drive differs depending on how you are accessing the drive. For clarity, examples of both local and remote access are given.

Restore the most-recently backed-up version of a file:

$ rdiff-backup --restore-as-of now /safehouse/klaatu/paint/jlw.kra ~/paint/jlw.kra
$ rdiff-backup --restore-as-of now klaatu@example.local::/safehouse/klaatu/paint/jlw.kra ~/paint/jlw.kra

The –restore-as-of option (-r) can go back is time farther than just the most recent back-up. For instance, maybe you think the best good version of a file existed two days ago:

$ rdiff-backup --restore-as-of 2D /safehouse/klaatu/paint/jlw.kra ~/paint/jlw.kra
$ rdiff-backup --restore-as-of 2D klaatu@example.local::/safehouse/klaatu/paint/jlw.kra ~/paint/jlw.kra

Or maybe you aren't sure, and would rather view a few different versions. It's all backed up, so you can resurrect as many versions as you like:

$ rdiff-backup --restore-as-of 2D /safehouse/klaatu/paint/jlw.kra ~/paint/jlw-2days.kra
$ rdiff-backup --restore-as-of 5D /safehouse/klaatu/paint/jlw.kra ~/paint/jlw-5days.kra

Other acceptable time formats include 33m33s (33 minutes and 33 seconds ago) and full dates like 2015-01-01 for that New Years photo that you wanted to forget but are now having second thoughts about. For more options, see the TIME FORMATS section of the rdiff-backup man page.

If you know even more detail about your file, you can use rdiff-backup to restore directly from an incremental backup file. Increment files are stored in your backup destination (/safehouse, what ever drive or server that may exist on) in rdiff-backup-data/increments.

They hold the previous versions of changed files. If you specify one directly:

rdiff-backup /safehouse/klaatu/rdiff-backup-data/increments/novel.2014-11-24T02:21:41-07:00.diff.gz ~

Dummy Checks

It's not a bad idea to check in on your backups every now and again, just to verify that what you think is happening is really happening.

To check your backups, log into your backup server or attach your backup drive, and have a look at the latest ten (or so) backup files created:

$ find /path/to/backup/dir -type f -printf "%C+ %p\n" | sort -rn | head -n 10

Adjust your backup scheme as necessary, depending on what you discover.


There are several good article on rdiff-backup. is quite good.