Deploying Amanda Network Backup for Centralized Server Backup

Deploying Amanda Network Backup for Centralized Server Backup

Introduction: The Problem and Our Solution

You are responsible for production data integrity? One failed disk without centralized backup can take days to recover. Setting up server backup with Amanda is what we do turnkey: we guarantee data safety on tape or disk. With 10+ projects using LTO libraries, we can evaluate your infrastructure in 1 day.

Why We Use Amanda

Amanda (Advanced Maryland Automatic Network Disk Archiver) is a mature open-source tool for centralized backup. According to Amanda documentation, compared to Bacula, it sets up 2–3 times faster for infrastructures up to 20 servers, does not require a separate database, and has built-in NDMP support. Its unique feature is a holding disk: data writes to fast disk first, then tapes to tape in the background, allowing parallel backups without blocking.

How We Deploy Amanda

Our process includes 4 mandatory stages:

1. Infrastructure audit and retention requirements.
2. Software installation and SSH key generation for amandad.
3. Configuration file setup and dump scheduling.
4. Test backup and recovery verification via amrecover.

The full cycle for 5–10 clients takes 2–3 days. After each stage we perform a verification check.

Configuration Details

All configuration files reside in /etc/amanda/<config-name>/. The config name is the backup domain name. Example for DailySet1 with disk storage:

# /etc/amanda/DailySet1/amanda.conf
org "Production Backup"
mailto "[email protected]"
dumpuser "amandabackup"
inparallel 4
holdingdisk hd1 {
    directory "/amanda/holding"
    use 50 GB
    chunksize 1 GB
}
define tapetype DISK {
    length 200 GB
    filemark 4 KB
    speed 200 MBps
}
define dumptype global {
    auth "ssh"
    ssh_keys "/var/lib/amanda/.ssh/id_rsa"
    compress none
    encrypt srv-blowfish
    index yes
}
define dumptype comp-root-tar {
    global
    program "GNUTAR"
    compress server fast
    exclude list "/etc/amanda/DailySet1/exclude.list"
}
# /etc/amanda/DailySet1/disklist
app-server-01 /etc comp-root-tar
app-server-01 /var/www comp-root-tar
db-server-01 /etc comp-root-tar
db-server-01 /var/lib/pgsql global
web-server-01 /etc comp-root-tar
web-server-01 /var/www comp-root-tar
# /etc/amanda/DailySet1/changer.conf
tapedev "/amanda/vtapes/DailySet1"
tpchanger "chg-disk:/amanda/vtapes/DailySet1"
tapetype DISK
tapecycle 14

Before running, verify configuration with amcheck -c DailySet1. Start the first backup manually: amdump DailySet1. Check status with amstatus DailySet1.

Common Errors and Solutions

• ERROR: Connection refused — the amandad daemon is not running on the client via inetd/xinetd, or the server is not allowed in hosts.allow. Solution: add amanda: a.b.c.d (server IP) to /etc/hosts.allow.
• Holding disk overflow (>80%) — Amanda will refuse to start a backup. Use amadmin DailySet1 holding to view used space, then amflush DailySet1 to write data to tape.
• Incorrect tapetype — if the actual volume capacity is less than specified, Amanda will ask to swap volumes mid-backup. Use amtapetype to measure real speed and size.

Tape vs Disk Comparison

Backup Monitoring and Alerting

Backup without monitoring is false security. We configure Amanda to send reports by email and integrate logs with Prometheus or Zabbix. Key metrics we track: last dump status per client, holding disk usage, free space on tape or disk volumes, backup duration relative to the maintenance window.

If holding disk is more than 85% full, the system sends an alert proactively. This is critical: at 100% Amanda refuses to start the next backup, and you lose a day without notification. We set up a cron script check_amanda_health.sh that reviews logs from the last 24 hours and sends alerts to PagerDuty or Slack on errors.

We also test recovery quarterly — amrecover on a test server with integrity verification. This is the only way to confirm backups actually work. Based on the test, we record RTO (recovery time objective) for each critical service. Our clients receive a recovery test report — documented proof for auditors and insurers.

What’s Included in Our Service

We provide:

• Configuration and recovery documentation.
• Automation scripts for cron schedules and monitoring.
• One day of training for your engineers.
• One month of post-launch support.

Timeline

Pricing is determined after infrastructure audit and retention requirements. Contact us for a consultation — we will evaluate your project.

amrecover DailySet1
amrecover> sethost db-server-01
amrecover> setdisk /var/lib/pgsql
amrecover> list
amrecover> add postgresql.conf
amrecover> extract