Results 1 to 9 of 9

Thread: Amanda 2.6.0 only doing full backups

  1. #1

    Default Amanda 2.6.0 only doing full backups

    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.

  2. #2
    Join Date
    Mar 2007
    Location
    Chicago, IL
    Posts
    688

    Default

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

  3. #3

    Default full Backups only

    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.

  4. #4
    Join Date
    Mar 2007
    Location
    Chicago, IL
    Posts
    688

    Default

    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.

  5. #5

    Default

    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?

  6. #6
    Join Date
    Mar 2007
    Location
    Chicago, IL
    Posts
    688

    Default

    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?

  7. #7

    Default

    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.

  8. #8
    Join Date
    Mar 2007
    Location
    Chicago, IL
    Posts
    688

    Default

    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?

  9. #9

    Default

    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.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •