Tarsnap - Online backups for the truly paranoid

Navigation menu

What's the problem with backing up filesystem snapshots?

Suppose a particular file has this timeline:

TimeEvent
0File is created
...
XSystem clock ticks
X + 0.1File is modified: version A
X + 0.2Filesystem snapshot is created
X + 0.3File is modified: version B (same size as A)
X + 1System clock ticks
...
X + 100Tarsnap archives the file (version A) from the snapshot
...
YAnother filesystem snapshot is created
...
Y + 100Tarsnap examines the file (version B) but does not archive it (problem!)

When Tarsnap runs at time X + 100, it will see the file version A with a modification time of X (since that is how snapshots work). When Tarsnap runs again at time Y + 100, it will still see a modification time of X (and the same filesize as version A), so it will assume that the file hasn't changed — even though the file is in fact different, due to the change from A to B at time X + 0.3.

How likely is this to matter? Well, POSIX only guarantees a filesystem time resolution of one second, and computers can do a lot of processing in one second.

Solution: use a timestamp prior to the snapshot

The --snaptime argument allows Tarsnap to recognize situations where this might occur and makes sure that it re-reads the file rather than assuming that it hasn't changed. To use it, please:

  1. Create a file (older than the snapshot) to serve as a reference time:
    touch /tmp/snaptime
  2. Create a filesystem snapshot, and mount it as /mnt.
  3. Run Tarsnap with the --snaptime option:
    tarsnap --snaptime /tmp/snaptime -cf mybackupname /mnt
  4. Unmount the snapshot, and remove /tmp/snaptime.