We are using Norton AV Enterprise 7.01 to scan our filer via CIFS. We have found that as Norton scans each file, the inode change time (i.e. ls -lc) gets set to the current time. I think it is due to Norton messing with the DOS archive bit, but I am not sure.
The problem is that this turns our level 1 ndmp dumps into virtual level 0 dumps. It seems that ndmp uses the inode change time, not the file modification time, as a basis for picking which files to dump during level 1's.
Any suggestions ?
We are using Norton AV Enterprise 7.01 to scan our filer via CIFS. We have found that as Norton scans each file, the inode change time (i.e. ls -lc) gets set to the current time. I think it is due to Norton messing with the DOS archive bit, but I am not sure.
The problem is that this turns our level 1 ndmp dumps into virtual level 0 dumps. It seems that ndmp uses the inode change time, not the file modification time, as a basis for picking which files to dump during level 1's.
Any suggestions ?
Hi Paul --
You're encountering what we listed as burt 17767: RFE: Option to exclude files with ctime changed from filer incremental dumps, since Virus Checkers using CIFS often causes unwanted ctime changes.
On your filer console, just type : filer> ndmpd ignore_ctime ignore ctime comparison set to: true
(And if you want to toggle it off ...) filer> ndmpd ignore_ctime ignore ctime comparison set to: false
By doing this, the filer will only check for changed mtimes, not ctimes on incremental backups.
Burt 17767 is ONLINE, but the NDMP version of the workaround is not yet included in the burt description. But I just gave it to you, so there's no reason to worry.
Of course, you may want to look at the NOW site to make sure you have the right version of Ontap, etc...
Stephen Manley DAM And NDMP James Joyce groupie
We are using Norton AV Enterprise 7.01 to scan our filer via CIFS. We have found that as Norton scans each file, the inode change time (i.e. ls -lc) gets set to the current time. I think it is due to Norton messing with the DOS archive bit, but I am not sure.
The problem is that this turns our level 1 ndmp dumps into virtual level 0 dumps. It seems that ndmp uses the inode change time, not the file modification time, as a basis for picking which files to dump during level 1's.
Any suggestions ?
Dump looks at both the mtime and the ctime when deciding to copy a file during an incremental dump. If either have changed then the file needs to be dumped.
The following change the ctime, but do not change any file data, and hence do not change the mtime:
rename file change owner/group of file change permissions of file
Some folks are unhappy when a virus scanner trips all the atimes (last read access) on all files. You lose valuable info about which files have not been read in a long time, because the scanner reads them often. So some virus scanners save the atime and put it back. But this trips the ctime, which causes all files to be copied by an incremental dump.
If you can configure your scanner to not preserve the atime, that would will fix it, but all your atimes will be tripped by the scanner.
I belive that netapp's NDMP dump has a flag or option where you can tell it to ignore ctime and only use mtime when doing an incremental dump. The downside is that an incremental dump will skip files that you probably want dumped. In addition to the cases listed above, if you un-tar or unzip an archive, the resulting files will have their old mtimes preserved, which may cause an incremental dump to skip them. This is not a problem when dump uses mtime and ctime, because the ctime is tripped when tar or unzip restores a file.
Steve Losen scl@virginia.edu phone: 804-924-0640
University of Virginia ITC Unix Support
Hey Paul.
We use NAI (McAfee) for Linux here and I wrote a little script that directs the scanner what to scan (ie, to avoid snapshots etc). It has a handy dandy switch to preserve atimes. I'd suspect NAV has something similar. In fact, I just poked around their support site (I'm considering switching AV providers) and they have this to say in the release notes for Norton AV Corporate 7.03:
Issue: Manual and Scheduled Scans would alter the "Last Modified" timestamp on some types of files (most commonly, text files). In some specific cases, this caused problems with certain file archiving, backup, and compare tools. Resolution: Scans no longer change this date.
Is that not the case? I'd be very surprised if they don't have some way around this. While I appreciate the thoughts of the other folks that say "just ignore atime", it seems there should be (and in fact there is for McAfee customers) another and better way around this - just don't touch it to begin with. Is there some other reason that ignoring atimes is important that I'm just not getting??
-Dustin
On Tue, Jan 30, 2001 at 02:58:40PM -0500, Paul Letta wrote:
We are using Norton AV Enterprise 7.01 to scan our filer via CIFS. We have found that as Norton scans each file, the inode change time (i.e. ls -lc) gets set to the current time. I think it is due to Norton messing with the DOS archive bit, but I am not sure.
The problem is that this turns our level 1 ndmp dumps into virtual level 0 dumps. It seems that ndmp uses the inode change time, not the file modification time, as a basis for picking which files to dump during level 1's.
Any suggestions ?
Here is the problem with virus scanners and the netapp.
1) virus scanners must read a file to check it for viruses.
2) This trips the atime on the file. The filer does this whether you like it or not. You can configure a filer to NEVER trip atimes with: vol options volname no_atime_update=on But if atimes matter to you, then why would you do this?
3) Some folks object to having the atimes of all files tripped by a virus scanner.
4) To solve 3, some virus scanners save the atime before reading a file and put it back when they are done.
5) On a netapp, when you do 4, it trips the ctime.
6) Under normal circumstances, an incremental dump copies all files whose mtime or ctime has changed.
7) Because of 4, 5, and 6, incremental dumps become full dumps, essentially.
8) Netapp's NDMP dump has an option to ignore ctime. I don't think this is a good idea because this causes dump to skip files that really should be dumped. If you rename a file, change its owner/group, or change its permissions, you probably want that change reflected in a dump. But these operations only trip ctime, not mtime. Also, if you read files from a tar or zip archive, the old mtimes are preserved, so dump may skip these files.
The simplest solution is probably to run the AV scanner on a snapshot, which is strictly read only, so it's impossible for the scanner to change any file timestamps. The scanner may require some configuration to run in a read-only environment.
Hey Paul.
We use NAI (McAfee) for Linux here and I wrote a little script that directs the scanner what to scan (ie, to avoid snapshots etc). It has a handy dandy switch to preserve atimes. I'd suspect NAV has something similar. In fact, I just poked around their support site (I'm considering switching AV providers) and they have this to say in the release notes for Norton AV Corporate 7.03:
Issue: Manual and Scheduled Scans would alter the "Last Modified" timestamp on some types of files (most commonly, text files). In some specific cases, this caused problems with certain file archiving, backup, and compare tools. Resolution: Scans no longer change this date.
Is that not the case? I'd be very surprised if they don't have some way around this. While I appreciate the thoughts of the other folks that say "just ignore atime", it seems there should be (and in fact there is for McAfee customers) another and better way around this - just don't touch it to begin with. Is there some other reason that ignoring atimes is important that I'm just not getting??
-Dustin
On Tue, Jan 30, 2001 at 02:58:40PM -0500, Paul Letta wrote:
We are using Norton AV Enterprise 7.01 to scan our filer via CIFS. We have found that as Norton scans each file, the inode change time (i.e. ls -lc) gets set to the current time. I think it is due to Norton messing with the DOS archive bit, but I am not sure.
The problem is that this turns our level 1 ndmp dumps into virtual level 0 dumps. It seems that ndmp uses the inode change time, not the file modification time, as a basis for picking which files to dump during level 1's.
Any suggestions ?
Steve Losen scl@virginia.edu phone: 804-924-0640
University of Virginia ITC Unix Support
- Netapp's NDMP dump has an option to ignore ctime. I don't think this is a good idea because this causes dump to skip files that really should be dumped. If you rename a file, change its owner/group, or change its permissions, you probably want that change reflected in a dump. But these operations only trip ctime, not mtime. Also, if you read files from a tar or zip archive, the old mtimes are preserved, so dump may skip these files.
Steve -- One quick note. Starting in the 6.0 version of Ontap, incremental dumps will detect when new files are added to a tree and back those up as well -- even if the mtime is set back to an old date.
Furthermore, renaming a file actually changes the directory. You have to remove an entry and add an entry. This changes the mtime on the directory (or directories if you move from one dir to another). Thus, dump has always captured the changed names.
So, by turning ctime checking off you will "only" lose the changed permissions, uid/gid of a file. It's up to the user to decide how comfortable they are with that setup.
Stephen Manley DAM and NDMP Groundhog
P.S. As an example of what I mean by the renames, check out the examples below
cherryhill:/u/stephen/foobar(22) ls -lm total 8 drwxrwxr-x 2 stephen 4096 Jan 31 08:35 testdir drwxrwxr-x 2 stephen 4096 Jan 31 08:35 testdir2 cherryhill:/u/stephen/foobar(23) ls -lm testdir total 0 -rw-rw-r-- 1 stephen 0 Jan 31 08:35 old_name cherryhill:/u/stephen/foobar(24) mv testdir/old_name testdir2/new_name cherryhill:/u/stephen/foobar(25) ls -lm total 8 drwxrwxr-x 2 stephen 4096 Jan 31 08:37 testdir drwxrwxr-x 2 stephen 4096 Jan 31 08:37 testdir2 cherryhill:/u/stephen/foobar(26) ls -lm testdir2/ total 0 -rw-rw-r-- 1 stephen 0 Jan 31 08:35 new_name
As you can see - the file mtime hasn't changed, but the DIRECTORIES' mtimes HAVE changed. Thus, dump will capture the remove from testdir and the add to testdir2
cherryhill:/u/stephen/foobar(27) mv testdir2/new_name testdir2/really_new_name cherryhill:/u/stephen/foobar(28) ls -lm total 8 drwxrwxr-x 2 stephen 4096 Jan 31 08:37 testdir drwxrwxr-x 2 stephen 4096 Jan 31 08:39 testdir2 cherryhill:/u/stephen/foobar(29) ls -lm testdir2/ total 0 -rw-rw-r-- 1 stephen 0 Jan 31 08:35 really_new_name
Once again, by renaming the file within the directory, the file's mtime stays unchanged, but the DIRECTORY'S mtime is updated.
-
Dustin Mollo -
Paul Letta -
Stephen Manley -
Steve Losen