How To:Run Multiple amandad processes on a Client

From The Open Source Backup Wiki (Amanda, MySQL Backup, BackupPC)
Jump to navigationJump to search

This article is a part of the How Tos collection.

Because the amandad process started by xinetd needs to be configured with the "wait = yes" status, there can normally be only one running process. When sending another request to the same client, the running amandad process will reply with a "amandad busy" error message.

There are circumstances when you want more than one amandad process concurrently running on a single client. Two methods are available:

  • recompile the amanda programs with alternative service names
  • configuring multiple IP-addresses and bind each instance to a single IP-address

Compiling with alternative service names

Normally the Amanda programs look in /etc/services (or the NIS-server etc) for the services "amanda" (usually 10080/udp) and "kamanda" (usually 10081/tcp).

You can compile the Amanda programs with the configure option --with-testing[=suffix]:

$ ./configure ...other-options... --with-testing

The resulting binaries will now look for the entries in /etc/services with names "amanda-test", "kamanda-test" which you can give numbers like 10090 and 10091.

Or giving an explicit suffix:

$ ./configure ...other-options... --with-testing=_2

which will look for the services named "amanda_2" and "kamanda_2".

When you want to install many Amanda suits on a single computer, you should also compile them with a different "--prefix=..." so that can exist next to each other.

Note that you also need to recompile the server side programs to use the alternative names.

These features are mainly to allow for a testing environment that can coexist with the normal environment.

Binding to a single IP-address with xinetd

More suitable for production systems is to add some parameters to the xinetd configuration.

We can dedicate one amandad process to each physical network interface, or (if only one interface is available) we can add aliases or virtual IP-numbers to the existing interface. E.g. when our interface has IP-number 192.168.0.101, we can add an IP-number:

# ifconfig eth0:1 192.168.0.102 netmask 255.255.255.0

By default xinetd will listen to all interfaces, but we can bind an instance of amandad listening to one interface:

service amanda
{
    id                = amanda1
    bind              = 192.168.0.101
    disable           = no
    socket_type       = dgram
    protocol          = udp
    wait              = yes
    user              = amandabackup
    group             = disk
    groups            = yes
    server            = /usr/local/libexec/amandad 
}
 
service amanda
{
    id                = amanda2
    bind              = 192.168.0.102
    disable           = no
    socket_type       = dgram
    protocol          = udp
    wait              = yes
    user              = amandabackup
    group             = disk
    groups            = yes
    server            = /usr/local/libexec/amandad 
}

We also need to add different names for the two ip-addresses in DNS, e.g. client1.example.com (IP 192.168.0.101) and client2.example.com (IP 192.179.0.102).

In the disklist on the server, we can now divide the DLE's over the two amandad processes, by simulating as if it are two diffferent clients. Note that in this case, two dumps can happen at the same time, similar to "maxdumps 2" in the dumptype of one client. To avoid trashing the single client, we make sure to add all DLE's of a single disk (spindle) to only one amandad instance:

Let's assume these mounts:

/dev/hda1  on  /boot 
/dev/hda3  on  / 
/dev/hda4  on  /var 
/dev/hdb1  on  /oracle

Then the disklist entries can be:

client1.example.com   /        comp-root-tar
client1.example.com   /var     comp-root-tar
client1.example.com   /boot    comp-root-tar
client2.example.com   /oracle  comp-user-tar

This technique can be used to work with fail-over services (services bound to a virtual IP-number) if you can manage to warn xinetd when a virtual IP-number becomes activated.

Another use of this technique is to overcome the UDP packet size. When you have many DLE's for one host, the amount of data in a request could overflow one UDP packet. Simulating as if the data is on two or more hosts, can get around this limit.