What's the problem with backing up filesystem snapshots?
Suppose a particular file has this timeline:
|0||File is created|
|X||System clock ticks|
|X + 0.1||File is modified: version A|
|X + 0.2||Filesystem snapshot is created|
|X + 0.3||File is modified: version B (same size as A)|
|X + 1||System clock ticks|
|X + 100||Tarsnap archives the file (version A) from the snapshot|
|Y||Another filesystem snapshot is created|
|Y + 100||Tarsnap 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:
Create a file (older than the snapshot) to serve as a reference time:
- Create a filesystem snapshot, and mount it as /mnt.
Run Tarsnap with the --snaptime option:
tarsnap --snaptime /tmp/snaptime -cf mybackupname /mnt
- Unmount the snapshot, and remove /tmp/snaptime.