This has worked in all previous version of Amanda.
.
Ah, so this is using the amzfs-snapshot scripts?
Jean-Louis, did something change here? I don't recall if we have a way for a
script to change the diskdevice for a DLE? Did that work in
3.1 and not in 3.2?
Tnanks Gunnar Gunnarson
OK. You should adjust the length in your tapetype definition, then - your
tape appears to be at least 550% longer than you have configured.
Can I add the tape length to:
define changer vault {
tpchanger chg-manual
tapedev tape:/dev/rmt/0n
changerfile changer.conf
}
Not sure
ok then I must overide the tapetype def with -o option in the amvault command.
No, it needs to be in the tapetype. It's weird, I know, but there are some
difficult problems with combining those two sections.
Thanks Gunnar Gunnarsson
On Sat, Oct 9, 2010 at 12:22 PM, Gunnarsson, Gunnar
gunnar.gunnars...@svk.se wrote:
ok then I must overide the tapetype def with -o option in the amvault command.
I'm not sure about that. Your amvault run demonstrated that your
tapes can actually hold almost 6 times the data you've suggested in
Snapshot is created but not used see below in 3.2.0beta3
Sat Oct 9 22:23:08 2010: amgtar: Spawning /usr/local/bin/tar
/usr/local/bin/tar --create --verbose --file - --directory / --one-file-system
--no-check-device --listed-incremental
/var/opt/lib/amanda/gnutar-lists/hansabck_1.new --sparse
On Sat, Oct 9, 2010 at 4:02 PM, Gunnarsson, Gunnar
gunnar.gunnars...@svk.se wrote:
Sat Oct 9 22:23:08 2010: amgtar: Spawning /usr/local/bin/tar
/usr/local/bin/tar --create --verbose --file - --directory /
--one-file-system --no-check-device --listed-incremental
Is this because amvault is considered a flush ?
Tape usage statistic is rather odd as well.
Otherwise is seems to work quite well - good work !
Thanks Gunnar Gunnarsson
*** THE DUMPS DID NOT FINISH PROPERLY!
The dumps were vaulted to tape EMS1-71.
The next 2 tapes Amanda expects to use are:
On Fri, Oct 8, 2010 at 1:11 PM, Gunnarsson, Gunnar
gunnar.gunnars...@svk.se wrote:
Is this because amvault is considered a flush ?
Tape usage statistic is rather odd as well.
Can you send the trace log that generated this report?
Dustin
--
Open Source Storage Engineer
http://www.zmanda.com
On Fri, Oct 8, 2010 at 1:11 PM, Gunnarsson, Gunnar
gunnar.gunnars...@svk.se wrote:
Is this because amvault is considered a flush ?
..
*** THE DUMPS DID NOT FINISH PROPERLY!
No, it was a bug - amvault didn't write the FINISH driver line
before calling amreport, so amreport didn't think it was
No I was wrong about it only delayed the flushing until at the end. Is that a
new behaviour in versioh 3.2.0 ?
The only problem I got was on the client side for the root filesystem zfs.
/-- hansabck / lev 1 FAILED [/usr/local/bin/tar exited with status 2: see
On Fri, Oct 8, 2010 at 5:42 PM, Gunnarsson, Gunnar
gunnar.gunnars...@svk.se wrote:
No is a HP Ultrium LTO 3 tape drive:
Yes I think the data was written to tape I will verify that next week.
OK. You should adjust the length in your tapetype definition, then -
your tape appears to be at least
11 matches
Mail list logo
