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.
Шифрование
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После создания цепочки обязательно проверьте её через collection-status. Старый пример ниже показывает вывод этой проверки на локальном repository; для SSH/SCP смысл тот же.
Retention задавайте явно
Без политики хранения репозиторий будет расти. Duplicity умеет удалять старые backup sets через действия вроде remove-older-than или хранить ограниченное число полных цепочек. Перед очисткой сначала проверьте текущее состояние и убедитесь, что нужные точки восстановления сохранены.
Восстановление нужно тестировать заранее
Команда restore должна быть знакома до аварии. Периодически восстанавливайте часть данных в отдельный каталог и проверяйте содержимое, владельцев, права и пригодность application data.
duplicity scp://backup@backup.example.net//srv/backups/server1 /tmp/restore-testВосстановление нужно проверять на практике. В старом примере Duplicity восстанавливал содержимое в отдельный каталог; этот же принцип используйте и для современных удалённых backend.
Базы данных копируйте консистентно
Архивирование каталога работающей СУБД не гарантирует корректное восстановление. Для PostgreSQL, MySQL/MariaDB и других приложений используйте штатный dump/snapshot-механизм, а уже полученный консистентный результат включайте в Duplicity.
Итог: Duplicity — это не просто команда cron. Нормальная схема включает отдельное хранилище, шифрование, retention, мониторинг последнего запуска и регулярный restore-test. Только тогда резервная копия становится реально рабочей страховкой.
