Stephen Joyce wrote:
Have you tested it with plain "vos dump" (not TiBs synthetic backups)?
Yes, vos dump ... -time ... is what we use to obtain the incremental dumps. I believe the decision to send a file to backup is based on the vnode:uniquifier data, but I haven't dug into the code on the volserver side to figure that out yet.
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.dumpThe 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|/filesizeIf 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
-- 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
smime.p7s
Description: S/MIME Cryptographic Signature
