Backup

Настройка резервного копирования на WebDAVS в Manjaro: Backupninja + Duplicity

Как настроить резервное копирование в Manjaro Linux с помощью связки backupninja и duplicity на внешнее хранилище WebDAVS? Как спасти себя от внезапных цифровых катастроф: настройка, конфигурация, примеры, подводные камни. WebDAV, бэкап, duplicity, backupninja, шифрование, cron, Manjaro Linux — всё в одной статье.

Как настроить резервное копирование в Manjaro Linux с помощью связки backupninja и duplicity на внешнее хранилище WebDAVS?
Как спасти себя от внезапных цифровых катастроф: настройка, конфигурация, примеры, подводные камни и всё это — с иронией и пользой.

Предисловие: Бэкап или Поцелуй Хаосу

Привет! Сегодня поговорим о том, о чем кричат на каждом углу, но делают единицы: о резервном копировании. Да-да, я знаю, вы уже зеваете. Про важность бэкапов сейчас не говорит только ленивый утюг. «У меня RAID-1!», – скажете вы. «У меня новый SSD!», – добавит сосед.

Но вот только вчера обратился человек — что-то сайты не доступны… На его почти новом сервере одновременно отправились в silicon heaven оба жестких диска из массива. RAID-1?
И традиционно: бэкапов на внешнем носителе или удаленном хранилище – нет. «RAID же!»

Лирическое отступление: Почему RAID – это не бэкап (Краткий курс выживания):

  • Человеческий фактор: sudo rm -rf / --no-preserve-root по пьяни. Или скрипт-шалунишка. RAID радостно удалит данные везде.
  • Аппаратная авария: Как в истории выше. Блок питания решил устроить фейерверк и поджарил все диски разом. Или контроллер RAID’а вышел в тихий час. Или потоп. Или пожар. Или… ну вы поняли.
  • Зловредное ПО: Шифровальщик радостно зашифрует ваш прекрасный RAID. Или тихо повредит файлы.
  • Логическая порча: Баг в софте, кривое обновление – и ваши ценные данные превращаются в тыкву. RAID синхронно отразит эту тыкву на всех дисках.
  • RAID спасает от одного-двух типов факапов: например, когда диск просто умирает от старости или поёт последний куплет из-за заводского брака. Но он не выручит, если у вас убитый блок питания убивает диски пачками.

Почему бэкапы должны быть ВНЕ основного сервера:

Все просто: физическое и/или логическое разделение. Если сгорел сервер – бэкапы на другом железе (или в облаке) целы. Если вас шифруют – бэкапы на отдельном сервисе (вроде нашей WebDAVS-шары) не тронуты. Это не панацея, но шансы выжить данных вырастают на порядки.

Вывод:

Бэкапить. Надежно. Регулярно. Автоматически. На сторонний носитель.Почему?
Потому что если:

  • вы пробросили WebDAV через HTTPS (а мы так и сделаем),
  • зашифровали бэкап (а мы и это тоже сделаем),
  • и держите его вне основного хоста,

— то шансов потерять всё становится ощутимо меньше.

Средства резервного копирования

Инструментов много: rsync, restic, borg, duplicity, déjà-dup, rsnapshot, timeshift (больше для десктопов), и даже tar + cron, если руки прямые и есть чувство азарта.

Сегодня мы возьмем проверенную связку: Backupninja как «дирижера» и Duplicity как «исполнителя» для отправки бэкапов на удаленный WebDAVS сервер, затронем нюансы работы с WebDAVS в локальной сети (хотя можно отправлять бэкапы в хранилища на Nextcloud, Owncloud, Yandex Disk, любой другой WebDAVS-совместимый хостинг).

Почему WebDAVS?

HTTPS, авторизация – уже неплохо для домашнего/малого бизнес использования.

Суть: Настраиваем Backupninja + Duplicity на Manjaro для WebDAVS

Описание:

  • Duplicity: Это крутой инструмент, который умеет делать инкрементальные бэкапы (только изменения), шифровать их через GPG (опционально, но очень рекомендую!), работать с кучей протоколов (включая наш webdavs://) и хранить историю. Он – сердце процесса.
  • Backupninja: Это не менее крутой «оркестратор». Его задача – запускать в нужное время (через cron) нужные скрипты резервирования (handlers), в нашем случае – скрипт для Duplicity. Он умеет настраивать расписание, уровни nice/ionice, логировать, обрабатывать ошибки. Главная фишка – конфиги в /etc/backup.d/ читаются как простые INI-файлы. Backupninja – мозг (и часы) процесса.

Установка:

Поехали! Ставим необходимые пакеты в Manjaro:

sudo pacman -S backupninja duplicity lsb-release

Возможно, придется поставить backupninja-git из AUR.
Могут потребоваться дополнительные пакеты:

sudo pacman -S python-boto python-paramiko
sudo pacman -S python-lockfile python-pydrive python-requests-oauthlib


Также, может потребоваться вручную создать каталог для временных файлов:

sudo mkdir -p /var/cache/backupninja/
sudo chown root:root /var/cache/backupninja/
sudo chmod 700 /var/cache/backupninja/

Теперь конфиг backupninja для duplicity

Создаем файл конфигурации для нашего бэкапа, например: /etc/backup.d/10-remote-webdav.dup. В имени файла определяется порядок выполнения (10 — раньше, 99 — позже) и обработчик — суффикс.dup говорит backupninja, что это конфиг для duplicity.
Пример конфига:

# /etc/backup.d/10-remote-webdav.dup
# Основные настройки Backupninja
enabled = yes
when = everyday at 04:00  # Время "Ч", когда бэкап стартует. Выберите свое!
report_success = no       # Слать отчет об успехе? (Можно =yes)
report_warning = yes      # Слать предупреждения? (Желательно =yes!)
report_error = yes        # Слать ошибки? (Обязательно =yes!)
nicelevel = 19            # Максимально низкий приоритет CPU, чтобы не мешать системе
# ionicelevel =           # Приоритет I/O (если знаете, что делаете, раскомментируйте и настройте)

# Настройки GPG (Шифрование - СИЛЬНО РЕКОМЕНДУЕТСЯ!)
[gpg]
sign = no                     # Не подписывать бэкапы цифровой подписью (можно =yes, если есть ключ)
encryptkey =                  # ID ПУБЛИЧНОГО GPG ключа для шифрования (ОЧЕНЬ ЖЕЛАТЕЛЬНО!)
#signkey =                    # ID вашего ПРИВАТНОГО GPG ключа для подписи (если sign=yes)
password = ваш_сложный_пароль # Пароль для расшифровки (если encryptkey указан). ХРАНИТЕ БЕЗОПАСНО!
#signpassword =               # Пароль от приватного ключа подписи (если signkey указан)

# Что бэкапим (include) и что игнорируем (exclude)
[source]
include = /etc              # Конфиги системы - святое!
include = /home             # Домашние директории пользователей (осторожно с правами!)
include = /root             # Домашка root
include = /var/spool/cron   # Задания cron пользователей
# include = /var/lib/dpkg/status* # Инфо об установленных пакетах (для apt-систем, в Manjaro pacman, так что актуальность под вопросом)
# include = /usr/local/bin   # Ваши локальные скрипты/бинарники
# include = /opt             # Софт в /opt

# Примеры исключений (подстраивайте под себя!)
exclude = /home/*/.cache       # Кеш
exclude = /home/*/.thumbnails  # Миниатюры
exclude = /home/*/.local/share/Trash  # Корзины
exclude = /home/*/.Trash
exclude = /home/*/.gnupg       # Папки GPG (осторожно! Если не уверены в восстановлении ключей, лучше бэкапить БЕЗ паролей!)
exclude = /home/*/gtk-gnutella-downloads # Пример временных загрузок
exclude = /var/cache           # Системный кеш (обычно не нужен)
exclude = /tmp                 # Временные файлы
exclude = /proc                # Виртуальная ФС
exclude = /sys                 # Виртуальная ФС
exclude = /dev                 # Устройства
exclude = /run                 # Runtime данные
exclude = /mnt                 # Точки монтирования
exclude = /media               # Точки монтирования
exclude = /var/cache/backupninja/duplicity # Кеш duplicity - бэкапить его смысла нет!

# Настройки Duplicity (Куда и Как)
[dest]
incremental = yes          # Использовать инкрементальные бэкапы? (Да!)
increments = 7             # Сколько инкрементальных бэкапов делать до создания очередного full backup.
keep = 17                  # Сколько дней хранить бэкапы (история)
keepincroffulls = 2        # Сколько ПОЛНЫХ бэкапов хранить дополнительно к цепочкам инкрементов (для надежности)
desturl = webdavs://webdav_user@ваш.домен.или.IP:порт/путь/на/сервере/backups  # Это важно. Пример: webdavs://bkpuser@cloud.example.com:443/remote.php/dav/files/bkpuser/manjaro-server/
ftp_password = ваш_пароль_webdav_user  # Пароль пользователя WebDAVS. Имя опции сбивает с толку, но тем не менее - это не ошибка. Именно здесь пароль для webdavs.
bandwidthlimit = 0         # Лимит скорости (Кбит/с). 0 = без ограничений. Ставьте, если бэкап съедает весь канал.
# sshoptions =             # Опции SSH (если использовали sftp://, тут не нужно)

И просто для удобства — мой конфиг, используемый на ноутбуке с Manjaro и WebDAVS в локальной сети:

options = --verbosity 8
nicelevel = 19
ionicelevel = 
[gpg]
sign = no
encryptkey = 
signkey = 
password = crypt_uncrypt_password
signpassword = 
[source]
include = /var/spool/cron/crontabs
include = /etc
include = /root
include = /home/user
include = /usr/local/*bin
exclude = /home/*/.gnupg
exclude = /home/*/.local/share/Trash
exclude = /home/*/.Trash
exclude = /home/*/.thumbnails
exclude = /home/*/.beagle
exclude = /home/*/.aMule
exclude = /home/*/gtk-gnutella-downloads
exclude = /var/cache/backupninja/duplicity
[dest]
incremental = yes
increments = 7
keep = 17
keepincroffulls = 2
desturl = webdavs://login@domain.keenetic.pro:6087/webdav/aspire/home-user
ftp_password = WEBDAVS_PASSWORD
bandwidthlimit = 0
sshoptions =

Пароли, домены и пользователи разумеется изменены — все совпадения случайны ;)

Еще немного описания опций
  • when: Говорит backupninja когда запускать этот бэкап. Формат гибкий: everyday at HH:MM, weekly on Monday at HH:MM, monthly at HH:MM.
  • report_*: Куда слать отчеты (обычно на email root). Настройте sendmail или почтовый релей, чтобы получать уведомления!
  • nicelevel/ionicelevel: Позволяют сделать процесс бэкапа максимально «незаметным» для системы.
  • [gpg]: Если WebDAV сервер не локальный — серьезно подумайте о шифровании (encryptkey)! Бэкапы на стороннем сервере должны быть зашифрованы. Да и на локальном желательно.
    Сгенерируйте GPG ключ (gpg --full-generate-key), возьмите его публичный ID (выводится командой gpg --list-keys) и укажите в encryptkey. Пароль password – это пароль для этого бэкапа, который будет использоваться при восстановлении. Запомните/запишите его ОЧЕНЬ надежно! Если не шифруете (encryptkey пуст), пароль password не нужен.
  • [source]: Тут вся магия что бэкапить. include – пути для включения. exclude – для исключения. Адаптируйте исключения (exclude) под свои нужды! Исключение кешей и временных файлов экономит место и время. Исключение /var/cache/backupninja/duplicity критически важно!
  • [dest]: Тут магия куда копировать и как долго хранить.
    • incremental = yes: Основа экономии места и времени. Полный бэкап делается периодически (зависит от keep, increments), между ними – бэкапы только изменений.
    • increments = 7: Хранит цепочки из 7 инкрементальных бэкапов после каждого полного. Когда цепочка достигает 7 инкрементов, создается новый полный бэкап, и цепочка начинается заново.
    • keep = 17: Хранить 17 дней. Старые полные бэкапы и их цепочки инкрементов удаляются автоматически.
    • keepincroffulls = 2: Дополнительная страховка. Хранит еще 2 самых старых полных бэкапа сверх того, что указано в keep. Помогает, если последний полный бэкап оказался битым.
    • desturl: Адрес назначения. Для WebDAVS в формате webdavs://. Критически важно:
      • webdavs:// (с s!) – использует HTTPS.
      • webdav_user@ – логин на вашем WebDAVS сервере.
      • ваш.домен.или.IP:порт – адрес и порт сервера (стандартно 443, если не меняли).
      • /путь/на/сервере/backups – путь на сервере куда писать бэкапы. Узнайте точный путь у вашего провайдера (для Nextcloud/Owncloud обычно /remote.php/dav/files/ИМЯ_ПОЛЬЗОВАТЕЛЯ/).
    • ftp_password: Пароль пользователя webdav_user. Храните этот файл конфигурации (10-remote-webdav.dup) в безопасности! (права 0600). Более безопасный способ – использовать переменные окружения.
    • bandwidthlimit = 0: Без ограничений скорости. Если бэкап мешает работе, установите лимит (например, bandwidthlimit = 1024 для 1 Мбит/с).

Backupninja Global Config & Cron

Сам backupninja имеет глобальный конфиг /etc/backupninja.conf.

Там можно настроить глобальные параметры логирования, отчетности и т.д.
Чаще всего его трогать не нужно, но можно задать общий лог, таймауты и т.п.

Также есть задание в /etc/cron.d/backupninja. Этот cron-файл, обычно, запускает backupninja каждый час. Backupninja уже сам смотрит внутри на свои конфиги в /etc/backup.d/ и выполняет только те, у которых enabled = yes и время (when) совпадает с текущим.

Маленький нюанс про WebDAVS в локальной сети

Нюанс действительно маленький, но может стоить времени и нервов. В зависимости от окружения и настроек, попытка подключения к webdavs по IP узла в локальной сети может заканчиваться ошибкой, например:

SSL handshake failed: SSL error: tlsv1 unrecognized name

Это может быть связано с тем, что сервер пытается использовать SNI (Server Name Indication), но по IP-адресу SNI не поддерживается.

Можно попробовать решить это следующим костыльным способом (да-да, костыль в этой статье тоже присутствует, куда же без него):

В файле /etc/hosts добавить что-то вроде:

192.168.1.1 mywebdavs.host

Здесь 192.168.1.1 — это IP-адрес Вашего webdavs-сервера, а mywebdavs.host — это домен, по которому вы будете к нему подключаться. Добавив это, в настройках программы используйте именно домен, а не IP-адрес для подключения. Это может помочь. Мне помогло.

Переходим к последнему немаловажному вопросу.

Как восстанавливать

4.1 Базовые команды Duplicity для восстановления:

  1. Список файлов в бэкапе (чтобы найти что восстанавливать):
sudo duplicity list-current-files webdavs://webdav_user@domain.tld:port/webdav/pcname/dirname
  • Важно: Если бэкап зашифрован (encryptkey использовался), нужно указать пароль (или использовать PASSPHRASE в переменных окружения):
sudo PASSPHRASE="ваш_сложный_пароль" duplicity list-current-files webdavs://...

Восстановить ОДИН файл/папку:

sudo duplicity \
  --file-to-restore /etc/important.conf \ # Путь К ФАЙЛУ В БЭКАПЕ (как он есть в списке)
  webdavs://webdav_user@domain.tld:port/webdav/pcname/dirname \ # URL хранилища
  /tmp/restored_important.conf # КУДА восстановить (локальный путь)
  • Для шифрованных: sudo PASSPHRASE="пароль" duplicity --file-to-restore ...

Восстановить ВСЁ на определенную дату (магия --time):

sudo duplicity \
  --restore-time '2024-07-01T04:00:00' \ # Восстановить состояние НА ЭТУ ДАТУ
  webdavs://webdav_user@domain.tld:port/webdav/pcname/dirname \ 
  /mnt/recovery_drive/ # КУДА восстановить ВСЮ ФС (директория должна существовать!)
  • Формат даты: YYYY-MM-DD, YYYY-MM-DDTHH:MM:SS (ISO 8601). Можно 1D (1 день назад), 2W (2 недели назад) и т.д.
  • Шифрование: sudo PASSPHRASE="пароль" duplicity --restore-time ...

Восстановить ПОСЛЕДНЕЕ СОСТОЯНИЕ:
Просто убери --restore-time:

sudo duplicity webdavs://... /mnt/recovery_drive/

    4.2 КРИТИЧЕСКИ ВАЖНЫЕ ШАГИ ПОСЛЕ НАСТРОЙКИ БЭКАПА:

    1. СРАЗУ ЖЕ СДЕЛАЙ ПЕРВЫЙ ПОЛНЫЙ БЭКАП (FULL):
      sudo backupninja -n /etc/backup.d/10-remote-webdav.dup — Жди долго.
    2. ПРОТЕСТИРУЙ ВОССТАНОВЛЕНИЕ!
      Хотя бы одного маленького файла (например, /etc/hosts или конфига самого бэкапа) на тестовую директорию (/tmp/test_restore/). Убедись, что:
      • Ты знаешь точный desturl.
      • Ты знаешь пароль WebDAVS (ftp_password).
      • Если шифровал: Ты знаешь PASSPHRASE (пароль шифрования) и он работает.
      • Команда восстановления выполняется без ошибок.
      • Восстановленный файл идентичен оригиналу (diff, md5sum).
    3. ЗАПИШИ ГДЕ-ТО БЕЗОПАСНО (НЕ НА ЭТОМ СЕРВЕРЕ):
      • Полный desturl.
      • Логин/пароль WebDAVS.
      • PASSPHRASE для расшифровки (если шифровал). БЕЗ ЭТОГО БЭКАПЫ = МУСОР.
      • Пример команды восстановления всего (duplicity --restore-time ...).
    4. ЗАПЛАНИРУЙ РЕГУЛЯРНЫЕ ТЕСТЫ ВОССТАНОВЛЕНИЯ:
      Хотя бы раз в квартал восстанавливай случайный файл или директорию на тестовый стенд. Это единственный способ быть уверенным, что процесс не сломался после обновлений, смены сертификатов, квот на хранилище и т.д.
    5. ПОДУМАЙ О ВОССТАНОВЛЕНИИ С «ГОЛОГО» ЖЕЛЕЗА:
      Как ты установишь duplicity на новый сервер, чтобы начать восстановление? Где возьмешь GPG ключ для расшифровки (если использовал encryptkey)? Это отдельный план действий!

    Почему это ВАЖНЕЕ всего остального:

    Потому что когда приходит беда (сервер мертв, диск рассыпался, шифровальщик атаковал):

    1. У тебя нет времени гуглить мануалы по duplicity.
    2. У кого-то дрожат руки и мокрый лоб.
    3. Чаще всего не помнишь точный URL хранилища или пароль.
    4. Если ты никогда не пробовал восстанавливать — высока вероятность что-то упустить или сломать в панике.

    Настройка бэкапа — это 20% работы. Гарантированное восстановление — это оставшиеся 80%.

    Ответить