amanda got a tummy ache over sudden increase in data in /opt
Greetings folks;
from /tmp/amanda-dbg/amandad/tonights file:
-
amandad: time 0.220: try_socksize: receive buffer size is 65536
amandad: time 0.220: stream_server: waiting for connection: ::.41697
amandad: time 0.220: sending REP pkt:
CONNECT DATA 44889 MESG 54361 INDEX 41697
OPTIONS features=9ffe00;
amandad: time 0.220: dgram_send_addr(addr=0x8052568, dgram=0xb7f721a4)
amandad: time 0.220: (sockaddr_in *)0x8052568 = { 2, 713, 192.168.71.3 }
amandad: time 0.220: dgram_send_addr: 0xb7f721a4-socket = 0
amandad: time 0.233: dgram_recv(dgram=0xb7f721a4, timeout=0,
fromaddr=0xb7f82190)
amandad: time 0.233: (sockaddr_in *)0xb7f82190 = { 2, 713, 192.168.71.3 }
amandad: time 0.233: received ACK pkt:
amandad: time 0.233: stream_accept: connection from :::192.168.71.3.52616
amandad: time 0.234: try_socksize: send buffer size is 65536
amandad: time 0.234: try_socksize: receive buffer size is 65536
amandad: time 0.234: stream_accept: connection from :::192.168.71.3.46641
amandad: time 0.234: try_socksize: send buffer size is 65536
amandad: time 0.234: try_socksize: receive buffer size is 65536
amandad: time 0.234: stream_accept: connection from :::192.168.71.3.56240
amandad: time 0.234: try_socksize: send buffer size is 65536
amandad: time 0.234: try_socksize: receive buffer size is 65536
amandad: time 0.234: security_close(handle=0x8052548, driver=0xb7f702a0 (BSD))
amandad: time 3578.686: security_stream_seterr(0x8063160, Connection reset by
peer)
amandad: time 3578.765: security_stream_seterr(0x8063160, write error on
stream 44889: Broken pipe)
amandad: time 3578.765: sending NAK pkt:
ERROR write error on stream 44889: write error on stream 44889: Broken pipe
amandad: time 3578.765: security_stream_close(0x8063160)
amandad: time 3578.765: security_stream_close(0x806b198)
amandad: time 3578.765: security_stream_close(0x80731d0)
amandad: time 3599.765: pid 31022 finish time Tue Jun 26 02:05:33 2007
--
Did I run out of dtimeout?
-from amanda.conf-
dtimeout 1500 # number of idle seconds before a dump is aborted.
-
The backup stated at 00:15
FC6 box, iptables isn't running and selinux is disabled completely.
Thanks.
--
Cheers, Gene
There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order.
-Ed Howdershelt (Author)
The C Programming Language -- A language which combines the flexibility of
assembly language with the power of assembly language.
Re: suggestion for a disk-to-disk backup server
On 2007-06-25 22:43, Chris Hoogendyk wrote: Jon LaBadie wrote: On Mon, Jun 25, 2007 at 12:43:50PM -0400, Chris Hoogendyk wrote: ... then I created a dumptype that was the same as my regular dumps but with record no strategy incronly Instead of making it a different configuration, and running into trouble on which full to base an incrmeental, why don't you run an additional amdump of the normal config in the weekend, but which has options to override the config: amdump daily -o reserver=100,tapedev=/no/such/tape With the option tapedev /no/such/tape we force Amanda to fall back to degraded mode, making backup to holdingdisk only, and with the reserve 100, we avoid wasting holdingdisk space for full backups in the degraded mode. On monday morning, you can choose: - flush the backup images to tape manually - autoflush together with the normal backup of the next night I'm not 100% certain, but I believe you may even erase (some of) the holdingdisk files, without flushing. I think that Amanda will take into account that the holdingdisk file disappeared, and schedule the same incremental level again (or a level 0 if due). Because there is no equivalent to amrmtape for a holdingdisk file, and, there are at least some things implemented that detect the loss of an holdingdisk file. Would be nice if someone could confirm this. I thought this would work, because the incremental would be based on ufsdump, and it would know there had been a full, even though it was a different configuration. Apparently, I've got this wrong. I'll check through the documentation, but I thought someone on the list might have done something like this or know either that it can't be done or how to do it as well as why. (Possibly, amanda interprets incronly as iff there has already been a full at some time under this configuration.) ufsdump might have been able to figure out from which date to do the incremental, `IF' it had been asked to do an incremental. However, as this was a new config, amanda knew there had never been a level 0 for this config. And of course it must start from a level 0 to do the incrementals. Even on a config meant to do incronly strategy you must do an initial full dump. -- Paul Bijnens, xplanation Technology ServicesTel +32 16 397.511 Technologielaan 21 bus 2, B-3001 Leuven, BELGIUMFax +32 16 397.512 http://www.xplanation.com/ email: [EMAIL PROTECTED] *** * I think I've got the hang of it now: exit, ^D, ^C, ^\, ^Z, ^Q, ^^, * * F6, quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, * * stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt, abort, hangup, * * PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e, kill -1 $$, shutdown, * * init 0, kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ... * * ... Are you sure? ... YES ... Phew ... I'm out * ***
Re: amanda got a tummy ache over sudden increase in data in /opt
On 2007-06-26 09:17, Gene Heskett wrote:
Greetings folks;
from /tmp/amanda-dbg/amandad/tonights file:
-
amandad: time 0.220: try_socksize: receive buffer size is 65536
amandad: time 0.220: stream_server: waiting for connection: ::.41697
amandad: time 0.220: sending REP pkt:
CONNECT DATA 44889 MESG 54361 INDEX 41697
OPTIONS features=9ffe00;
amandad: time 0.220: dgram_send_addr(addr=0x8052568, dgram=0xb7f721a4)
amandad: time 0.220: (sockaddr_in *)0x8052568 = { 2, 713, 192.168.71.3 }
amandad: time 0.220: dgram_send_addr: 0xb7f721a4-socket = 0
amandad: time 0.233: dgram_recv(dgram=0xb7f721a4, timeout=0,
fromaddr=0xb7f82190)
amandad: time 0.233: (sockaddr_in *)0xb7f82190 = { 2, 713, 192.168.71.3 }
amandad: time 0.233: received ACK pkt:
amandad: time 0.233: stream_accept: connection from :::192.168.71.3.52616
amandad: time 0.234: try_socksize: send buffer size is 65536
amandad: time 0.234: try_socksize: receive buffer size is 65536
amandad: time 0.234: stream_accept: connection from :::192.168.71.3.46641
amandad: time 0.234: try_socksize: send buffer size is 65536
amandad: time 0.234: try_socksize: receive buffer size is 65536
amandad: time 0.234: stream_accept: connection from :::192.168.71.3.56240
amandad: time 0.234: try_socksize: send buffer size is 65536
amandad: time 0.234: try_socksize: receive buffer size is 65536
amandad: time 0.234: security_close(handle=0x8052548, driver=0xb7f702a0 (BSD))
amandad: time 3578.686: security_stream_seterr(0x8063160, Connection reset by
peer)
amandad: time 3578.765: security_stream_seterr(0x8063160, write error on
stream 44889: Broken pipe)
amandad: time 3578.765: sending NAK pkt:
ERROR write error on stream 44889: write error on stream 44889: Broken pipe
amandad: time 3578.765: security_stream_close(0x8063160)
amandad: time 3578.765: security_stream_close(0x806b198)
amandad: time 3578.765: security_stream_close(0x80731d0)
amandad: time 3599.765: pid 31022 finish time Tue Jun 26 02:05:33 2007
--
Did I run out of dtimeout?
-from amanda.conf-
dtimeout 1500 # number of idle seconds before a dump is aborted.
-
The problem here is that we do not see the any trace of traffic
of absence of traffic on the DATA channel in such a log file. We can
only guess.
So, yes, it could be that about 2078 seconds after starting the backup
it was hanging (e.g. when stat()ing a dead samba mounted filesystem)
for about 1500 seconds, after which the server aborted the dump, closing
the tcp connections to the client.
On the client side we only see Connection reset by peer, meaning that
the other side (server) has closed the connection. On the server side,
we should find the corresponding logs (probably in amdump.X log) about
3578 seconds later than the start of dump of this DLE. Maybe some more
info is there about the decision to close the connection?
The backup stated at 00:15
FC6 box, iptables isn't running and selinux is disabled completely.
--
Paul Bijnens, xplanation Technology ServicesTel +32 16 397.511
Technologielaan 21 bus 2, B-3001 Leuven, BELGIUMFax +32 16 397.512
http://www.xplanation.com/ email: [EMAIL PROTECTED]
***
* I think I've got the hang of it now: exit, ^D, ^C, ^\, ^Z, ^Q, ^^, *
* F6, quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, *
* stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt, abort, hangup, *
* PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e, kill -1 $$, shutdown, *
* init 0, kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ... *
* ... Are you sure? ... YES ... Phew ... I'm out *
***
Re: suggestion for a disk-to-disk backup server
On Tue, Jun 26, 2007 at 09:29:52AM +0200, Paul Bijnens wrote: I'm not 100% certain, but I believe you may even erase (some of) the holdingdisk files, without flushing. I think that Amanda will take into account that the holdingdisk file disappeared, and schedule the same incremental level again (or a level 0 if due). Because there is no equivalent to amrmtape for a holdingdisk file, and, there are at least some things implemented that detect the loss of an holdingdisk file. Would be nice if someone could confirm this. You're half-right -- Amanda will not try to flush a missing file, but it will not take missing files into account in the planner. Amanda-2.5.2 and later has 'amadmin conf holding delete' which can delete holding files and adjust the 'curinfo' database accordingly, such that the appropriate level of dump will take place next time. Also, note that 'amdump' takes a [ hostname [ diskname ..] ] argument, if you only want to dump certain DLEs. Dustin -- Dustin J. Mitchell Storage Software Engineer, Zmanda, Inc. http://www.zmanda.com/
Large number of entries in the disklist file?
Fellow AMANDA users, In the past, I remember seeing something about AMANDA having trouble when there are a large number of disklist entries. First, am I remembering correctly, and second what constitutes a large number of entries? My current backup plan is to have about 1500-2000 entries in the disklist. Is this a poor idea? Best, Jordan Desroches Systems Administrator Thayer School of Engineering Dartmouth College
RE: Troubleshooting new Amanda client: Amanda user?
Kevin, thanks so much. You were right on the money. Disabling the
firewall completely allow amcheck to work correctly.
If you have some additional patience, I could use a hand trying to
configure the firewall rules correctly on my amanda client. I tried to
follow the directions at
http://wiki.zmanda.com/index.php/How_To:Set_Up_iptables_for_Amanda to
set up this rule on tobaccodev, my amanda client. This combines the
amanda rule with the rules I set up using the firewall GUI in CentOS5
(RHEL5):
[EMAIL PROTECTED] ~]# iptables -t filter -I INPUT 1 -p udp -m udp -s
centernet.jhuccp.org --dport 10080:10083 -j ACCEPT
[EMAIL PROTECTED] ~]# service iptables status
Table: filter
Chain INPUT (policy ACCEPT)
num target prot opt source destination
1ACCEPT udp -- 10.253.192.205 0.0.0.0/0 udp
dpts:10080:10083
2RH-Firewall-1-INPUT all -- 0.0.0.0/00.0.0.0/0
Chain FORWARD (policy ACCEPT)
num target prot opt source destination
1RH-Firewall-1-INPUT all -- 0.0.0.0/00.0.0.0/0
Chain OUTPUT (policy ACCEPT)
num target prot opt source destination
Chain RH-Firewall-1-INPUT (2 references)
num target prot opt source destination
1ACCEPT all -- 0.0.0.0/00.0.0.0/0
2ACCEPT icmp -- 0.0.0.0/00.0.0.0/0 icmp
type 255
3ACCEPT esp -- 0.0.0.0/00.0.0.0/0
4ACCEPT ah -- 0.0.0.0/00.0.0.0/0
5ACCEPT udp -- 0.0.0.0/0224.0.0.251 udp
dpt:5353
6ACCEPT udp -- 0.0.0.0/00.0.0.0/0 udp
dpt:631
7ACCEPT tcp -- 0.0.0.0/00.0.0.0/0 tcp
dpt:631
8ACCEPT all -- 0.0.0.0/00.0.0.0/0 state
RELATED,ESTABLISHED
9ACCEPT tcp -- 0.0.0.0/00.0.0.0/0 state
NEW tcp dpt:21
10 ACCEPT tcp -- 0.0.0.0/00.0.0.0/0 state
NEW tcp dpt:25
11 ACCEPT tcp -- 0.0.0.0/00.0.0.0/0 state
NEW tcp dpt:22
12 ACCEPT tcp -- 0.0.0.0/00.0.0.0/0 state
NEW tcp dpt:443
13 ACCEPT tcp -- 0.0.0.0/00.0.0.0/0 state
NEW tcp dpt:23
14 ACCEPT tcp -- 0.0.0.0/00.0.0.0/0 state
NEW tcp dpt:80
15 REJECT all -- 0.0.0.0/00.0.0.0/0
reject-with icmp-host-prohibited
Here's an example of a no-error 'amcheck -c DBackup tobaccodev' from the
tapeserver:
[EMAIL PROTECTED] ~]# tcpdump -nn src or dst centernet and port amanda
tcpdump: verbose output suppressed, use -v or -vv for full protocol
decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
10:28:58.190591 IP 10.253.192.205.854 10.253.192.217.10080: UDP,
length 123
10:28:58.210814 IP 10.253.192.217.10080 10.253.192.205.854: UDP,
length 50
10:28:58.212936 IP 10.253.192.217.10080 10.253.192.205.854: UDP,
length 87
10:28:58.214318 IP 10.253.192.205.854 10.253.192.217.10080: UDP,
length 50
10:28:58.216532 IP 10.253.192.205.854 10.253.192.217.10080: UDP,
length 299
10:28:58.223632 IP 10.253.192.217.10080 10.253.192.205.854: UDP,
length 50
10:28:58.233581 IP 10.253.192.217.10080 10.253.192.205.854: UDP,
length 527
10:28:58.235018 IP 10.253.192.205.854 10.253.192.217.10080: UDP,
length 50
8 packets captured
20 packets received by filter
0 packets dropped by kernel
[EMAIL PROTECTED] ~]#
I had to insert the rule to allow amanda packets in _before_ the
RH-Firewall-1-INPUT rule to make it work. This tests correctly with
amcheck, but I haven't tried an actual dump yet.
If someone with some amanda firewall rule writing experience could check
and confirm my work, I'll write an addendum to the Zmanda artile with my
example, for other CentOS and RHEL users.
Thanks, again, Kevin, for your advice and suggestions.
-Kevin
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Kevin Till
Sent: Friday, June 22, 2007 5:33 PM
Cc: amanda-users@amanda.org
Subject: Re: Troubleshooting new Amanda client: Amanda user?
Zembower, Kevin wrote:
Kevin, thanks so much for writing. I appreciate your suggestions and
questions.
Here's /etc/xinet.d/amanda:
[EMAIL PROTECTED] ~]# cat /etc/xinetd.d/amanda
# default: off
# description: The client for the Amanda backup system.\
# This must be on for systems being backed up\
# by Amanda.
service amanda
{
socket_type = dgram
protocol= udp
wait= yes
user= amanda
group = disk
server = /usr/lib/amanda/amandad
disable = no
}
[EMAIL PROTECTED] ~]#
No 'auth' seems to be indicated.
It's running the
Re: Troubleshooting new Amanda client: Amanda user?
On Tue, Jun 26, 2007 at 10:38:33AM -0400, Zembower, Kevin enlightened us: Kevin, thanks so much. You were right on the money. Disabling the firewall completely allow amcheck to work correctly. If you have some additional patience, I could use a hand trying to configure the firewall rules correctly on my amanda client. I tried to follow the directions at http://wiki.zmanda.com/index.php/How_To:Set_Up_iptables_for_Amanda to set up this rule on tobaccodev, my amanda client. This combines the amanda rule with the rules I set up using the firewall GUI in CentOS5 (RHEL5): [EMAIL PROTECTED] ~]# iptables -t filter -I INPUT 1 -p udp -m udp -s centernet.jhuccp.org --dport 10080:10083 -j ACCEPT [EMAIL PROTECTED] ~]# service iptables status Table: filter Chain INPUT (policy ACCEPT) num target prot opt source destination 1ACCEPT udp -- 10.253.192.205 0.0.0.0/0 udp dpts:10080:10083 2RH-Firewall-1-INPUT all -- 0.0.0.0/00.0.0.0/0 Chain FORWARD (policy ACCEPT) num target prot opt source destination 1RH-Firewall-1-INPUT all -- 0.0.0.0/00.0.0.0/0 Chain OUTPUT (policy ACCEPT) num target prot opt source destination Chain RH-Firewall-1-INPUT (2 references) num target prot opt source destination 1ACCEPT all -- 0.0.0.0/00.0.0.0/0 2ACCEPT icmp -- 0.0.0.0/00.0.0.0/0 icmp type 255 3ACCEPT esp -- 0.0.0.0/00.0.0.0/0 4ACCEPT ah -- 0.0.0.0/00.0.0.0/0 5ACCEPT udp -- 0.0.0.0/0224.0.0.251 udp dpt:5353 6ACCEPT udp -- 0.0.0.0/00.0.0.0/0 udp dpt:631 7ACCEPT tcp -- 0.0.0.0/00.0.0.0/0 tcp dpt:631 8ACCEPT all -- 0.0.0.0/00.0.0.0/0 state RELATED,ESTABLISHED 9ACCEPT tcp -- 0.0.0.0/00.0.0.0/0 state NEW tcp dpt:21 10 ACCEPT tcp -- 0.0.0.0/00.0.0.0/0 state NEW tcp dpt:25 11 ACCEPT tcp -- 0.0.0.0/00.0.0.0/0 state NEW tcp dpt:22 12 ACCEPT tcp -- 0.0.0.0/00.0.0.0/0 state NEW tcp dpt:443 13 ACCEPT tcp -- 0.0.0.0/00.0.0.0/0 state NEW tcp dpt:23 14 ACCEPT tcp -- 0.0.0.0/00.0.0.0/0 state NEW tcp dpt:80 15 REJECT all -- 0.0.0.0/00.0.0.0/0 reject-with icmp-host-prohibited Here's an example of a no-error 'amcheck -c DBackup tobaccodev' from the tapeserver: [EMAIL PROTECTED] ~]# tcpdump -nn src or dst centernet and port amanda tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 10:28:58.190591 IP 10.253.192.205.854 10.253.192.217.10080: UDP, length 123 10:28:58.210814 IP 10.253.192.217.10080 10.253.192.205.854: UDP, length 50 10:28:58.212936 IP 10.253.192.217.10080 10.253.192.205.854: UDP, length 87 10:28:58.214318 IP 10.253.192.205.854 10.253.192.217.10080: UDP, length 50 10:28:58.216532 IP 10.253.192.205.854 10.253.192.217.10080: UDP, length 299 10:28:58.223632 IP 10.253.192.217.10080 10.253.192.205.854: UDP, length 50 10:28:58.233581 IP 10.253.192.217.10080 10.253.192.205.854: UDP, length 527 10:28:58.235018 IP 10.253.192.205.854 10.253.192.217.10080: UDP, length 50 8 packets captured 20 packets received by filter 0 packets dropped by kernel [EMAIL PROTECTED] ~]# I had to insert the rule to allow amanda packets in _before_ the RH-Firewall-1-INPUT rule to make it work. This tests correctly with amcheck, but I haven't tried an actual dump yet. If someone with some amanda firewall rule writing experience could check and confirm my work, I'll write an addendum to the Zmanda artile with my example, for other CentOS and RHEL users. Thanks, again, Kevin, for your advice and suggestions. -Kevin On my CentOS client systems, I modify /etc/sysconfig/iptables-config to read: IPTABLES_MODULES=ip_conntrack_ftp ip_conntrack_amanda And simply allow udp 10080 from the server (in /etc/sysconfig/iptables): -A INPUT -s 192.168.1.1 -d 192.168.1.30 -p udp -m udp --dport 10080 -j ACCEPT On the server I also allow tcp 10082 and 10083. On my bridging firewall, I modify /etc/modprobe.conf to include a longer timeout: options ip_conntrack_amanda master_timeout=2400 That works for me... Matt -- Matt Hyclak Department of Mathematics Department of Social Work Ohio University (740) 593-1263
Use multiple drives in tape robot
Hi, Is it possible to have 2 configs using 2 separate drives in a tape robot, i.e. can they share the changer interface? I don't mean use of RAIT. I have successfully set up 1 config with chg-zd-mtx then tried duplicating that to a 2nd config using chg-zd-mtx with a different set of tapes in the robot, and the other drive. This was successful, except one of the amdumps failed on the first calling saying no writable tape could be found; it worked on the 2nd calling so I suspect there is a clash with 2 configs trying to access the changer. Or am I barking up the wrong tree, is there a better way to do this (one of the other changer scripts?) or is it just not possible/supported? Thanks for any info or suggestions as to where in the documentation I should be looking. Phil Phil Weber Business Technology (Egg) Storage Technical Services - Senior UNIX Technologist Phone: 01384 26 4136 - Egg is a trading name of the Egg group of companies which includes: Egg plc (reg no 2448340), Egg Financial Intermediation Ltd (reg no 3828289), and Egg Banking plc (reg no 2999842). Egg Banking plc and Egg Financial Intermediation Ltd are authorised and regulated by the Financial Services Authority (FSA) and are entered in the FSA register under numbers 205621 and 309551 respectively. These members of the Egg group are registered in England and Wales. Registered office: Citigroup Centre, Canada Square, London E14 5LB. This e-mail is confidential and for use by the addressee only. If you are not the intended recipient of this e-mail and have received it in error, please return the message to the sender by replying to it and then delete it from your mailbox. Internet e-mails are not necessarily secure. The Egg group of companies do not accept responsibility for changes made to this message after it was sent. Whilst all reasonable care has been taken to avoid the transmission of viruses, it is the responsibility of the recipient to ensure that the onward transmission, opening or use of this message and any attachments will not adversely affect its systems or data. No responsibility is accepted by the Egg group of companies in this regard and the recipient should carry out such virus and other checks as it considers appropriate. This communication does not create or modify any contract.
Re: Use multiple drives in tape robot
On Tue, 26 Jun 2007 at 4:58pm, Weber, Philip wrote Is it possible to have 2 configs using 2 separate drives in a tape robot, i.e. can they share the changer interface? I don't mean use of RAIT. I have successfully set up 1 config with chg-zd-mtx then tried duplicating that to a 2nd config using chg-zd-mtx with a different set of tapes in the robot, and the other drive. This was successful, except one of the amdumps failed on the first calling saying no writable tape could be found; it worked on the 2nd calling so I suspect there is a clash with 2 configs trying to access the changer. I do exactly this, and have never seen a collision. I kick off the 2 amdumps 5 minutes apart. Be sure to assign each config its own set of slots. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Re: Use multiple drives in tape robot
On Tuesday 26 June 2007 11:58:00 Weber, Philip wrote: Is it possible to have 2 configs using 2 separate drives in a tape robot, i.e. can they share the changer interface? I don't mean use of RAIT. The answer to your question is yes, but you must ensure that only one instance of mtx is running at a time. If your configurations each use one tape only, then it should be safe to start them at different times, as Joshua has suggested. If you have runtapes 1 for both configurations (and maybe even if not), you might consider wrapping MTX in a short script to ensure that only one copy runs at a time. --Ian I have successfully set up 1 config with chg-zd-mtx then tried duplicating that to a 2nd config using chg-zd-mtx with a different set of tapes in the robot, and the other drive. This was successful, except one of the amdumps failed on the first calling saying no writable tape could be found; it worked on the 2nd calling so I suspect there is a clash with 2 configs trying to access the changer. Or am I barking up the wrong tree, is there a better way to do this (one of the other changer scripts?) or is it just not possible/supported? Thanks for any info or suggestions as to where in the documentation I should be looking. Phil Phil Weber Business Technology (Egg) Storage Technical Services - Senior UNIX Technologist Phone: 01384 26 4136 - Egg is a trading name of the Egg group of companies which includes: Egg plc (reg no 2448340), Egg Financial Intermediation Ltd (reg no 3828289), and Egg Banking plc (reg no 2999842). Egg Banking plc and Egg Financial Intermediation Ltd are authorised and regulated by the Financial Services Authority (FSA) and are entered in the FSA register under numbers 205621 and 309551 respectively. These members of the Egg group are registered in England and Wales. Registered office: Citigroup Centre, Canada Square, London E14 5LB. This e-mail is confidential and for use by the addressee only. If you are not the intended recipient of this e-mail and have received it in error, please return the message to the sender by replying to it and then delete it from your mailbox. Internet e-mails are not necessarily secure. The Egg group of companies do not accept responsibility for changes made to this message after it was sent. Whilst all reasonable care has been taken to avoid the transmission of viruses, it is the responsibility of the recipient to ensure that the onward transmission, opening or use of this message and any attachments will not adversely affect its systems or data. No responsibility is accepted by the Egg group of companies in this regard and the recipient should carry out such virus and other checks as it considers appropriate. This communication does not create or modify any contract. -- Forums for Amanda discussion: http://forums.zmanda.com/
Restore from multiple configs
Hello again. In my struggle to get a working amanda config (working for my strange setup :) I reached the following decision: I'll use two configs, - Weekly, which does level-0 dumps to tape (using chg-zd-mtx) - Daily, which does incrementals to a virtual tape on disk (using chg-disk) As it is cumbersome to restore stuff from different configs, I wrote chg-multiplex, which acts as a super-changer and combines the two configs for restore purposes. If you like the idea, have a look at: http://wiki.zmanda.com/index.php/Chg-multiplex If you don't: sorry for the spam :) -- Harald Schioeberg Technische Universitaet Berlin | T-Laboratories | FG INET www: http://www.net.t-labs.tu-berlin.de Phone: +49-(0)30-8353-58476 | Fax: +49-(0)391 534 783 47
Re: Use multiple drives in tape robot
* Joshua Baker-LePain [EMAIL PROTECTED] [20070626 12:32]: On Tue, 26 Jun 2007 at 4:58pm, Weber, Philip wrote Is it possible to have 2 configs using 2 separate drives in a tape robot, i.e. can they share the changer interface? I don't mean use of RAIT. I have successfully set up 1 config with chg-zd-mtx then tried duplicating that to a 2nd config using chg-zd-mtx with a different set of tapes in the robot, and the other drive. This was successful, except one of the amdumps failed on the first calling saying no writable tape could be found; it worked on the 2nd calling so I suspect there is a clash with 2 configs trying to access the changer. I do exactly this, and have never seen a collision. I kick off the 2 amdumps 5 minutes apart. Be sure to assign each config its own set of slots. I'll just add that you must also configure amanda such that both configs use different ports with '--with-testing=config1' and '--with-testing=config2' and add those to /etc/services like amanda-config110080/tcp amanda-config110080/udp amanda-config210081/tcp amanda-config210081/udp Depending on the authentication scheme you decide to use you might have to specify the udp and tcp port range so that both config don't overlap. Look for '--with-tcpportrange=' and '--with-udpportrange=' There is no provision for the access of the robotic device. At some point I had 7 config on the same robot and I had surprisingly little contention between the different amanda configs accessing the robot arm. hth jf -- Joshua Baker-LePain Department of Biomedical Engineering Duke University -- °
Re: Use multiple drives in tape robot
On Tue, 26 Jun 2007 at 12:57pm, Jean-Francois Malouin wrote I'll just add that you must also configure amanda such that both configs use different ports with '--with-testing=config1' and '--with-testing=config2' and add those to /etc/services like amanda-config110080/tcp amanda-config110080/udp amanda-config210081/tcp amanda-config210081/udp Depending on the authentication scheme you decide to use you might have to specify the udp and tcp port range so that both config don't overlap. Look for '--with-tcpportrange=' and '--with-udpportrange=' Hmm. Is that on the server or the client side? I didn't do any such magic, but I don't have any clients that are in both configs. Also, I'm still using 2.4.5p1. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Re: Restore from multiple configs
Hi Harald, I'm going to ignore your details and key on the concept : you want to have a weekly and a daily back up. I wanted to do this too and went down the path of investigating multiple configurations like you are doing. But it really bugged me that I have to basically do 2 level-0 backups a week, one for the weekly and one for the daily (since the daily backup configuration isn't aware of the weekly). My reason for having a weekly backup is because I want to be able to archive the tapes periodically, but I don't need to have the 2 configurations fully separate. After messing around, I finally figured out that what I wanted was a single configuration with a forced level 0 on saturday night. So, I set up a single daily configuration. Inside /etc/amanda/daily I added a scripts called forceall that looks like this: -bash-3.00$ cat forceall #!/bin/sh /usr/sbin/amadmin daily force \ windsor / \ gilmore / \ gilmore /backedup/project \ gilmore /backedup/home \ gateway2 / \ imap / \ asterisk / - so yes, I have to specify all my disk entries in this file, which is a pain and a possible issue when you change the entries - but my disk configuration is pretty stable. (I also created an unforceall is the same with the force parameter changed to unforce for testing.) My crontab looks like: # # minute (0-59) # | - hour (0-23) # | | -- day of month (1-31) # | | | --- month (1-12) # | | | | day of the week (0-7 sunday = 0 or 7) # | | | | | # * * * * * # check the configuration each evening 00 20 * * 0-5 /usr/sbin/amcheck -m daily # run pgrdaily every weekday and Saturday morning 05 03 * * 1-6 /usr/sbin/amdump daily # on Saturday morning, make sure its a level 0 00 03 * *6 /etc/amanda/daily/forceall amdump doesn't run on Sunday, giving the Saturday job enough chance to dump everything as it can take more than 24 hours for a full level 0. But each Saturday before the dump, I run the forceall script that tells amanda to make the next run a level 0. This is working really well for me. Any weekend I have a level 0 set of tapes that I can pull and put into the safe or off-site backup, but I don't have to pay the overhead of doing 2 level 0's, one for the weekly and one for the daily/cycle. I just thought I would suggest this as an alternative to a 2 configuration setup. When I pull the tapes, I have a system for marking the out-going tapes as being not reused, and then adding the new tapes into the rotation. If you are interested in going ahead with the above kind of idea I can send you the details on that too. Anyway, hopefully you find this idea interesting. Don (ps: and I know this isn't really the recommended way of doing things... the recommended way is just let amanda schedule it all - but I've found this to work very well for me. I usually only pull my archive once a month and I have considered changing the cronjob to only force the level 0 once a month rather than once a week - but my backups do occassionally have a glitch and fail to run, so having them go weekly allows me to just wait for next week if there was a problem, rather than having to either wait a month or manually mess with something.) Harald Schioeberg wrote: Hello again. In my struggle to get a working amanda config (working for my strange setup :) I reached the following decision: I'll use two configs, - Weekly, which does level-0 dumps to tape (using chg-zd-mtx) - Daily, which does incrementals to a virtual tape on disk (using chg-disk) As it is cumbersome to restore stuff from different configs, I wrote chg-multiplex, which acts as a super-changer and combines the two configs for restore purposes. If you like the idea, have a look at: http://wiki.zmanda.com/index.php/Chg-multiplex If you don't: sorry for the spam :) -- Harald Schioeberg Technische Universitaet Berlin | T-Laboratories | FG INET www: http://www.net.t-labs.tu-berlin.de Phone: +49-(0)30-8353-58476 | Fax: +49-(0)391 534 783 47
RE: Troubleshooting new Amanda client: Amanda user?
Matt, thank you for your help. I didn't think that I had ip_conntrack_amanda, so I was trying to set it up without it. When I tried your way, it worked like a charm. Note to archive readers: I think it's important to insert the line: -A INPUT -s 192.168.1.1 -d 192.168.1.30 -p udp -m udp --dport 10080 -j ACCEPT _before_ the line: -A INPUT -j RH-Firewall-1-INPUT to prevent the packets from following the RH-Firewall-1-INPUT rules first, where they'll be discarded. Thanks, again, Matt. -Kevin -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matt Hyclak Sent: Tuesday, June 26, 2007 11:39 AM To: amanda-users@amanda.org Subject: Re: Troubleshooting new Amanda client: Amanda user? On Tue, Jun 26, 2007 at 10:38:33AM -0400, Zembower, Kevin enlightened us: Kevin, thanks so much. You were right on the money. Disabling the firewall completely allow amcheck to work correctly. If you have some additional patience, I could use a hand trying to configure the firewall rules correctly on my amanda client. I tried to follow the directions at http://wiki.zmanda.com/index.php/How_To:Set_Up_iptables_for_Amanda to set up this rule on tobaccodev, my amanda client. This combines the amanda rule with the rules I set up using the firewall GUI in CentOS5 (RHEL5): [EMAIL PROTECTED] ~]# iptables -t filter -I INPUT 1 -p udp -m udp -s centernet.jhuccp.org --dport 10080:10083 -j ACCEPT [EMAIL PROTECTED] ~]# service iptables status Table: filter Chain INPUT (policy ACCEPT) num target prot opt source destination 1ACCEPT udp -- 10.253.192.205 0.0.0.0/0 udp dpts:10080:10083 2RH-Firewall-1-INPUT all -- 0.0.0.0/00.0.0.0/0 Chain FORWARD (policy ACCEPT) num target prot opt source destination 1RH-Firewall-1-INPUT all -- 0.0.0.0/00.0.0.0/0 Chain OUTPUT (policy ACCEPT) num target prot opt source destination Chain RH-Firewall-1-INPUT (2 references) num target prot opt source destination 1ACCEPT all -- 0.0.0.0/00.0.0.0/0 2ACCEPT icmp -- 0.0.0.0/00.0.0.0/0 icmp type 255 3ACCEPT esp -- 0.0.0.0/00.0.0.0/0 4ACCEPT ah -- 0.0.0.0/00.0.0.0/0 5ACCEPT udp -- 0.0.0.0/0224.0.0.251 udp dpt:5353 6ACCEPT udp -- 0.0.0.0/00.0.0.0/0 udp dpt:631 7ACCEPT tcp -- 0.0.0.0/00.0.0.0/0 tcp dpt:631 8ACCEPT all -- 0.0.0.0/00.0.0.0/0 state RELATED,ESTABLISHED 9ACCEPT tcp -- 0.0.0.0/00.0.0.0/0 state NEW tcp dpt:21 10 ACCEPT tcp -- 0.0.0.0/00.0.0.0/0 state NEW tcp dpt:25 11 ACCEPT tcp -- 0.0.0.0/00.0.0.0/0 state NEW tcp dpt:22 12 ACCEPT tcp -- 0.0.0.0/00.0.0.0/0 state NEW tcp dpt:443 13 ACCEPT tcp -- 0.0.0.0/00.0.0.0/0 state NEW tcp dpt:23 14 ACCEPT tcp -- 0.0.0.0/00.0.0.0/0 state NEW tcp dpt:80 15 REJECT all -- 0.0.0.0/00.0.0.0/0 reject-with icmp-host-prohibited Here's an example of a no-error 'amcheck -c DBackup tobaccodev' from the tapeserver: [EMAIL PROTECTED] ~]# tcpdump -nn src or dst centernet and port amanda tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 10:28:58.190591 IP 10.253.192.205.854 10.253.192.217.10080: UDP, length 123 10:28:58.210814 IP 10.253.192.217.10080 10.253.192.205.854: UDP, length 50 10:28:58.212936 IP 10.253.192.217.10080 10.253.192.205.854: UDP, length 87 10:28:58.214318 IP 10.253.192.205.854 10.253.192.217.10080: UDP, length 50 10:28:58.216532 IP 10.253.192.205.854 10.253.192.217.10080: UDP, length 299 10:28:58.223632 IP 10.253.192.217.10080 10.253.192.205.854: UDP, length 50 10:28:58.233581 IP 10.253.192.217.10080 10.253.192.205.854: UDP, length 527 10:28:58.235018 IP 10.253.192.205.854 10.253.192.217.10080: UDP, length 50 8 packets captured 20 packets received by filter 0 packets dropped by kernel [EMAIL PROTECTED] ~]# I had to insert the rule to allow amanda packets in _before_ the RH-Firewall-1-INPUT rule to make it work. This tests correctly with amcheck, but I haven't tried an actual dump yet. If someone with some amanda firewall rule writing experience could check and confirm my work, I'll write an addendum to the Zmanda artile with my example, for other CentOS and RHEL users. Thanks, again, Kevin, for your advice and suggestions. -Kevin On my CentOS client systems, I modify /etc/sysconfig/iptables-config to read: IPTABLES_MODULES=ip_conntrack_ftp ip_conntrack_amanda And simply
Re: Restore from multiple configs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I wanted to do this too and went down the path of investigating multiple configurations like you are doing. But it really bugged me that I have to basically do 2 level-0 backups a week, one for the weekly and one for the daily (since the daily backup configuration isn't aware of the weekly). It is. Just use the same logdir. Harald -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGgV/aJgyxs71kcx4RAgMKAJ4ltrXhSCFfTYR3zpe04bGG8v074QCeMKXa UjxjFUlpqx1iHwxb1e1hQF4= =1W8Y -END PGP SIGNATURE-
