fbackup effecting other 3rd party backups?

[David L Brewster]

We recently purchased backup software to perform jobs on our 12 machines all of which run HP-UX 11.
We continue to use fbackup for redundancy.
We have daily fbackup jobs performing a FULL system backup.
With our new application, we have a full backup running on Saturday's and incremental backups running Sunday-Friday.
We saw that our incremental backups were backing up almost 95% of a full system when modification times do not support this.
Several weeks of consulting with the vendor has yielded no solutions.
On one of our servers I removed the fbackup job. Now, that server's incremental backup is behaving as expected.
Somehow our 3rd party software thinks a file should be included in an incremental backup, but looking at the modification time of the file indicates otherwise.
Does fbackup somehow touch files without changing the modification time?
Does anyone have experience with fbackup effecting other backups in a similiar way?

[James R. Ferguson]

Hi David:

'fbackup' resets the lastaccess ('atime') of files it backs up. Thus, you will find that the 'ctime' [last inode timestamp change] *is* changed. The modifiction 'mtime' is seperate from either the 'atime' or 'ctime' and is *not* affected by 'fbackup'.

Regards!

...JRF...

[A. Clay Stephenson · Accepted solution]

fbackup uses its own database to keep up with the metadata and it only compare the file's mtime -- which is left intact. What I suspect is that your other unnamed backup software is looking also at a file's atime (access time). It's also possible that your backup is looking at the ctime.

Use the ls -c (change time) and -u (access time) option to examine these metadata as well and you may find your answer.

[Rodney Hills]

If you are using a backup system on a Windows PC and you are using samba to access the files with the backup software, then note that the DOS "Archive" bit is the Owner Execute bit of the permissions for a file.

Some PC based softwares use the Archive bit as a way to determine if a file should be included in an incremental or note.

HTH


-- Rod Hills

[David L Brewster]

Nice!
Our 3rd party software must be using the access time. Or at least it is not using the modification time.
# ls -l make.disks.lst
-rwxr-x--- 1 root sys 10450 Jan 6 12:07 make.disks.lst
# ls -lc make.disks.lst
-rwxr-x--- 1 root sys 10450 Jan 12 03:52 make.disks.lst
# ls -lu make.disks.lst
-rwxr-x--- 1 root sys 10450 Jan 11 04:38 make.disks.lst
#

I suppose there is no way to have fbackup reset the access time?

[James R. Ferguson]

Hi (again) David:

As I noted, 'fbackup' *does* reset the 'atime' (lastaccess timestamp) of files that it copies. This is the reason that the 'ctime' is *changed*.

An 'ls -lc' displays the 'ctime' as you saw for January 12. I suspect that your third-party software is being triggered by that attribute.

Regards!

...JRF...

[Steven E. Protter]

fbackup does lock the file while its backing it up. If its running at the same the other product is running this will produce an error.

Also the archive bit is set, because fbackup can track and do incremental backups itself.

I think this poses a problem for using your third party product.

The way we got around it (previous job) was do do a weekly fbackup full which we kept around for sysadmins to use and let Veritas do all the complex stuff involving incremental.

SEP

[David L Brewster]

Thanks to all for your help.
You all provided more information in the last 10 minutes than I have gotten from our vendor since November!!
Armed with this information, I will contact our vendor.
Thanks again!!