Резервное копирование Linux-сервера с Duplicity: шифрование, инкременты и восстановление

Duplicity подходит для файловых резервных копий Linux, когда нужны инкременты, шифрование и отправка в удалённое хранилище. Он собирает данные в архивные тома, умеет шифровать их GnuPG и поддерживает разные backends, включая SSH/SCP.

Сначала определите, что именно копировать

Не стоит бездумно архивировать весь корень файловой системы. Обычно в backup включают конфигурацию, пользовательские данные, application data и подготовленные дампы баз, а временные каталоги, caches, proc/sys/dev и другие воспроизводимые данные исключают.

Базовый backup на удалённый сервер

Официальная документация Duplicity поддерживает резервное копирование по SCP/SSH. После первой полной копии следующие запуски обычно создают инкрементальную цепочку, если доступна предыдущая сигнатура.

duplicity /srv/data scp://backup@backup.example.net//srv/backups/server1

Перед автоматизацией настройте отдельный SSH-ключ, ограничьте его права и убедитесь, что backup-пользователь не получает ненужный доступ к серверу хранения.

Шифрование

Duplicity умеет шифровать backup volumes через GnuPG. Ключ или passphrase нужно хранить отдельно от единственной копии архива. Потеря ключа шифрования превращает даже идеально сохранившийся backup в бесполезный набор данных.

Проверяйте состояние цепочки

Для контроля репозитория полезны штатные действия collection-status, list-current-files и verify. Они помогают понять, какие backup sets существуют и соответствует ли удалённая копия ожидаемым данным.

duplicity collection-status scp://backup@backup.example.net//srv/backups/server1

Retention задавайте явно

Без политики хранения репозиторий будет расти. Duplicity умеет удалять старые backup sets через действия вроде remove-older-than или хранить ограниченное число полных цепочек. Перед очисткой сначала проверьте текущее состояние и убедитесь, что нужные точки восстановления сохранены.

Восстановление нужно тестировать заранее

Команда restore должна быть знакома до аварии. Периодически восстанавливайте часть данных в отдельный каталог и проверяйте содержимое, владельцев, права и пригодность application data.

duplicity scp://backup@backup.example.net//srv/backups/server1 /tmp/restore-test

Базы данных копируйте консистентно

Архивирование каталога работающей СУБД не гарантирует корректное восстановление. Для PostgreSQL, MySQL/MariaDB и других приложений используйте штатный dump/snapshot-механизм, а уже полученный консистентный результат включайте в Duplicity.

Итог: Duplicity — это не просто команда cron. Нормальная схема включает отдельное хранилище, шифрование, retention, мониторинг последнего запуска и регулярный restore-test. Только тогда резервная копия становится реально рабочей страховкой.