Re: Using the --snaptime option

[Nick Sivo <nick@ycombinator.com>]

I asked Colin about this earlier, and have included his email below.
Since ZFS tracks when the snapshot was taken, I use the following in a
zsh script to create the file:

  snaptimetemp=`mktemp /tmp/snaptime.XXXXXXXXXXXX`
  latest=<get the name of the snapshot to backup>
  timestamp=`zfs get -Hp -o value creation $latest`
  log "Snapshot creation timestamp: $timestamp (`date -jr $timestamp`)"
  touch -t `date -jr $timestamp '+%Y%m%d%H%M.%S'` "$snaptimetemp"
  tarsnap -c --keyfile "$2" -f "$latest" --snaptime "$snaptimetemp"
--print-stats --totals "$backuproot"

You're really just interested in the timestamp and touch parts, but I
included the rest for context.

===========
Colin's Reply:
===========

Hi Nick,

On 04/29/13 13:57, Nick Sivo wrote:
> I'm working on setting up nightly backups of our live server.  We run
> FreeBSD and I've configured a nightly UFS snapshot to be taken, and
> I'd like to back up some directories from that snapshot.  Can I just
> mount it and point tarsnap to the right place?  Do I need the
> --snaptime option?  If so, can I just set it to the timestamp of the
> snapshot itself?

You need the --snaptime option, and it should point at something with a
modification time prior to when the snapshot creation started.  The
easiest way to do this is probably to touch a file on the filesystem
immediately before taking the snapshot, then to use that file as the
snaptime marker.

> To the best of my knowledge tarsnap shouldn't need to know that it's
> reading from a snapshot, but I figured I'd ask since there's an
> option.

This is necessary because of Tarsnap's "this file hasn't changed since I
last read it so I won't waste time re-reading it" logic.  Normally if a
file has the same path, size, inode #, and modification time, Tarsnap
assumes that it hasn't changed and doesn't need to be re-read; but the
file times have limited precision, so the following situation is possible:

t=12345.0001: file is modified
t=12345.0100: tarsnap reads file
t=12345.0500: file is modified again
t=54321.0000: tarsnap is run again and encounters file again

in which case the second tarsnap run will see a timestamp of "12345" even
though it's a "later" 12345.

To prevent this race condition, tarsnap flags files which with modification
times equal to when tarsnap is running; however, that doesn't work in the
following case:

t=12345.0001: file is modified
t=12345.0100: filesystem snapshot #1 is created
t=12345.0500: file is modified again
t=13000.0000: tarsnap is run against filesystem snapshot #1
t=50000.0000: filesystem snapshot #2 is created
t=54321.0000: tarsnap is run against filesystem snapshot #2

since both snapshots will show the file with an mtime of 12345.  Tarsnap
uses the snaptime marker to identify cases like this.

In short: It's a sneaky race condition which you'd have to be very unlucky
to hit, but using the --snaptime option allows tarsnap to identify when it
might be running into the race and play it safe instead.

On Thu, Jan 23, 2014 at 3:43 AM, Albert Peschar <albert@peschar.net> wrote:
> Hi all,
>
>
>
> I've been using tarsnap for some months to do all kinds of backups.
>
> Now, I'd like to use tarsnap to archive ZFS filesystem snapshots. What
>
> is unclear to me is whether and how I should be using the --snaptime
>
> option.
>
>
>
> From the manual:
>
>
>
>      --snaptime file
>
>              (c mode only) This option MUST be specified when
>
>              creating a backup from a filesystem snapshot, and
>
>              file must have a modification time prior to when
>
>              the filesystem snapshot was created.  (This is nec‐
>
>              essary to prevent races between file modification
>
>              and snapshot creation which could result in tarsnap
>
>              failing to recognize that a file has been modi‐
>
>              fied.)
>
>
>
> Should I just specify any file that hasn't been modified during the
>
> snapshot?
>
>
>
> And would someone be willing to explain why this is at all necessary?
>
>
>
>
>
> Thanks,
>
>
>
> Albert