Когда-то давно я настроил бэкап сервера через Relax-and-Recover, а потом благополучно забыл, как это делается. Классика жанра: работает — и ладно. Но однажды пришло время обновить резервную копию, и началось приключение.
Первое открытие: конфиг лежал не в local.conf, а в site.conf. Полдня поисков, потому что память услужливо подсовывала не тот файл. Второе открытие: ReaR наотрез отказывается писать бэкап на тот же диск, где живёт система. Логично — если диск умрёт, бэкап умрёт вместе с ним, и восстанавливать будет нечего.
Решение нашлось элегантное: смонтировать внешний диск ноутбука на сервер через SSH-туннель и sshfs. Реверс-туннель пробрасывает порт с ноутбука на сервер, sshfs монтирует удалённую папку как локальную, и ReaR счастлив — видит отдельную файловую систему.
Но самое интересное началось раньше. Перед бэкапом нужно остановить всё, что работает с PostgreSQL. И вот тут выяснилось, что сервисов, которые лезут в базу, куда больше, чем кажется: различные сервисы, панель управления, дашборд, телеграм-боты, вебхуки, таймеры, которые каждые пару минут что-то собирают и агрегируют. Причём часть из них — oneshot-сервисы, которые не видны в списке запущенных, потому что они отрабатывают за долю секунды и завершаются. Их выдаёт только отдельный поиск по юнит-файлам.
Отдельная история — внешний диск. После обновления системы он перестал определяться. Диск гудит, питание есть, а система его не видит. Оказалось, виноват конкретный USB-порт: воткнул диск в соседний разъём — и всё заработало. Моral: не спешите винить ядро и обновления, иногда достаточно переткнуть кабель.
Сам бэкап занял минут десять. Архив системы, спасательный ISO-образ, логи и метаданные — всё легло на внешний диск. Проверка целостности архива через gzip -t прошла молча, что в мире Linux означает высшую похвалу.
Главный вывод: записывайте, что и как вы настраивали. Потому что через полгода вы не вспомните ни имя утилиты, ни путь к конфигу, ни почему останавливали базу перед запуском. А сервисы — они как тараканы: стоит отвернуться, и вот уже ещё один лезет в PostgreSQL.