10.

1 Amanda Backup Solution

What is Amanda?
AMANDA, the Advanced Maryland Automatic Network Disk Archiver, is a backup system that allows the administrator to set up a single master backup server to back up multiple hosts over network to tape drives/changers or disks or optical media. Amanda uses native dump and/or GNU tar facilities and can back up a large number of workstations running multiple versions of Unix. Amanda uses Samba, Cygwin or a native Windows client to back up Microsoft Windows desktops and servers. This document describes how to set up Amanda on Ubuntu machie. The resulting system provides a flexible backup-system with many features. It will be able to back up multiple hosts via network to various devices. I chose the disk based backup for this lesson.

Preparation
Set up a basic Debian system and a basic Ubuntu system update both. The Debian system will be the backup-host: server1.example.com. The Ubuntu system will be the backupclient: server2.example.com.

Needed Packages On The Backup-Host

apt-get install amanda-server xinetd gawk gnuplot readlinecommon

Backup-Host Configuration
Note: I'm using the standard configuration DailySet1 in this howto. Amanda.conf We customize the amanda.conf for DailySet1 to our needs: vi /etc/amanda/DailySet1/amanda.conf Edit the following, existing lines, so that they look like this: tapecycle 6 tapes tapetype DISK tpchanger "chg-disk"

changerfile "/etc/amanda/DailySet1/changer" tapedev "file:/dumps/amandatapes/DailySet1" Now add the tapetype definition for the virtual tapedevice. In this example I chose a size of 3GB for each virtual tape - resulting in a required space of 18GB for all six virtual tapes. Adjust it to your needs. define tapetype DISK { comment "Backup to HD" length 3072 mbytes } Next we have to add a dumptype where we define the settings for the backups. But of course you can use the existing dumptypes. Make sure that you use/create one with the entry program "GNUTAR". All possible settings are well commented in the amanda.conf. define dumptype example { global comment "example dumptype" compress client fast program "GNUTAR" strategy standard priority high } Virtual Tapedevice First we have to prepare a directory-tree for amanda where the backups will be stored temporarily (the holding disk): mkdir -p /dumps/amanda Now we have to create a directory for the virtual tapedevice: mkdir -p /dumps/amandatapes/DailySet1 In the next step we have to create the directories for the virtual tapes. In this example we create six virtual tapes: for i in 1 2 3 4 5 6; do mkdir /dumps/amandatapes/DailySet1/slot${i}; done Create the info file: touch /dumps/amandatapes/DailySet1/info Time to initialize the tapedevice by inserting the first virtual tape into the tapedevice: ln -s /dumps/amandatapes/DailySet1/slot1 /dumps/amandatapes/DailySet1/data Now we have to pass the ownership to the amanda-user: chown -R backup:backup /dumps/ Next we switch to the user backup: su backup Note: All amanda-commands, except amrestore, have to be executed as user backup. Create the tapelist file: touch /etc/amanda/DailySet1/tapelist We have to label the virtual tapes to make them usable for amanda: for i in 1 2 3 4 5 6; do /usr/sbin/amlabel DailySet1 DailySet1-${i} slot ${i}; done The Disklist The disklist brings all together. Here we define what has to be backed up from what server with which settings. A complete entry

for a server consists of the fqdn, the path (e.g. /var) or device (e.g. sda1) that shall be backed up and the dumptype. vi /etc/amanda/DailySet1/disklist server2.example.com /home example Note: Don't forget to add the backup-client to /etc/hosts if you are using this setup in a LAN without an own DNS. Amandahosts Finally we have /etc/amandahosts to edit the amandahosts file: vi

server1.example.com backup server1.example.com root server2.example.com root

Needed Packages On the Backup-Client

sudo apt-get install amanda-client xinetd openssh-server

Amandahosts On The Backup-Client

Add the backup-host /etc/amandahosts to the amandahosts file. sudo vi

server1.example.com backup Note: Don't forget to add the backup-host to /etc/hosts if you are using this setup in a LAN without an own DNS.

Scheduled Backups
Modify the existing crontab (crontab.amanda) in /etc/amanda on the backup-host to your needs.

Testing The Configuration On The Backup Host

/usr/sbin/amcheck DailySet1 should look like: Amanda Tape Server Host Check ----------------------------Holding disk /dumps/amanda: 25063520 KB disk space available, using 24961120 KB slot 1: read label `DailySet1-1', date `20070911' NOTE: skipping tape-writable test Tape DailySet1-1 label ok Server check took 0.254 seconds Amanda Backup Client Hosts Check -------------------------------Client check: 1 host checked in 0.354 seconds, 0 problems found (brought to you by Amanda 2.5.1p1)

Manual Backup

For testing purposes or special reasons you can make a backup manually of course: /usr/sbin/amdump DailySet1 Note: Depending on the size of the data this could take a while.

Restore Backups
Switch to a directory on the backup-host where you (temporarily) want to restore the backup file(s): cd /tmp/ Select The Virtual Tape Insert the virtual tape from which you want to restore the backup(s): /usr/sbin/amtape $configuration slot $x e.g. /usr/sbin/amtape DailySet1 slot 1 9.2 Rewind The Virtual Tape No joke, you have to rewind your HD. :) /usr/sbin/ammt -t file:/dumps/amandatapes/$configuration rewind e.g. /usr/sbin/ammt -t file:/dumps/amandatapes/DailySet1 rewind 9.3 Restore Backup(s) From The Virtual Tape To get all backups from the tape: /usr/sbin/amrestore file:/dumps/amandatapes/$configuration e.g. /usr/sbin/amrestore file:/dumps/amandatapes/DailySet1 To get a single backup from the tape: /usr/sbin/amrestore file:/dumps/amandatapes/$configuration $host $backed_path_or_device e.g. /usr/sbin/amrestore file:/dumps/amandatapes/DailySet1 server2.example.com '/home$' or /usr/sbin/amrestore file:/dumps/amandatapes/DailySet1 server2.example.com sda1 9.4 Transfer The Backup-File To The Client Host I chose scp for this. scp -C $backup_file $user@$backup-client: $destination_file e.g. scp -C server2.example.com._home.20070911.0 administrator@server2.example.com:/tmp/backup Uncompress The Transfered Backup On The Client-Host cd /tmp/ sudo tar xvf backup Virtual Local Area Networks Virtual Local Area Networks are used to devide a physical network into several broadcast domains As you probably already understand, the reason to use vlan's is to divide a network and separate host's that shouldn't be able to access each other. This

article will address the IEEE 802.1q standard way of doing this division. There are two types of packets on a vlan, these are tagged and untagged packets. The untagged packet is a regular packet and looks just like a packet that exists on a regular network. Untagged packets is the most common type on a vlan. The decision of which vlan an untagged packet belongs to is made by the switch. A switch can be configured to assign specific ports to specific vlan's. The switch can also be configured to receive tagged packets. To be able to make use of vlan's you will need a switch (or several) that support the IEEE 802.1q standard. You will also need a NIC (Network Interface Card) that plays nice when used to transmit and receive tagged packets. Many NIC's do support 802.1q but some have trouble with the extra 4 bytes added to the packet when tagged packets are used. If the switch receives a tagged packet and the port which it receives the packet with is configured to allow tagged packets, it knows which ports it can send the packet to. A switch can also be configured to transmit tagged packets, this could be used to make a vlan span more than one switch or to make use of a vlan aware NIC (Network Interface Card) on a router, firewall, server or even a workstation. A vlan is asigned a specific id this id can be anything between 1 and 4094. Vlan 1 is very often used for management so this should not be used SCENARIO : We have a router/firewall with two NIC's one used to connect to the Internet (WAN) and the other to connect to the local network (LAN). We would like to beef up the security aspect of our site and introduce a Demilitarized Zone (DMZ). If this should be implemented without the use of vlan's we would have to buy a new switch and a third NIC for our router/firewall. Luckily the switch used supports 802.1q. The switch configuration is done by adding a new vlan. How this is done should be documented in the switch documentation. Networks WAN 172.16.0.0/24 LAN 192.168.0.0/24 DMZ 10.0.0.0/24 CONFIGURATION sudo apt-get install vlan Load the 8021q module into the kernel. sudo modprobe 8021q Create a new interface that is a member of a specific vlan, vlan id 10 is used. sudo vconfig add eth1 10 Assigning an address to the new interface. sudo ifconfig eth1.10 10.0.0.1 netmask 255.255.255.0

To make this setup permanent, some lines has to be added to some configuration files. Add the module to the kernel on boot. sudo su -c 'echo "8021q" >> /etc/modules' Create the interface and make it available during the boot. Add the following lines to /etc/network/interfaces auto eth1.10 iface eth1.10 inet static address 10.0.0.1 netmask 255.255.255.0 vlan-raw-device eth1 QUAGGA ROUTING DAEMON (RIP,OSPF,BGP) Quagga is an open source routing software based on the Zebra router, for which development was stopped in 2003. It supports the main standardised routing protocols such as RIP, OSPF or BGP and can be installed on any Linux system with a 2.4 or higher kernel. Quagga is composed of several daemons, one per routing protocol and another one called Zebra acting as the kernel routing manager. Each daemon has its own configuration file and terminal interface which can be accessed by telnet. The vtysh tool is provided to configure the Quagga router from the localhost, in a unique interface. Quagga works independently from the operational system (OS) over which it is installed. This is not the case for the open source Vyatta router or the commercial routers where the OS and the routing engine are built together. With Vyatta routers, you can access the operational system (a modified version of the Debian Linux distribution) but even this is not necessary to configure the router. With commercial routers like Cisco or Nortel, you can access only the router interface. It must be emphasised that Quagga owns only routing capabililies and functionalities associated with it, such as access lists or route maps. It does not provide "non-routing" functionalities such as DHCP server, NTP server/client or ssh access but it is often possible to enable them on the operating system supporting your Quagga router. See the Routers' comparison to get an overview about the functionalities available with Cisco, Vyatty or Quagga routers. The Quagga Command line Interface is very similar to the Cisco IOS software allows it to be configured very easily for those who are familiar with Cisco. And finally, little story: the word 'quagga' comes from an extinct animal which was a subspecies of the plains zebra. QUAGGA DAEMONS: You have to activate the Quagga daemons matching the routing protocols you want to set on your router.

zebra: bgpd: ospfd: ospf6d: ripd: ripngd:Interface declaration and static routing BGP routing protocol OSPF routing protocol OSPF IPv6 routing protocol RIP v2 routing protocol RIP Ipv6 routing protocolIn the example below, the zebra and IPv4 OSPF daemon have been activated. #vim /etc/quagga/daemonszebra=yesbgpd=no ospfd=yesospf6d=noripd=noripngd=no Restart the Quagga service: #/etc/init.d/quagga restart Stopping Quagga daemons (prio:0): ospfd zebra (bgpd) (ripd) (ripngd) (ospf6d) (isisd). Removing all routes made by zebra.Nothing to flush. Loading capability module if not yet done.Starting Quagga daemons (prio:10): zebra ospfd. You can check the Quagga daemons status: #ps -ef | grep quaggaUIDPIDPPIDCSTIMETTYTIMECMDquagga46321022:25? 00:00:00/usr/lib/quagga/ospfd --daemonquagga46361022:25? 00:00:00/usr/lib/quagga/zebra --daemonIf a Quagga daemon doesn't stop properly, you can kill it manually and start the quagga service: #kill -9 "UID number"#/etc/init.d/quagga start QUAGGA DAEMONS: You have to activate the Quagga daemons matching the routing protocols you want to set on your router. zebra: bgpd: ospfd: ospf6d: ripd: ripngd:Interface declaration and static routing BGP routing protocol OSPF routing protocol OSPF IPv6 routing protocol RIP v2 routing protocol RIP Ipv6 routing protocolIn the example

below, the zebra and IPv4 OSPF daemon have been activated. #vim /etc/quagga/daemonszebra=yesbgpd=no ospfd=yesospf6d=noripd=noripngd=no Restart the Quagga service: #/etc/init.d/quagga restartStopping Quagga daemons (prio:0): ospfd zebra (bgpd) (ripd) (ripngd) (ospf6d) (isisd). Removing all routes made by zebra.Nothing to flush. Loading capability module if not yet done.Starting Quagga daemons (prio:10): zebra ospfd. You can check the Quagga daemons status: #ps -ef | grep quaggaUIDPIDPPIDCSTIMETTYTIMECMDquagga46321022:25? 00:00:00/usr/lib/quagga/ospfd --daemonquagga46361022:25? 00:00:00/usr/lib/quagga/zebra --daemonIf a Quagga daemon doesn't stop properly, you can kill it manually and start the quagga service: #kill -9 "UID number"#/etc/init.d/quagga startCONFIGURATION FILES: (/etc/quagga/*.conf files) You must create a configuration file (even if it is empty) each time you activate a Quagga daemon. Each daemon is associated with a specific file name: zebra: bgpd: ospfd: ospf6d: ripd: ripngd:zebra.conf bgpd.conf ospfd.conf ospf6d.conf ripd.conf ripngd.confTo create the config files, copy the sample config files as follows: In our example, as we activated the zebra and ospfd daemons; we need to create the zebra.conf and ospfd.conf files. #cp /usr/share/doc/quagga/examples/zebra.conf.sample /etc/quagga/zebra.conf #cp /usr/share/doc/quagga/examples/ospfd.conf.sample

/etc/quagga/ospfd.confAnother way to do it is to create two empty files called /etc/quagga/ospfd.conf and /etc/quagga/zebra.conf. But in this case you cannot telnet a daemon, you need to configure the telnet permissions with vtsh (see below). Finally, give user and group ownership to respectively quagga and quaggavty to the files inside the /etc/quagga directory: #chown quagga.quaggavty /etc/quagga/*.conf #chmod 640 /etc/quagga/*.confRestart the Quagga service: #/etc/init.d/quagga restart DEBIAN.CONF FILE By default, the Quagga daemons are listening only to the loopback interface 127.0.0.1. It means that you can telnet a daemon only on its loopback address 127.0.0.1 and thus cannot access it remotely. If you want to telnet a Quagga daemon remotely you can, in the /etc/quagga/debian.conf file. Either indicate one or several IP addresses or remove the -A option meaning that you can telnet a daemon on any of its IP addresses. Here are two examples: The ospfd daemon is listening to the 127.0.0.1 and 192.168.1.104 IP addresses. ospfd_options=" --daemon -A 127.0.0.1 192.168.1.104" The zebra daemon is listening to all the Linux interfaces IP addresses. We recommend using this setting. If you want to filter who can access to your router, configure access lists on the router software. zebra_options=" --daemon " Here is the recommended debian.conf file: #vim /etc/quagga/debian.conf# If this option is set the /etc/init.d/quagga script automatically loads # the config via "vtysh -b" when the servers are started. # Check /etc/pam.d/quagga if you intend to use "vtysh"! # vtysh_enable=yes zebra_options=" --daemon -A " bgpd_options=" --daemon -A " ospfd_options=" --daemon -A " ospf6d_options="--daemon -A " ripd_options=" --daemon -A " ripngd_options="--daemon -A " isisd_options=" --daemon -A " The "vtysh_enable=yes" setting is required to access the Quaggga router via vtysh. (see vtysh section). Restart the Quagga service #/etc/init.d/quagga restart