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: [EMAIL PROTECTED]
VISIT: http://www.teradactyl.com
Home of the
True incremental Backup System
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
