RFE: using rsync as a backup tool (preserve access time & com press destination files) ?

[tim.conway at philips.com]

The way gnutar "preserves" atime is by noting it before the read, and 
setting it back after the read, thus wiping out a legitimate setting of 
atime occuring during that interval.
Yeah, the netapps mess with unix times.  Did you notice that mtime and 
ctime always match?
Now that I know you're on a netapp, though, your problems are solved. 
Snapshot and sync from the snapshot, then expire the snapshot if your data 
is rapidly-changing, so it doesn't hold a bunch of old space.

Also, I just mounted up a netapp readonly (on a system also mounting same 
directory readwrite elsewhere).  even though it's readonly, the netapp 
sees the read and updates atime... however, I still like the snapshot 
idea.

Tim Conway 
conway.tim at spilihp.com reorder name and reverse domain 
303.682.4917 office, 303.921.0301 cell 
Philips Semiconductor - Longmont TC 
1880 Industrial Circle, Suite D 
Longmont, CO 80501 
Available via SameTime Connect within Philips, caesupport2 on AIM 
"There are some who call me.... Tim?" 




Gilles-Eric Descamps <Gilles-Eric.Descamps at SiliconAccess.com>
11/15/02 03:50 PM

 
        To:     Tim Conway/LMT/SC/PHILIPS at AMEC
        cc: 
        Subject:        RE: RFE: using rsync as a backup tool (preserve access time & com press 
destination files) ?
        Classification: 



> From: tim.conway at philips.com [mailto:tim.conway at philips.com]
> Sent: Wednesday, October 30, 2002 10:53 AM
> 
> It's not up to the application whether atime gets updated. 
> That's like 
> complaining about find making your hard drive light flash.
> The only thing rsync could do would be to note the atime 
> before reading 
> the file, then falsely set it back to what it was, after 
> reading the file, 
> and hope that it wasn't set to something else in the 
> interim... a kludge 
> at best. 

  Well, gnu tar provides a "--atime-preserve".
  All applications which backup filesystems (legato, quickrestore, 
budtools)
  preserve times on an application level.
  A backup tool is supposed to bypass normal filesystem access
  as it's supposed to be transparent.


> Why not mount the filesystem on an alternate mountpoint, noatime or 
> readonly?  On AIX, you can just mount the dir wherever.  In sun, and 
> apparently Linux, nfs export it, only to localhost, if you 
> like, and mount 
> it readonly.  As Chef Tell used to say, "very simple, very easy", and 
> legitimate setting of atime can continue unhindered.

  Because that does not work. I just tried it.
  The file server is a NetApp box running a proprietary OS (not unix, nor
windows).
  mounted the NFS filesystem with noatime & readonly,
  but guess what, when you read a file, the box updates the read time