Amanda (Advanced Maryland Automatic Network Disk Archiver) is an open source backup system where one central server pulls backups from many clients over the network, plans full and incremental dumps automatically, and keeps an index so you can restore individual files later. In this tutorial you will install an Amanda server on Ubuntu 24.04, store backups on disk using virtual tapes, add a remote client, run and schedule backups, and restore a file with amrecover.
Prerequisites
To follow this guide you need:
- Two servers running Ubuntu 24.04 LTS, for example two CubePath VPS instances on the same private network:
- The backup server, with enough free disk space to hold several copies of the data you back up. This guide uses
/srv/amanda. - A client that holds the data to protect.
- The backup server, with enough free disk space to hold several copies of the data you back up. This guide uses
- A non-root user with
sudoprivileges on both machines. - Each machine able to resolve the other's hostname. Amanda checks host names strictly, so this matters (Step 1 covers it).
In the commands below, replace backup.example.com / your_server_ip with the backup server's name and IP address, and client.example.com / your_client_ip with the client's.
Step 1 - Making the hosts resolve each other
Amanda's bsdtcp authentication checks the connecting host against the .amandahosts file using its resolved name, so both machines need consistent forward and reverse name resolution. If you do not run internal DNS, add both hosts to /etc/hosts on both servers:
sudo nano /etc/hosts
your_server_ip backup.example.com backup
your_client_ip client.example.com client
Check the result from each machine:
getent hosts backup.example.com client.example.com
10.0.0.10 backup.example.com backup
10.0.0.20 client.example.com client
Step 2 - Installing the Amanda server
On the backup server, install the server package and the client package. The client package lets the server back itself up and provides amrecover:
sudo apt update
sudo apt install amanda-server amanda-client
On Debian and Ubuntu, Amanda runs as the existing backup system user, whose home directory is /var/backups. All Amanda commands in this guide run as that user. Confirm the installation:
sudo -u backup amadmin --version
amadmin-3.5.1
Step 3 - Creating the virtual tape storage
Instead of a physical tape drive, Amanda can use the chg-disk changer, which treats a set of directories (slots) as tapes. Create ten slots, a holding disk where dumps are staged before being written to a tape, and the directory for Amanda's state files:
sudo mkdir -p /srv/amanda/vtapes/DailySet1/slot{1..10}
sudo mkdir -p /srv/amanda/holding
sudo mkdir -p /var/lib/amanda/DailySet1/{curinfo,log,index}
sudo chown -R backup:backup /srv/amanda /var/lib/amanda/DailySet1
Ten slots with one tape per run and a weekly dump cycle means you can restore from roughly the last ten days of backups.
Verify the layout:
ls /srv/amanda/vtapes/DailySet1
slot1 slot10 slot2 slot3 slot4 slot5 slot6 slot7 slot8 slot9
Step 4 - Writing the server configuration
Each Amanda configuration lives in its own directory under /etc/amanda. The directory name (DailySet1 here) is the configuration name you pass to every Amanda command. Create it:
sudo mkdir -p /etc/amanda/DailySet1
sudo chown backup:backup /etc/amanda/DailySet1
Create the main configuration file:
sudo -u backup nano /etc/amanda/DailySet1/amanda.conf
org "DailySet1"
mailto "root"
dumpuser "backup"
inparallel 4
netusage 100000 Kbps
dumpcycle 1 week
runspercycle 7
tapecycle 10 tapes
runtapes 1
tpchanger "chg-disk:/srv/amanda/vtapes/DailySet1"
taperscan "traditional"
labelstr "^DailySet1-[0-9][0-9]*$"
autolabel "DailySet1-%%" empty
tapetype "DISK"
define tapetype DISK {
comment "Virtual tapes on disk"
length 20 gbytes
}
infofile "/var/lib/amanda/DailySet1/curinfo"
logdir "/var/lib/amanda/DailySet1/log"
indexdir "/var/lib/amanda/DailySet1/index"
holdingdisk hd1 {
directory "/srv/amanda/holding"
use 10 gbytes
}
define dumptype global {
comment "Settings shared by all dump types"
auth "bsdtcp"
index yes
}
define dumptype comp-tar {
global
comment "GNU tar, compressed on the client"
program "GNUTAR"
compress client fast
}
The key settings are:
dumpcycle 1 weekandrunspercycle 7: every disk gets at least one full backup per week, and Amanda spreads full backups across the seven nightly runs so no single night is overloaded. The other nights take incremental backups.tapecycle 10 tapes: a tape is not overwritten until ten newer tapes exist.autolabel ... empty: Amanda labels empty slots automatically, so you do not have to runamlabelby hand.length 20 gbytes: the maximum size of one virtual tape. Set it to more than the largest nightly backup you expect, and make sure/srv/amandacan hold ten of them.
Next, list what to back up in the disklist. Each line is hostname directory dumptype:
sudo -u backup nano /etc/amanda/DailySet1/disklist
client.example.com /etc comp-tar
client.example.com /var/www comp-tar
backup.example.com /etc comp-tar
Step 5 - Allowing the server to use its own client
The client side of Amanda only accepts requests from hosts listed in the backup user's .amandahosts file. The same file on the server also decides which hosts may browse the index and fetch backups during a restore. On the backup server, allow the server to back itself up and allow root on both machines to restore:
sudo -u backup nano /var/backups/.amandahosts
backup.example.com backup amdump
backup.example.com root amindexd amidxtaped
client.example.com root amindexd amidxtaped
The first line lets the Amanda server run backups (amdump) of its own disks as backup. The other two let root on the server and on the client browse the index (amindexd) and fetch backups (amidxtaped) with amrecover. The file must be owned by backup and not writable by others:
sudo chown backup:backup /var/backups/.amandahosts
sudo chmod 600 /var/backups/.amandahosts
Step 6 - Setting up the client
On the client, install the client package:
sudo apt update
sudo apt install amanda-client
The package registers the amandad daemon with inetd, listening on TCP port 10080. Confirm it is listening:
sudo ss -ltnp | grep 10080
LISTEN 0 64 0.0.0.0:10080 0.0.0.0:* users:(("inetd",pid=2143,fd=7))
If nothing is listening, check that the amanda line exists in /etc/inetd.conf and restart inetd with sudo systemctl restart openbsd-inetd.
Authorize the backup server to run backups on this client:
sudo -u backup nano /var/backups/.amandahosts
backup.example.com backup amdump
sudo chown backup:backup /var/backups/.amandahosts
sudo chmod 600 /var/backups/.amandahosts
Tell amrecover on the client where the index and tape servers are:
sudo nano /etc/amanda/amanda-client.conf
conf "DailySet1"
index_server "backup.example.com"
tape_server "backup.example.com"
auth "bsdtcp"
Finally, allow only the backup server to reach port 10080. If UFW is active on the client:
sudo ufw allow from your_server_ip to any port 10080 proto tcp
For restores, the client connects to the same port on the server, so on the backup server allow the client in:
sudo ufw allow from your_client_ip to any port 10080 proto tcp
Step 7 - Checking the configuration
amcheck validates the server configuration, the virtual tapes, the holding disk, and connects to every client in the disklist. Run it on the backup server as the backup user:
sudo -u backup amcheck DailySet1
A healthy setup ends like this:
Amanda Tape Server Host Check
-----------------------------
Holding disk /srv/amanda/holding: 58 GB disk space available, using 10 GB
slot 1: volume 'DailySet1-01'
Will write to volume 'DailySet1-01' in slot 1.
NOTE: skipping tape-writable test
Server check took 0.412 seconds
Amanda Backup Client Hosts Check
--------------------------------
Client check: 2 hosts checked in 0.603 seconds. 0 problems found.
(brought to you by Amanda 3.5.1)
Fix every reported problem before continuing. The most common ones are covered in the Troubleshooting section.
Step 8 - Running the first backup
Start a backup run manually. amdump does not print progress, it runs until the whole run is finished and then mails a report to the mailto address:
sudo -u backup amdump DailySet1
While it runs, you can follow its progress from a second terminal:
sudo -u backup amstatus DailySet1
When it finishes, print the report of the last run:
sudo -u backup amreport DailySet1
Hostname: backup
Org : DailySet1
Config : DailySet1
Date : September 25, 2026
These dumps were to tape DailySet1-01.
The next tape Amanda expects to use is: 1 new tape.
STATISTICS:
Total Full Incr. Level:#
-------- -------- -------- --------
...
DUMP SUMMARY:
DUMPER STATS TAPER STATS
HOSTNAME DISK L ORIG-KB OUT-KB COMP% MMM:SS KB/s MMM:SS KB/s
------------------ --------- -- -------- -------- ----- ------- ------ ------ -------
backup.example.com /etc 0 5210 980 18.8 0:01 980.0 0:00 9800.0
client.example.com /etc 0 5480 1030 18.8 0:01 1030.0 0:00 10300.0
client.example.com /var/www 0 48220 12040 25.0 0:03 4013.3 0:01 12040.0
Level 0 is a full backup. From the next runs on, you will see level 1 (incremental) entries as Amanda balances the cycle.
Step 9 - Scheduling nightly backups
Amanda has no scheduler of its own, you run amdump from cron. Edit the backup user's crontab:
sudo crontab -u backup -e
0 16 * * 1-5 /usr/sbin/amcheck -m DailySet1
45 0 * * * /usr/sbin/amdump DailySet1
The amcheck -m line checks the setup every weekday afternoon and only sends mail if it finds a problem, giving you time to fix it before the night's run. amdump runs every night at 00:45.
Confirm the crontab was saved:
sudo crontab -u backup -l
Note
amdumpandamcheck -msend their reports by mail. Install a mail transfer agent (for examplepostfixconfigured as a satellite or smarthost) if you want to receive them outside the server.
Step 10 - Restoring files with amrecover
amrecover is an interactive shell for browsing the backup index and extracting files. Run it as root on the client. It extracts into the current directory, so start in an empty directory to avoid overwriting live files:
sudo mkdir -p /root/restore
cd /root/restore
sudo amrecover DailySet1
Inside the amrecover> prompt, select the host and disk, browse, add the files you want and extract them:
sethost client.example.com
setdisk /etc
ls
cd ssh
add sshd_config
extract
quit
extract lists the virtual tapes it needs and asks for confirmation. Answer Y to each prompt. When it finishes, verify the file:
sudo ls -l /root/restore/ssh/sshd_config
-rw-r--r-- 1 root root 3253 Sep 20 09:14 /root/restore/ssh/sshd_config
Use setdate YYYY-MM-DD before ls to browse the backup as it was on an earlier date.
Troubleshooting
amcheck reports "host not found" or "access as backup not allowed from ...". The name the client sees for the server does not match the .amandahosts entry. Run getent hosts your_server_ip on the client and use exactly that name in /var/backups/.amandahosts.
amcheck shows "selfcheck request failed: Connection refused". amandad is not listening on the client, or a firewall blocks port 10080. Check sudo ss -ltnp | grep 10080 on the client and the UFW rules on both hosts.
.amandahosts "must be owned by backup" or "is group/world writable". Reapply chown backup:backup and chmod 600 to /var/backups/.amandahosts.
A run fails with "No acceptable volumes found". All tapes are still protected by tapecycle, or no empty slot exists. Add more slot directories, or lower tapecycle to the number of slots.
Conclusion
You now have an Amanda server that backs up a remote client and itself every night to virtual tapes on disk, checks its own health during the day and lets you restore individual files from any backup still in the tape cycle. As next steps, add the rest of your hosts to the disklist, copy /srv/amanda/vtapes to off-site storage (for example with rclone to an S3 bucket), and test a full restore of a directory at least once a month.