amrecover issue with tar and spaces
Hello, Seems to be an issue with amrecover within a DLE that contain spaces. This particular incident came to light on a volume that is being backed up via TAR. I have not tried to reproduce with Dump. As you can see from the snippets below, the output is being mangled a bit. Dropping off leading characters. If you know what the file structure is suppose to be, you can cd down into the dir by specifying it's real name. Extraction and recovery seems to work as well. I ended up just extracting the whole directory above where the issue starts. All files were recovered successfully. Just thought I'd throw it out for the developers to see. I'm a revision behind on 2.5.1p1, so please forgive me if this has been addressed. I'm using GNUtar 1.13.25, on FreeBSD 4.7 -Steffan amrecover cd Operating Plans /nfs/snap/NS_Novell/VOL1/RestOfVOL1/NS_Business_Plan/Operating Plans amrecover ls 2006-11-12-09-12-51 06 Operating Plans/ 2006-11-12-09-12-51 06 Manager Scorecard/ amrecover cd 0506 Operating Plans /nfs/snap/NS_Novell/VOL1/RestOfVOL1/NS_Business_Plan/Operating Plans/0506 Operating Plans amrecover ls 2006-11-12-09-12-51 4 Dept Ops Plan.xls 2006-11-12-09-12-51 3 Dept Ops Plan.xls 2006-11-12-09-12-51 1 Dept Ops Plan.xls A snippet of the Index file shows everything is fine within the file. /NS_Business_Plan/Operating Plans/0506 Operating Plans/61141 Dept Ops Plan.xls /NS_Business_Plan/Operating Plans/0506 Operating Plans/61151 Dept Ops Plan.xls /NS_Business_Plan/Operating Plans/0506 Operating Plans/61161 Dept Ops Plan.xls /NS_Business_Plan/Operating Plans/0506 Operating Plans/61171 Dept Ops Plan.xls /NS_Business_Plan/Operating Plans/0506 Operating Plans/61212 Dept Ops Plan.xls
upgrade to Amanda 2.5.1p1 issues
Hello all,
Having what I think are bsd auth issues after upgrading from 2.4.4b1.
The server is running FreeBSD 4.7.
Regarding the new needed pieces for 2.5x, I've added some items to my
inetd.conf file, but am unsure about what the syntax look like for the
only_from section for inetd, or if it's even needed? There is no
clear example in the wiki or docs:
(http://wiki.zmanda.com/index.php/Configuring_bsd/bsdudp/bsdtcp_authentication).
They only show xinetd.conf samples.
Here's what I have:
amanda dgram udp waitoperator
/usr/local/libexec/amandad amandad -auth=bsd amdump amindexd amidxtaped
amandaidx stream tcp nowait operator
/usr/local/libexec/amindexd amindexd -auth=bsd amdump amindexd
amidxtaped
amidxtape stream tcp nowait operator
/usr/local/libexec/amidxtaped amidxtaped -auth=bsd amdump amindexd
amidxtaped
not sure where it would fit in. Can't get amcheck to stat the local
server (which is getting backed up as well as backing up clients.) All
remote machines report back ok, but the host does not. Tailing the
messages file shows:
Nov 6 00:39:40 phatb inetd[34046]: /usr/local/libexec/amandad[34305]:
exit status 0x100
Nov 6 00:39:40 phatb inetd[34046]: /usr/local/libexec/amandad[34306]:
exit status 0x100
Nov 6 00:39:40 phatb inetd[34046]: /usr/local/libexec/amandad[34307]:
exit status 0x100
Nov 6 00:39:40 phatb inetd[34046]: amanda/udp server failing
(looping), service terminated
With hundreds of the first few lines. Then I have to HUP inetd to get
it to try again. here's a piece of the debug file from the amcheck:
amcheck-clients: dgram_send_addr(addr=0xbfbf74b8, dgram=0x280d7d84)
amcheck-clients: time 10.084: (sockaddr_in *)0xbfbf74b8 = { 2, 10080,
216.103.190.98 }
amcheck-clients: dgram_send_addr: 0x280d7d84-socket = 4
amcheck-clients: dgram_send_addr(addr=0xbfbf74b8, dgram=0x280d7d84)
amcheck-clients: time 20.094: (sockaddr_in *)0xbfbf74b8 = { 2, 10080,
216.103.190.98 }
amcheck-clients: dgram_send_addr: 0x280d7d84-socket = 4
security_seterror(handle=0x8063200, driver=0x280d6da0 (BSD)
error=timeout waiting for ACK)
security_close(handle=0x8063200, driver=0x280d6da0 (BSD))
amcheck: pid 34323 finish time Mon Nov 6 00:42:04 2006
amrecover exhibits the same issues:
amrecover: debug 1 pid 33549 ruid 0 euid 0: start at Mon Nov 6
00:32:47 2006
Reading conf file /usr/local/etc/amanda/amanda-client.conf.
Reading conf file /usr/local/etc/amanda/all.archive/amanda-client.conf.
amrecover: debug 1 pid 33549 ruid 0 euid 0: rename at Mon Nov 6
00:32:47 2006
security_getdriver(name=bsd) returns 0x280b5da0
security_handleinit(handle=0x8063100, driver=0x280b5da0 (BSD))
amrecover: bind_portrange2: Skip port 572: Owned by sonar.
-snip-
amrecover: bind_portrange2: Skip port 600: Owned by ipcserver.
amrecover: bind_portrange2: Try port 601: Available - Success
amrecover: dgram_bind: socket bound to 0.0.0.0.601
amrecover: dgram_send_addr(addr=0xbfbff96c, dgram=0x280b6d84)
amrecover: (sockaddr_in *)0xbfbff96c = { 2, 10080, 216.103.190.98 }
amrecover: dgram_send_addr: 0x280b6d84-socket = 3
amrecover: dgram_send_addr(addr=0xbfbff60c, dgram=0x280b6d84)
amrecover: (sockaddr_in *)0xbfbff60c = { 2, 10080, 216.103.190.98 }
amrecover: dgram_send_addr: 0x280b6d84-socket = 3
amrecover: dgram_send_addr(addr=0xbfbff60c, dgram=0x280b6d84)
amrecover: (sockaddr_in *)0xbfbff60c = { 2, 10080, 216.103.190.98 }
amrecover: dgram_send_addr: 0x280b6d84-socket = 3
security_seterror(handle=0x8063100, driver=0x280b5da0 (BSD)
error=timeout waiting for ACK)
security_close(handle=0x8063100, driver=0x280b5da0 (BSD))
In the past, we never had a amanda-client.conf file, but I've added
one with a single entry:auth bsd.
I also adjusted the .amandahosts file to add the service entries:
(xxx's are obviously not xxx's)
216.xxx.xxx.xx amanda amindexd amidxtaped amdump
216.xxx.xxx.xx root amindexd amidxtaped amdump
Still no luck. Where else should I look?
Thanks
-Steffan
Re: upgrade to Amanda 2.5.1p1 issues
man hosts.allow inetd in FreeBSD has got tcpwrappers built in. Example: amandad : 1.2.3.4 : allow amandad : ALL : deny Thanks for the reply, Unfortunately, that wasn't it. I already had entries in hosts.allow and even adjusted it to amandad: ALL :allow. Still no go. Also, I think if that was it, I'd see an You are not authorized to use... in the logs and not these: Nov 6 07:18:40 phatb inetd[82282]: /usr/local/libexec/amandad[82539]: exit status 0x100 Nov 6 07:18:40 phatb inetd[82282]: /usr/local/libexec/amandad[82540]: exit status 0x100 Nov 6 07:18:40 phatb inetd[82282]: /usr/local/libexec/amandad[82541]: exit status 0x100 Nov 6 07:18:40 phatb inetd[82282]: /usr/local/libexec/amandad[82542]: exit status 0x100 Nov 6 07:18:40 phatb inetd[82282]: amanda/udp server failing (looping), service terminated Any other thoughts? Thanks again -S
Re: upgrade to Amanda 2.5.1p1 issues
Thanks for the feedback. Went back and re-checked all the items on the list here: http://wiki.zmanda.com/index.php/Amcheck:_selfcheck_request_failed Fired it back up and it work. I must have had something fat fingered. Thanks -S
Re: Question about holding disk
cd dump_dir rm * amcleanup config_name (not sure you even need this) Lars Bakker wrote: Can anyone tell me how to remove old backups from holding disk?
Re: Looooooooong backup
Sometimes on my FreeBSD box 'amstatus' output doesn't change during really long dumps. I've found the best way to find out if it's still running is to use the 'ps' command and grep for the phrase 'done' ie: 'ps -ax | grep done' Dump does a good job of reporting back how far it thinks it is in the process. ie:78% done -S
dual tape drives, 1 changer, two configs
I have a dual tape drive capable auto-changer that I was planning to add a second drive to in order to increase throughput and thereby decrease the backup window. But, from reading through the docs and previous posts to this list, it would appear that Amanda will not natively write to both drives at the same time without resorting to using a two config model. I have a few questions about the 2 config model. - I have a 14 slot array. Can I have the two configs share the same tapelist? So that I don't have to split up the slots into to groups of 7 with separate tapelists and potentially have the tape swapping days become out of sync. (ie, group 1 takes 2 tapes on night, so 6 days into it, it needs to they need to be swapped out, but group 2 still has an open tape to use). I'd like to continue to swap all 14 tapes at the same time. - Most of the posts regarding configuring Amanda to write to both tape drives simultaneously are at least a year old. Does the 2.5.x version address/fix this limitation? or are there any future plans to add this? - Any examples out there of best practices, or sample configs, for the two config model? (anyone willing to share theirs?) Thanks -Steffan
NFS strangeness
Hello all, Just wondering if anyone might be able to shed some light on my problem... we recently got a SnapServer on our network and would like to use our existing Amanda install to back it up via NFS but so far have been unsuccessful. - FreeBSD 4.7-RELEASE - Amanda v2.4.4b1 - GNU tar v1.13.25 I have tried mounting the NFS shares onto the main Amanda backup host as well as other servers being backed up via Amanda. I can manually, from the command line, read/write and tar up the attached NFS shares without issue, both as root and user Amanda. Yet when Amanda runs through it's backup process, nothing gets backed up from that share. I've checked the logs, and there are no errors showing. Running an amrecover shows the root directory that the share is mounted on, but there are no files or directories within to recover. I've tried changing the dump type in amanda.conf to both DUMP and GNUTAR for the partition in question. No change. I've also tried an NFS mount from an alternate FreeBSD machine to rule out the SnapServer. Same issue. Here are the runtar and sendsize debug files: runtar: debug 1 pid 49585 ruid 1002 euid 0: start at Fri Sep 8 13:41:26 2006 gtar: version 2.4.4b1 running: /usr/bin/tar: gtar --create --file - --directory /nfs --one-file-system --listed-incremental /usr/local/var/amanda/gnutar-lists/phatb.boothcreek.net_dev_aacd0s2h_1.new --sparse --ignore-failed-read --totals --exclude-from /tmp/amanda/sendbackup._dev_aacd0s2h.20060908134126.exclude . sendsize: debug 1 pid 50252 ruid 1002 euid 1002: start at Fri Sep 8 13:59:38 2006 sendsize: version 2.4.4b1 sendsize[50252]: time 0.005: waiting for any estimate child sendsize[50257]: time 0.005: calculating for amname '/dev/aacd0s2h', dirname '/nfs', spindle -1 sendsize[50257]: time 0.006: getting size via gnutar for /dev/aacd0s2h level 0 sendsize[50257]: time 0.008: spawning /usr/local/libexec/runtar in pipeline sendsize[50257]: argument list: /usr/bin/tar --create --file /dev/null --directory /nfs --one-file-system --listed-incremental /usr/local/var/amanda/gnutar-lists/phatb.boothcreek.net_dev_aacd0s2h_0.new --sparse --ignore-failed-read --totals --exclude-from /tmp/amanda/sendsize._dev_aacd0s2h.20060908135938.exclude . sendsize[50257]: time 0.052: Total bytes written: 102400 (100kB, 3.1MB/s) sendsize[50257]: time 0.053: . sendsize[50257]: estimate time for /dev/aacd0s2h level 0: 0.045 sendsize[50257]: estimate size for /dev/aacd0s2h level 0: 100 KB sendsize[50257]: time 0.053: waiting for /usr/bin/tar /dev/aacd0s2h child sendsize[50257]: time 0.053: after /usr/bin/tar /dev/aacd0s2h wait sendsize[50257]: time 0.054: done with amname '/dev/aacd0s2h', dirname '/nfs', spindle -1 sendsize[50252]: time 0.054: child 50257 terminated normally sendsize: time 0.054: pid 50252 finish time Fri Sep 8 13:59:38 2006 as you can see... it only sees the 100k of real test files that I have in the /nfs directory, and not the actual mounts that live under /nfs. ??? Am I missing something easy? Anything special I need to add to 'amanda.conf'? or 'disklist'? I do just mount the NFS share to an existing entry in my disklist, right? Rather then adding the NFS mount as a separate entry? I've check all the permissions on the share (no_root_squash, etc)... I'm at a loss. Digging around the net, I've been unable to find any clear docs on what the proper setup might need to look like. Anyone have any more suggestions about next steps? Thanks a bunch, -Steffan
Re: NFS strangeness
Frank- Thanks so much for your reply... that did the trick! I knew it had to be something simple... I'll be adding that to the Amanda Wiki for future users. Thanks again -Steffan Frank Smith wrote: Dump works on devices, not filesystems, so it won't work on an NFS mount. Tar works on filesystems, but Amanda calls it with the option to not cross filesystem boundaries, so a backup of /nfs in your case will just give you the local files in /nfs and not mounts under /nfs. If you are trying to backup /nfs/remotedir, add /nfs/remotedir to your disklist and it will do what you want. I backup our legacy NetApps via an NFS mount this way and it works fine. Frank
