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 <[email protected]> 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
