On 2018-11-28 10:58, Chris Nighswonger wrote:
On Wed, Nov 28, 2018 at 10:49 AM Austin S. Hemmelgarn
<[email protected] <mailto:[email protected]>> wrote:
On 2018-11-28 09:53, Stefan G. Weichinger wrote:
> Am 28.11.18 um 15:47 schrieb Chris Nighswonger:
>> So why won't amanda dump and tape at the same time?
>
> It does normally, that is what the holding disk is for.
Really? I was under the impression that it was for making sure you can
finish dumps if something goes wrong with taping, and cache dumps so
they can be written to tape in one pass. Without a holding disk,
Amanda
dumps straight to tape, which is technically dumping and taping in
parallel.
>
> More details might lead to better suggestions.
>
> Show your amanda.conf etc
Indeed, though I suspect it's something regarding the flushing
configuration.
inparallel 10
maxdumps 1
# (equivalent to one Tbit/s).
netusage 1073741824
dumporder "STSTStstst"
dumpcycle 5 days
runspercycle 5
tapecycle 13 tapes
runtapes 1
flush-threshold-scheduled 50
flush-threshold-dumped 50
bumpsize 10 Mbytes
bumppercent 0
bumpmult 1.5
bumpdays 2
ctimeout 60
dtimeout 1800
etimeout 300
dumpuser "backup"
tapedev "Quantum-Superloader3-LTO-V4"
autolabel "$c-$b" EMPTY
labelstr "campus-.*"
tapetype LTO-4
logdir "/var/backups/campus/log"
infofile "/var/backups/campus/curinfo"
indexdir "/var/backups/campus/index"
tapelist "/var/backups/campus/tapelist"
autoflush all
holdingdisk hd1 {
comment "Local striped raid array"
directory "/storage/campus"
use 0 Gb
chunksize 1 Gb
}
define changer Quantum-Superloader3-LTO-V4 {
tapedev "chg-robot:/dev/sg3"
property "use-slots" "1-13"
property "tape-device" "0=tape:/dev/nst0"
device-property "LEOM" "TRUE"
}
define tapetype LTO-4 {
comment "Created by amtapetype; compression enabled"
length 794405408 kbytes
filemark 1385 kbytes
speed 77291 kps
blocksize 512 kbytes
}
Based on your configuration, your tapes are configured to store just
short of 800GB of data.
The relevant lines then are these two:
flush-threshold-scheduled 50
flush-threshold-dumped 50
The first one tells Amanda to not try flushing anything early if you
aren't using at least half a tape based on dump size estimates, and the
second one says that at least half a tape's worth of data must already
be dumped before flushing will start. Together, this means Amanda won't
flush anything to tape until all dumps are done unless you're dumping
more than half a tape's worth of data each run.
If you set those both to zero, Amanda will start flushing dumps to tape
as they finish. Doing so has two disadvantages for you because you're
using real tapes and not vtapes:
* You can't have Amanda intelligently pack the dumps onto the tape.
This probably doesn't matter as you appear to have things configured so
that each run only uses one tape and you haven't explicitly defined a
`tapealgo` (the default `tapealgo` is a simple dumb FIFO queue, so it
behaves the same as immediately flushing dumps as they finish).
* You run the risk of having to stop and restart the tape drive multiple
times while writing dumps. Put simply, by flushing at the end like
things are currently, you can gaurantee 100% utilization of the tape
drive while flushing dumps. If you flush them as they're done, the
taper will almost certainly have to wait for some dumps to finish after
it initially starts writing data.
In your case, I'd suggest figuring out the average amount of data you
dump each run, and then configuring things to start flushing when about
half that much data has been dumped. That will still have the taping
run in parallel with the dumping, but will give you enough of a buffer
that the taper should never have to wait for dumps to finish.
