Has amanda's handling of vtape changed ?
Hello!
It's me again with taking my vtapes based config from old Amanda 2.4.4
server to new Amanda 2.5.1p2 server. I have my tapetype definition set
so that one 160 GB partition is divided into 5x50GB vtapes. This is done
considering that on most nights Amanda doesn't really fill the vtape so
there is actually safe to write more than 160GB/5 to a vtape on some
other nights. The 50 GB limit is there just so Amanda doesn't plan too
many full dumps for any single run.
define tapetype HARDDISK {
comment "Backup to external HDD"
length 51200 mbytes
filemark 0 kbytes
speed 4 kbytes
}
On the old server this consideration seemed to hold true - on some
nights less than 40 GB got dumped, on some days even more than the 51200
MB specified in the tapetype (when Amanda miscalculated slightly). The
only time there was an "out of tape" error was when the external HDD
actually filled up.
Yesterday, I made the first amdump run on new server. Since amdump
hadn't been run for several days, Amanda tried to schedule as many full
backups as possible. Most of the DLEs were backed up successfully, but
the last one failed with
server Archive lev 1 FAILED [out of tape]
server Archive lev 1 FAILED [data write: Broken pipe]
server Archive lev 1 FAILED [dump to tape failed]
And the external HDD didn't fill up, it still has 40 GB free.
However the size of vtape from this amdump run is suspiciously close to
my "length" parameter:
# pwd
/backup/slot6
# du -m
51213 .
Hence my question: Does Amanda now enforce the "length" parameter when
writing to a vtape? In such a way that if "length" is reached in the
middle of taping the DLE then taping is stopped and "out of tape" announced?
Here's the end of amandad.debug from this run:
amandad: time 4353.619: stream_accept: connection from 12.34.56.78.1026
amandad: try_socksize: send buffer size is 65536
amandad: try_socksize: receive buffer size is 65536
amandad: time 4353.619: stream_accept: connection from 12.34.56.78.1026
amandad: try_socksize: send buffer size is 65536
amandad: try_socksize: receive buffer size is 65536
amandad: time 4353.619: stream_accept: connection from 12.34.56.78.1026
amandad: try_socksize: send buffer size is 65536
amandad: try_socksize: receive buffer size is 65536
security_close(handle=0x50d100, driver=0x80085d040 (BSD))
security_stream_seterr(0x527000, write error on stream 63480: Connection
reset by peer)
amandad: time 6183.197: sending NAK pkt:
<
ERROR write error on stream 63480: write error on stream 63480:
Connection reset by peer
>
And interestingly Amanda actually dumped core at the time which matches
the timestamp of this amandad.debug file:
Jan 26 01:26:20 server kernel: pid 40527 (amandad), uid 3951: exited on
signal 11 (core dumped)
Jan 26 01:26:20 server sendbackup[41450]: index tee cannot write [Broken
pipe]
Jan 26 01:26:20 server sendbackup[41447]: error [/usr/local/bin/gtar
returned 2, compress returned 1]
Jan 26 01:26:20 server inetd[16676]:
/usr/local/libexec/amanda/amandad[40527]: exited, signal 11
Here is also the relevant sendbackup.debug from the client (which is
actually the same as the server):
Could not open conf file "/usr/local/etc/amanda/amanda-client.conf": No
such file or directory
Reading conf file "/usr/local/etc/amanda/BACKUP/amanda-client.conf".
sendbackup: debug 1 pid 41447 ruid 3951 euid 3951: rename at Fri Jan 26
00:55:50 2007
sendbackup req: 2007:1:11:3:34:13 OPTIONS |;auth=BSD;compress-fast
;index;>
parsed request as: program `GNUTAR'
disk `Archive'
device `/storage/files/Archive'
level 1
since 2007:1:11:3:34:13
options `|;auth=BSD;compress-fast;index;'
sendbackup: start: server.domain.ee:Archive lev 1
sendbackup: time 0.000: spawning /usr/bin/gzip in pipeline
sendbackup: argument list: /usr/bin/gzip --fast
sendbackup-gnutar: time 0.001: pid 41449: /usr/bin/gzip --fast
sendbackup-gnutar: time 0.001: error opening
'/var/amanda/gnutar-lists/serverArchive_0': No such file or directory
sendbackup-gnutar: time 0.001: doing level 1 dump as listed-incremental
to '/var/amanda/gnutar-lists/serverArchive_1.new'
sendbackup-gnutar: time 0.005: doing level 1 dump from date: 1970-01-01
0:00:00 GMT
sendbackup: time 0.006: spawning /usr/local/libexec/amanda/runtar in
pipeline
sendbackup: argument list: runtar BACKUP GNUTAR --create --file -
--directory /storage/files/Archive --one-file-system
--listed-incremental /var/amanda/gnutar-lists/serverArchive_1.new
--sparse --ignore-failed-read --totals .
sendbackup-gnutar: time 0.007: /usr/local/libexec/amanda/runtar: pid 41451
sendbackup: time 0.007: started backup
sendbackup: time 0.007: started index creator: "/usr/local/bin/gtar -tf
- 2>/dev/null | sed -e 's/^\.//'"
sendbackup: time 1829.721: 118: strange(?):
sendbackup: time 1829.721: index tee cannot write [Broken pipe]
Re: amrecover problem
Eric Doutreleau wrote: Kevin Till a écrit : Axel Seguin wrote: Obviously the client tries to contact the server on port 10080, shouldn't it try to reach the server on port 10082? How can I change that? In ~/.amandahosts on the client I have : amdump Any help would be greatly appreciated. Hi, there is an update on Amanda 2.5.1. To enable different auth mechanism, amandad needs to run on the server. And it will start amindexd and amidxtaped accordingly. Please see http://wiki.zmanda.com/index.php/Configuring_bsd/bsdudp/bsdtcp_authentication well i have seen that but i have a lot of old amanda configuration and i would like to use "amoldrecover". amoldrecover will try to connect to port 10082 on the server. This particular server must run amindexd and amidxtaped in the Amanda 2.5.0 format. See: http://wiki.zmanda.com/index.php/Quick_start#Configuring_xinetd_on_server Hope this helps. -- Thank you! Kevin Till Amanda documentation: http://wiki.zmanda.com Amanda forums:http://forums.zmanda.com
DOH: taper exited with signal 1
Please ignore my previous message. I shouldn't have killed the terminal from which I started amdump! Amanda is still in testing on the new server so amdump doesn't run from cron yet. I started another amdump and it's happily taping now (until I manage to kill it again). -- Toomas Aas
Taper exited with signal 1
Hello! Moving to new server here with my Amanda setup using vtapes on external HDDs. Old server was FreeBSD 4.11, Amanda 2.4.4, GNU tar 1.13.25. New server is FreeBSD 6.2, Amanda 2.5.1p2, GNU tar 1.16. All my DLEs use GNU tar. Amcheck ran almost successfully on new server (one DLE reported "Permission denied"), but amdump failed for all DLEs with message "Dump to tape failed" and Notes section of Amanda report contains suspicious message "taper exited with signal 1". I wonder if this is the known problem with GNU tar 1.16 returning 1 if any file changes during backup, or is there something else fishy here? I suspect it's something else, because in case of GNU tar problem, the errors should be from dumper not taper? Original Message FAILURE AND STRANGE DUMP SUMMARY: server /storage/home lev 0 FAILED [dump to tape failed] server /storage/mail lev 0 FAILED [dump to tape failed] server /usrlev 0 FAILED [dump to tape failed] server /storage/dumps lev 0 FAILED [dump to tape failed] server /varlev 0 FAILED [dump to tape failed] server filesOZ lev 0 FAILED [dump to tape failed] server filesAN lev 0 FAILED [dump to tape failed] server / lev 0 FAILED [dump to tape failed] server Archive lev 1 FAILED [dump to tape failed] NOTES: planner: Last full dump of server:filesAN on tape LINT10 overwritten on this run. planner: Last full dump of server:filesOZ on tape LINT10 overwritten on this run. planner: Last full dump of server:Archive on tape LINT06 overwritten in 1 run. taper: Received signal 1 taper: Received signal 1 planner: server Archive 20070125224719 0 [dumps too big, 39024330 KB, full dump delayed] driver: taper pid 39526 exited with code 1 taper.debug file contains the following: === beginning of file === taper: debug 1 pid 39526 ruid 3951 euid 3951: start at Thu Jan 25 22:47:19 2007 taper: pid 39526 executable taper version 2.5.1p2 taper: debug 1 pid 39526 ruid 3951 euid 3951: rename at Thu Jan 25 22:47:19 2007 taper: page size = 4096 taper: buffer size is 32768 taper: buffer[00] at 0x800542000 taper: buffer[01] at 0x80054a000 taper: buffer[02] at 0x800552000 taper: buffer[03] at 0x80055a000 taper: buffer[04] at 0x800562000 taper: buffer[05] at 0x80056a000 taper: buffer[06] at 0x800572000 taper: buffer[07] at 0x80057a000 taper: buffer[08] at 0x800582000 taper: buffer[09] at 0x80058a000 taper: buffer[10] at 0x800592000 taper: buffer[11] at 0x80059a000 taper: buffer[12] at 0x8005a2000 taper: buffer[13] at 0x8005aa000 taper: buffer[14] at 0x8005b2000 taper: buffer[15] at 0x8005ba000 taper: buffer[16] at 0x8005c2000 taper: buffer[17] at 0x8005ca000 taper: buffer[18] at 0x8005d2000 taper: buffer[19] at 0x8005da000 taper: buffer structures at 0x8005e2000 for 480 bytes changer_query: changer return was 10 1 changer_query: searchable = 0 changer_find: looking for LINT10 changer is searchable = 0 taper: Building type 2 (TAPESTART) header of size 32768 using: taper: Contents of *(dumpfile_t *)0x7fffcb80: taper: type = 2 (TAPESTART) taper: datestamp= '20070125224719' taper: dumplevel= 0 taper: compressed = 0 taper: encrypted= 0 taper: comp_suffix = '' taper: encrypt_suffix = '' taper: name = 'LINT10' taper: disk = '' taper: program = '' taper: srvcompprog = '' taper: clntcompprog = '' taper: srv_encrypt = '' taper: clnt_encrypt = '' taper: recover_cmd = '' taper: uncompress_cmd = '' taper: encrypt_cmd = '' taper: decrypt_cmd = '' taper: srv_decrypt_opt = '' taper: clnt_decrypt_opt = '' taper: cont_filename= '' taper: is_partial = 0 taper: partnum = 0 taper: totalparts = 0 taper: blocksize= 32768 === end of file === Thanks for any ideas, -- Toomas Aas
Solaris amanda-2.5.1p2
Hi, I'm trying to compile amanda 2.5.1p2 in solaris 8 (sparc). I'm getting errors with libtermcap, but even after I dig in the google, and make configure like this, ./configure --with-user=amanda --with-group=sys --without-termcap --without-ltermcap --without-LIBTERMCAP --with-ncurses=yes --with-lncurses=yes --with-LIBNCURSES=yes The compilation crash with the same error, Text relocation remains referenced against symbol offset in file 0xa0c /usr/local/lib/libtermcap.a(tparam.o) 0xa10 /usr/local/lib/libtermcap.a(tparam.o) 0xa14 /usr/local/lib/libtermcap.a(tparam.o) 0xa18 /usr/local/lib/libtermcap.a(tparam.o) 0xa1c /usr/local/lib/libtermcap.a(tparam.o) 0xa20 /usr/local/lib/libtermcap.a(tparam.o) 0xa24 /usr/local/lib/libtermcap.a(tparam.o) can some one help ? Thank's ND -- Nuno Dias <[EMAIL PROTECTED]> LIP
Re: amrecover doesn't see all the index entries?
Hello, Anyone will have a poke at this? jf * Jean-Francois Malouin <[EMAIL PROTECTED]> [20070122 13:57]: > Hi, > > Last Friday a user managed to remove her entire home directory :) > so I started an amrecover session (2.5.1p2, client is the server, > irix-6.5) using the last full backup of the DLE (backed up with > xfsdump). This DLE while not that big (~70GB) has a lot of small files > (the uncompressed index file for the full shows ~1M entries). After a > few hours waiting for the prompt back from amrecover after doing the > setdisk I aborted the session, started a screen session and did the > whole thing again, and left work. Later at night I reattached to my > screen session and still nothing. Did the same thing Saturday morning > and finally got a prompt back. But while in amrecover I tried to cd > into the home of the user I got 'no such directory' or similar. > Checking the index file I see all her files. And doing a 'ls' at the > root of the DLE only shows part of the directory structure of the home > disk. To restore her files I had to use the baremetal restore command > 'dd if=<> skip=1 bs=32k | xfsrestore -i - .' Makes me a little > nervous. Any one has any idea what might be the problem? > > regards > jf -- <° ><
Re: Dilog Libra 8 - experience anyone?
Hi Stefan, /usr/libexec/chg-zd-mtx -info I get no slots available >>> >>>do you already have labled tapes in your tapelist available? And >>>assigned them to slots via amlabel? If not, chg-zd-mtx won't show any >>>available slots... >> >> Oh, a very good information ... >> >> Sure, I have a valid tapelist for the former config with the tapedrive >> only, but not for the changer. >> >> Is this information somewhere in the docs/manpages/howtos? >> If not I should add that somewhere. > >I assume this is not correct. i had a similar problem some days ago with a new setup where 'chg-zd- mtx -info' only listed a single tapeslot as available when i had labled only a single tape. It was resolved after i added 7 more tapes to the 8- tape-changer. That's why i thought you might have run into the same problem. I couldn't find anything about this behaviour in the docs (especially in the chg-zd-mtx script itself), so if this is the default it should probably be noted somewhere. greets, Kai
Re: amrecover problem
Kevin Till a écrit : Axel Seguin wrote: Obviously the client tries to contact the server on port 10080, shouldn't it try to reach the server on port 10082? How can I change that? In ~/.amandahosts on the client I have : amdump Any help would be greatly appreciated. Hi, there is an update on Amanda 2.5.1. To enable different auth mechanism, amandad needs to run on the server. And it will start amindexd and amidxtaped accordingly. Please see http://wiki.zmanda.com/index.php/Configuring_bsd/bsdudp/bsdtcp_authentication well i have seen that but i have a lot of old amanda configuration and i would like to use "amoldrecover". when i use that on a remote i got the following message on the amidxtaped.debug more amidxtaped.20070125103831.debug amidxtaped: debug 1 pid 9307 ruid 33 euid 33: start at Thu Jan 25 10:38:31 2007 amidxtaped: version 2.5.1p2 amidxtaped: time 0.000: read error: No such file or directory amidxtaped: time 0.000: pid 9307 finish time Thu Jan 25 10:38:32 2007 on the backup server it works well
