Amanda 2.6.0 only doing full backups

[nhwhite212]

I have upgraded to Amanda 2.6.0p1 on a Solaris 9 system. We have been running Amanda for years, but I really needed the ability to span large DLEs across multiple tapes. Amanda seems to be installed and running fine, EXCEPT
it always sees the DLEs as new and forces a level 0 backup. I have tried everything I can think of, changed permissions etc. It is updating curinfo( now in /usr/adm/amanda/... on every dump for every DLE, but then on the next dump run it sees it every DLE as new again, and hence can never get to a level 1 backup. This has to be something very simple, but I am stymied. Any ideas would be appreciated.

[dustin]

Do you have "record no" set? Have you checked that the client is generating gnutar incremental files correctly?

[nhwhite212]

I have
record yes
set globally,
and haven't touched the gnutar settings since 2.5.1.
As best I can tell it never asks for an incremental size even, since it ALWAYS sees the DLEs as new.

[dustin]

What message are you seeing that indicates it's a new DLE? If it's "Adding new disk foo:bar", then that's coming from a failure to find the disk in the curinfo database, as you surmised.

[nhwhite212]

Yes,
That is what it is seeing. The disks show up in curinfo, with their latest
throughput and compression rates, but the datestamp record does not get updated acts as if record is set to no. But it can obviously update curinfo/.../info, can't figure out why it doesn't record the datestamp information. Is the information in the info file recorded by different processes?

[dustin]

It really sounds like 'record' is not set to yes -- perhaps verify that with amadmin x config?

Otherwise, have a look through the driver debug logs to see if it's encountering any errors that would cause this?

[nhwhite212]

Record is set to yes for the dumptypes I am using, and I see no errors the log files. Any other ideas, I am ready to give up.

[dustin]

Nope -- I have never heard of this happening before. Actually, one thought: are your info files on a filesystem that would prohibit renaming a file for some reason?

[nhwhite212]

No, /usr/adm/amanda/DailySet1 is on a local file system. local file system. I just renamed an info file as a test (being user amanda, the backup user). No problem. Although I do think this must be a permissions problem somewhere.