[OpenAFS] Incremental backups

[Stephen Joyce]

Have you tested it with plain "vos dump" (not TiBs synthetic backups)?

If what you say is true, great!, although it disagrees with the docs that I 
was reading. From the "vos dump" section of the Admin Reference:

--begin quote--

The following command writes a full dump of the volume user.terry to the 
file /afs/abc.com/common/dumps/terry.dump.

  % vos dump -id user.terry -time 0 -file /afs/abc.com/common/dumps/terry.dump

The following command writes an incremental dump of the volume user.smith 
to the file smith.990131.dump in the current working directory. Only those 
files in the volume with modification time stamps later than 6:00 p.m. on 
31 January 1999 are included in the dump.

    % vos dump -id user.smith -time "01/31/1999 18:00" -file smith.990131.dump

--endquote--

This wouldn't be the first case of the OpenAFS docs being incorrect or 
outdated...

Cheers, Stephen
--
Stephen Joyce
Systems Administrator                                            P A N I C
Physics & Astronomy Department                         Physics & Astronomy
University of North Carolina at Chapel Hill         Network Infrastructure
voice: (919) 962-7214                                        and Computing
fax: (919) 962-0480                               http://www.panic.unc.edu

The purpose of the icons, the purpose of the entire OS X look and feel, is
to keep the customer happy during that critical period between the time of
sale and the time the check clears.

On Fri, 25 Apr 2008, Kristen J. Webb wrote:

> Stephen Joyce wrote:
>
>> 
>> One other thing to be aware of is that giving the -time option to vos dump 
>> makes it look at the files' modification timestamps to determine what to 
>> back up. It's very possible to create a file with an old timestamp (using 
>> tar, touch, etc) so that it won't be caught by anything except a full 
>> backup. Mv'ing a file between volumes is an easy way to accidentally cause 
>> this. Just something to be aware of.
>
> The vos dump process does not look at unix time stamps to determine
> if a file needs to be backed up.  This is a nice feature of AFS.
> Any modification to the volume updates the volume time stamp, and
> if you keep track of these correctly, you'll get the new data even if
> the unix times would not predict that.
>
> I cp -p /usr/bin/filesize to my afs volume.  As you can see
> it is all of the unix times are from 2000:
>
> # stat filesize
>  File: `filesize'
>  Size: 68              Blocks: 2          IO Block: 4096   regular file
> Device: dh/13d  Inode: 80281630    Links: 1
> Access: (0755/-rwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
> Access: 2000-09-04 11:24:42.000000000 -0400
> Modify: 2000-09-04 11:24:42.000000000 -0400
> Change: 2000-09-04 11:24:42.000000000 -0400
>
> I then took an incremental backup of the volume and checked our
> file lookup database and the file is there:
>
> FILE                 68 Mon Sep  4 11:24:42 2000  afs|user.kwebb|/filesize
>
> If vos dump did not give us these older files consistently,
> our synthetic backup process would detect it.
>
> Kris
> -- 
> Mr. Kristen J. Webb
> Teradactyl LLC.
>
> PHONE: 1-505-242-1091
> EMAIL: kwebb@teradactyl.com
> VISIT: http://www.teradactyl.com
>
> 	Home of the
>
> True incremental Backup System
>