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
On Sat, Oct 9, 2010 at 4:02 PM, Gunnarsson, Gunnar
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
> /var/opt/lib/amanda/gnutar-lists/hansabck_1.new
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 12:22 PM, Gunnarsson, Gunnar
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
your default tapetype.
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 8:21 AM, Gunnarsson, Gunnar
wrote:
>>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 {
No, it needs to be in the tapety
>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
On Fri, Oct 8, 2010 at 5:42 PM, Gunnarsson, Gunnar
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 550% longer than you h
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
/tmp/amanda/client/hansa/amgtar.
On Fri, Oct 8, 2010 at 1:11 PM, Gunnarsson, Gunnar
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 finished.
> Tape usage
On Fri, Oct 8, 2010 at 1:11 PM, Gunnarsson, Gunnar
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
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: E
12 matches
Mail list logo