dumps too big, full dump delayed / dumps too big, but cannot incremental

[skirmess]

(Amanda 3.2.0, Solaris 10/x86)

The following is what I'd like to achieve:
- Normal Amanda backup every day with a dumpcycle of 7 days
- Once a month do a full backup of every disk on the same day. This tapes will be marked as no-reuse and kept for an extended period.

I did the following by forcing full dumps with "amadmin force" once a month. That worked great until the tape wasn't big enough to hold all dumps. Now I would like to do the following.

- Normal Amanda backup every day with a dumpcycle of 7 days
- Once a month do a full backup of every disk on the same day. Write as many as possible to tape and keep the remaining in the holding disk. The next day, resume normal "Amanda operation" and flush the remaining level 0 from the holding disk to the tape. These two tapes will be marked as no-reuse and kept for an extended period.

But it is not working. When I use "amadmin force" I get a lot of these errors:

azati / lev 0 FAILED [dumps too big, 2701612 KB, but cannot incremental dump new disk]

Looks like Amanda falsely thinks that a forced level 0 is a new disk. And doesn't want to write the level 0 to the holding disk.

Then, I tried the following:

amdump -o DUMPTYPE:global:strategy=noinc lto3

and get messages like this:

planner: azati / 20101115021100 0 "[dumps too big, 2709094 KB, full dump delayed]"

> These dumps were to tape lto3-029.
> Not using all tapes because 1 tapes filled; runtapes=1 does not allow additional tapes.
> There are 122G of dumps left in the holding disk.
> They will be flushed on the next run.

> The next tape Amanda expects to use is: lto3-016.
> FAILURE DUMP SUMMARY:
> azati /l/v/ski lev 0 partial taper: 1 tapes filled; runtapes=1 does not allow additional tapes

dumpuser "amanda"
inparallel 4
dumporder "sssS"
taperalgo first
displayunit "g"
netusage  1000000 Kbps
dumpcycle 7 days
runspercycle 0
tapecycle 21 tapes
bumpsize 10000 Mb
bumppercent 20
bumpdays 30
bumpmult 4
dtimeout 10000
ctimeout 30
etimeout 10000
device_output_buffer_size 1280k
usetimestamps yes
flush-threshold-dumped 0
flush-threshold-scheduled 0
taperflush 0
autoflush yes
runtapes 1
tapedev "tape:/dev/rmt/0mn"
maxdumpsize -1
tapetype LTO-3
labelstr "^lto3-[0-9][0-9][0-9]"
amrecover_changer "changer"
holdingdisk hd1 {
        comment "main holding disk"
        directory "/var/opt/amanda/hold1"
        chunksize 0
        use -300 Gb
}
holdingdisk hd2 {
        comment "secondary holding disk"
        directory "/var/opt/amanda/hold2"
        chunksize 0
        use -80 Gb
}
reserve 30
infofile "/var/opt/amanda/lto3/curinfo"
logdir   "/var/opt/amanda/lto3/log"
indexdir "/var/opt/amanda/lto3/index"
define tapetype global {
    part_size 3G
    part_cache_type none
}
define tapetype LTO-3 {
        global
        comment "LTO-3"
        length 398336 mbytes
        filemark 0 kbytes
        speed 29364 kps
}
define dumptype global {
       comment "Global definitions"
       auth "bsd"
}
define dumptype kzone-dump {
    global
    program "DUMP"
    comment "partitions dumped with dump and compressed"
    index
    compress server best
    priority medium
}
define dumptype kzone-tar {
    global
    program "GNUTAR"
    comment "partitions dumped with tar and compressed"
    index
    compress server best
    priority medium
    exclude list "/etc/opt/amanda/lto3/exclude.gtar"
}
define dumptype FreeBSD73-kzone-tar {
    kzone-tar
    auth "ssh"
    ssh_keys "/var/opt/amanda/.ssh/id_dsa_amdump"
    amandad_path "/usr/local/libexec/amanda/amandad"
    client_username "operator"
    exclude list "/dev/null"
}
define dumptype kzone-tar-no-comp {
    kzone-tar
    compress none
}
define dumptype kzone-tar_azati-root {
    kzone-tar
    exclude list "/etc/opt/amanda/lto3/exclude.gtar.root"
}
define dumptype kzone-tar_estimate-server {
    kzone-tar
    estimate server
}
define interface local {
    comment "a local disk"
    use 8000 kbps
}
define application-tool app_amgtar {
    comment "amgtar"
    plugin  "amgtar"
}
define dumptype dt_amgtar {
    program "APPLICATION"
    application "app_amgtar"
}
define application-tool app_amstar {
    comment "amstar"
    plugin  "amstar"
}
define dumptype dt_amstar {
    program "APPLICATION"
    application "app_amstar"
}
define script-tool sc-email {
  comment "script-email"
  plugin  "script-email"
  execute_on pre-dle-amcheck, pre-host-amcheck, post-dle-amcheck, post-host-amcheck, pre-dle-estimate, pre-host-estimate, post-dle-estimate, post-host-estimate, pre-dle-backup, pre-host-backup, post-dle-backup, post-host-backup
  execute_where server
  property "mailto" "martinea"
}

[[email protected]]

Hi,

>But it is not working. When I use "amadmin force" I get a lot of these errors:

The "amadmin force" command will force a level 0 (full backup) on the next backup run, of all hosts/disks on the backup set. Hence you are getting all those "dumps too big" messages.

You can run the "amadmin force" command more selectively, and force the level 0 backups only for hosts/disks you know will fit on the tape:
$ amadmin <backup-set-name> force <hostA> <disk1> ;to force a level 0 only of disk1 on hostA

You are using "reserve 30", meaning that 30% of holding disk is reserved for incremental backups. Make sure that the remaining 70% is enough for the full backups, otherwise Amanda will not save the full backups into the holding disk.

Hope this helps a little.

Cheers,
Ed

[skirmess]

Thanks, Ed. I was just a little bit confused that "amadmin force" produces a different error message then "-o DUMPTYPE:global:strategy=noinc" although it was the same problem.

The noinc flag correctly reports "dumps too big, full dump delayed" which is correct.

But the "amadmin force" reports "but cannot incremental dump new disk" which is confusing as it isn't a new disk. The error message should be "[dumps too big, 2701612 KB, but cannot incremental dump a forced level 0]". But that's a minor issue. :)

I could solve my problem. The issue was the maxdumpsize parameter. It specifies the maximum number of bytes the planner will schedule for a run, regardless of if it's dumped to tape or kept in the holding disk. I changed it to "796672 mbytes" which is twice the size of my tape and it worked as expected.

Now what I found really misleading is this. This is from the amanda.conf man page:

     maxdumpsize int
         Default:  runtapes*tape-length. Maximum number of bytes
         the planner will schedule for a run.

         The default unit is Kbytes if it is not specified.

The problem is maxdumpsize was set in my amanda.conf file because I copied the example, therefore the default shouldn't matter. It was set to -1 and I expected -1 to be equal to unlimited. But it looks like -1 means "runtapes*tape-length" which was hard to guess for me.

Please consider changing the man page to something like this:

     maxdumpsize int
         Default: -1 which is equal to runtapes*tape-length.
         Maximum number of bytes the planner will schedule for a run.

         The default unit is Kbytes if it is not specified.