Only the first backup in disklist is made

[ndias]

Because the issue #222 was closed and I can«t open again, and the suggest is to open a new issue.

The issue at @#222 is a bug that should be resolved, it's not true this

"Due to multiple DLE entries, amanda is using degraded mode for the backups. Using a holdingdisk is mandatory in degraded mode."

Like I wrote in the issue, if i use multiple DLEs and a physical TAPE the holdding disk is not necessary and amanda doesn't complain about not having an holding disk.

From the man pages ...
"The amanda.conf file may define one or more holding disks used as buffers to hold backup images before they are written to tape."

may ... not MUST so it's optional.

[konidev20]

Hey @ndias,

We will check this out and see if there are any gaps in the documentation between 3.5.3 and 3.5.1. Thank you for your patience.

[tanstafel]

Just stumbled of the same issue. We upgraded from a CentOS 7 with amanda 3.3.3 to a Rocky9 with amanda 3.5.3 and our backup shows the same issue. We actually have a small holding disks to buffer some of the data from remote servers but most of the data to backup is already local. Now making the holdingdisk as large as the whole backup is ridiculous. This can't be right. Please provide a solution to this issue.

[tanstafel]

Just stumbled of the same issue. We upgraded from a CentOS 7 with amanda 3.3.3 to a Rocky9 with amanda 3.5.3 and our backup shows the same issue. We actually have a small holding disks to buffer some of the data from remote servers but most of the data to backup is already local. Now making the holdingdisk as large as the whole backup is ridiculous. This can't be right. Please provide a solution to this issue.

Ah, I made a mistake here. The DLEs that failed explicitly said "holdingdisk never". We did this because we did not want multiple parallel compressors (pigz) running which makes no real sense. For this I will find another solution or live with it. Sorry for the noise.

[tanstafel]

Just stumbled of the same issue. We upgraded from a CentOS 7 with amanda 3.3.3 to a Rocky9 with amanda 3.5.3 and our backup shows the same issue. We actually have a small holding disks to buffer some of the data from remote servers but most of the data to backup is already local. Now making the holdingdisk as large as the whole backup is ridiculous. This can't be right. Please provide a solution to this issue.

Ah, I made a mistake here. The DLEs that failed explicitly said "holdingdisk never". We did this because we did not want multiple parallel compressors (pigz) running which makes no real sense. For this I will find another solution or live with it. Sorry for the noise.

Spoke too soon: While removing the "holdingdisk never" is improved things - the large DLEs still do not work and complain with "out of holding space in degraded mode". So it looks like I really need a holding disk that fits the data of teh largest DLE. Most of this data is already present locally and it makes totally no sense that amanda copies this first to a holding disk and from there to the final destination. As I stated in my first post - this can't be right and there must be workable solution for this.

[jlbl1701]

I just upgraded my home server from Rocky8 (with amanda 3.5.1) to Fedora 42 (with amanda 3.5.4) and have hit this bug. My configuration wasn't using a holding disk and worked just fine with 3.5.1. With 3.5.4, only the first DLE gets backed up. If I add a small holding disk, then multiple DLEs work, but any backups bigger than the holding disk fail. As with the other user, have no need of a holding disk. This is clearly a regression. Please let us know how we can get this fixed. Thanks!

[konidev20]

I used a bit of GitHub Copilot surrounding this issue. The amanda.conf file might have changed between 3.x.x and 3.5.4 version.

Could you try a amanda.conf in this format?

org "SimpleBackup"
mailto "admin@example.com"
dumpuser "amanda"
inparallel 4
netusage 600 Kbps

# Storage block (new, replaces many tape-specific settings)
define tapetype LTO {
    length 80000 mbytes
    filemark 4 kbytes
}

define changer mydiskchanger {
    tpchanger "chg-disk:/var/lib/amanda/vtapes"
}

storage my-disk-storage {
    tapecycle 7 tapes
    tapedev "chg-disk:/var/lib/amanda/vtapes"
    tapetype LTO
    changer mydiskchanger
}

labelstr "^DailySet[0-9][0-9]*$"

define dumptype simple-dump {
    program "GNUTAR"
    compress none
    index yes
}

holdingdisk hd1 {
    directory "/var/lib/amanda/holding"
    use 1000 mbytes
    chunksize 1 mbyte
}

# Disklist example (not in amanda.conf)
# localhost /home simple-dump

The DLE file remains the same.

[jlbl1701]

Thanks for taking a look at this -- it's greatly appreciated!

The format above led to errors processing the config file. I got it to work by changing the storage block to look like this:

define tapetype HDD {
    length 600000 mbytes
}

define changer home-backup {
   tpchanger "chg-disk:/mnt/ext-backup/backup/amanda/tapes"
   property "num-slot" "10"
}

define storage HomeDaily {
   tapedev "chg-disk:/mnt/ext-backup/backup/amanda/tapes"
   tapetype HDD
   tpchanger home-backup
}

where HomeDaily is the name of the configuration.

However, this config still shows the same problem as my config which was previously working with 3.5.1. I was able to refine the symptoms a bit though:

• Without a holdingdisk, only a single DLE gets backed up. The rest show FAILED [can't do degraded dump without holding disk] in the amreport.
• With a holdingdisk, all dumps smaller than the holdingdisk work. Only 1 dump larger the holdingdisk works. Any remaining DLEs larger than the holdingdisk show FAILED [out of holding space in degraded mode].

So this still looks to be a regression. As I understand it, "Degraded" mode means that the tape device is absent and dumps must go to the holdingdisk. But that's not the case in this setup -- the tape device is working and dumps can make it there.
And a holdingdisk has never been required.

Let me know if I can provide any further info. Thanks again for looking into this.

[opoplawski]

FWIW - I hacked up an alternative for us in #281 that allows us to have parallel dumps and avoid the duplication of a final write to vtape.

I'm also poking into some "degraded mode" issues with that setup as well that might be related to this. If I ever figure anything out I'll post it.