Налаштування бекапування серверів через Amanda

Вступ: проблема і наше рішення

Ви відповідаєте за цілісність даних у продакшені? Один збійний диск — і без централізованого бекапу відновлення може зайняти дні. Налаштування бекапування серверів через Amanda — це те, що ми робимо під ключ: гарантуємо збереження даних на стрічці або диску. Наш досвід — 10+ проєктів з бібліотеками LTO, і ми готові оцінити вашу інфраструктуру за 1 день.

Чому ми використовуємо Amanda?

Amanda (Advanced Maryland Automatic Network Disk Archiver) — зрілий open-source інструмент для централізованого бекапування. Згідно з Amanda documentation, у порівнянні з Bacula він налаштовується швидше у 2–3 рази для інфраструктур до 20 серверів, не потребує окремої бази даних і має вбудовану підтримку NDMP. Унікальна особливість — holding disk: дані спочатку записуються на швидкий диск, а потім дозаписуються на стрічку у фоновому режимі, що дозволяє паралельно бекапити кількох клієнтів без блокувань.

Як ми розгортаємо Amanda?

Процес включає 4 обов'язкові етапи:

1. Аудит інфраструктури та вимог до термінів зберігання.
2. Встановлення ПЗ та генерація SSH-ключів для amandad.
3. Налаштування конфігураційних файлів та розкладу дампу.
4. Тестовий бекап та перевірка відновлення через amrecover.

Повний цикл для 5–10 клієнтів займає 2–3 дні. Після завершення кожного етапу ми проводимо контрольну перевірку. Вартість налаштування залежить від обсягу, комплексний проєкт зі стрічковою бібліотекою — визначається після аудиту.

Конфігурація в деталях

Усі файли конфігурації зберігаються в /etc/amanda/<config-name>/. Ім'я конфігурації — ім'я бекап-домену. Приклад для DailySet1 з дисковим сховищем:

# /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

Перед запуском перевірте конфігурацію через amcheck -c DailySet1. Перший бекап запускається вручну: amdump DailySet1. Статус — amstatus DailySet1.

Типові помилки та їх вирішення

• ERROR: Connection refused — на клієнті не запущено amandad через inetd/xinetd, або в hosts.allow не вказано сервер. Рішення: додайте запис amanda: a.b.c.d (IP сервера) до /etc/hosts.allow.
• Holding disk переповнений (>80%) — Amanda відмовиться запускати бекап. Використовуйте amadmin DailySet1 holding для перегляду зайнятого місця, потім amflush DailySet1 для запису даних на стрічку.
• Неправильний tapetype — якщо реальна ємність тому менша за вказану, Amanda запросить зміну тому в середині бекапу. amtapetype вимірює реальну швидкість та об'єм.

Порівняння: стрічка vs диск

Моніторинг бекапів та алертинг

Бекап без моніторингу — це ілюзія безпеки. Ми налаштовуємо отримання звітів Amanda електронною поштою та інтегруємо логи з Prometheus або Zabbix. Ключові метрики, які відстежуємо: статус останнього дампу кожного клієнта, зайнятість holding disk, вільне місце на стрічкових або дискових томах, час виконання бекапу відносно вікна обслуговування.

Якщо holding disk заповнений більш ніж на 85%, система завчасно надсилає алерт. Це критично: при заповненні до 100% Amanda відмовиться запускати наступний бекап, і ви втратите добу без повідомлення. Налаштовуємо cron-скрипт check_amanda_health.sh, який перевіряє логи за останні 24 години і при помилках надсилає сигнал у PagerDuty або Slack.

Окремо тестуємо відновлення раз на квартал — amrecover на тестовому сервері з верифікацією цілісності. Це єдиний спосіб переконатися, що бекап реально працює. За результатами тесту фіксуємо RTO (час відновлення) для кожного критичного сервісу. Нашим клієнтам ми надаємо звіт про тестування відновлення — документальне підтвердження для аудиторів та страхових компаній.

Що входить в роботу

Ми надаємо:

• Документацію з конфігурації та відновлення.
• Скрипти автоматизації для cron-розкладів та моніторингу.
• Навчання ваших інженерів (1 день).
• Місяць підтримки після запуску.

Строки та вартість

Вартість розраховується індивідуально після аудиту інфраструктури та вимог до зберігання. Зверніться до нас для консультації — ми оцінимо проєкт.

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