Very Computer

Hello.

Why is Veritas Netbackup changing inode change timestamp on every
backuped file? Is it possible to change the Netbackup-configuration
in order to avoid changing inode change time?

I am running Veritas Netbackup version 3.2 GA on SunOS 5.6.

Legato Networker is not changing inode change time when doing backup.

       Best Regards

       National Land Survey of Sweden      Phone:  +46 26 633492
       80182 Gavle, SWEDEN                 Fax:    +46 26 120063

*************************************************************************

Because Netbackup is poorly designed in this respect.  A backup product
should be required to perform transparent backup and restores, like
Legato and vxdump, but apparently Netbackup was designed more as an
application program and not as a system utility so it has no ability to
do transparent I/O.  There are a couple of things you can do: (1) use
flashbackup from Veritas (costs more), (2) break a mirror (if you're
running VxVM) and backup the mirror, or (3) use snapshot filesystem to
create a point in time copy of the filesystem, back that up, then
discard it.  These are all bad workarounds; I think Veritas needs to
step up to this problem, especially if they want to market to the
serious datacenters which rely on timestamps, tripwire, etc., for
accountability.  Plus, ctime is a valuable piece of metadata that users
can rely on; it shouldn't be screwed with by a backup product.

I heard a rumor that Veritas filesystem will someday have "cloning"
which is like a very efficient snapshot capability.  This may solve
this problem but I haven't heard when it's coming.  The best solution
(in my opinion) would be for Netbackup to use transparent I/O for all
backups and restores (via raw device, DMAPI, or whatever the OS provides).

Quote:>   There are a couple of things you can do: (1) use flashbackup from
>   Veritas (costs more), (2) break a mirror (if you're running VxVM)
>   and backup the mirror, or (3) use snapshot filesystem to create a
>   point in time copy of the filesystem, back that up, then discard
>   it.  These are all bad workarounds; I think Veritas needs to step
>   up to this problem, especially if they want to market to the
>   serious datacenters which rely on timestamps, tripwire, etc., for
>   accountability.

Quote:>   Plus, ctime is a valuable piece of metadata that users can rely
>   on; it shouldn't be screwed with by a backup product.

Kjetil T.

DO_NOT_RESET_FILE_ACCESS_TIME

to the client bp.conf (at least you can in whatever version we are
testing), in which case the inode change timestamp won't change but
last access time will.  Since netbackup goes through the file system,
one or the other must be changed (unless you play the sort of tricks
with snapshots or clones (where supported) that others mentioned).

I *really* wish this option could be configured on a filesystem basis,
since we've different requirements for different kinds of filesystems,
but Veritas doesn't seem to have considered that possibility.
--

Wilson Lab, Cornell University      <URL:http://www.lns.cornell.edu/~dsr/>
    "History teaches us that days like this are best spent in bed"

1) The default. After having read the file and backed it up (and
   therefore having modified atime of the file), NetBackup resets the
   atime of the file (and therefore modifies ctime). IIRC, this is
   done to be able to cooperate nicely with HSM products

2) After having read the file and backed it up (and therefore having
   modified atime of the file), just leave everything as is and
   continue.

The second behaviour can be reached with a combination of 2 options in
bp.conf. Something like DONT_MODIFY_ATIME and
USE_CTIME_FOR_INCREMENTALS or somesuch. Read the docs to find out how
the options are called exactly.

--
joe

With the options described above Netbackup can preserve atime and mtime,
but only at the expense of ctime.  There is no option to preserve all the
timestamps.  This is a shortcoming of Netbackup since the timestamps are
valuable metadata that belong to the owner of the file.  If ctime is
preserved, it can be used to provide auditability to insure files have not
been tampered with (as with tripwire).  If it is changed by the backup then
it is useless for this purpose.

ufsdump can do so for example, or NetBackup with the FlashBack
option. But no tool can go through the filesystem and preserve all
three times.

--
joe

vxdump does it.  Veritas wrote that, why can't they do Netbackup the
same way?

Of course, it would still remain filesystem specific, i.e. that
feature would only work for VxFS, or for UFS on Solaris, or for XFS
for IRIX etc.etc.

Did you try the block incremental feature which Veritas offers for
NetBackup on VxFS filesystems? Maybe this one doesn't change any of
the [amc]time.

--
joe

Yes, we have asked for this.  Actually, I am holding out that filesystem
cloning (a feature like snapshot filesystem but more efficient) will solve
this problem.  I don't know when that is coming though.

|> Of course, it would still remain filesystem specific, i.e. that
|> feature would only work for VxFS, or for UFS on Solaris, or for XFS
|> for IRIX etc.etc.

I think vxdump and ufsdump accomplish it by reading the raw device.
I don't know of any standard API that addresses transparent I/O through
the raw device; in that case it would be filesystem-specific.

|> Did you try the block incremental feature which Veritas offers for
|> NetBackup on VxFS filesystems? Maybe this one doesn't change any of
|> the [amc]time.

I'll check into that.  I thought block incremental was only for
databases but I don't know why you couldn't use it for user files
as well.

Can NetBackup support two or more IP addresses on the master and/or
slave to allow more bandwidth from multiple NIC's through the same
master or slave?

Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.