Перейти к основному контенту

2. Backup

Глава 2: Процесс бэкапа — Стратегия, исключения и монолитное заклинание

Просто запустить копирование файлов недостаточно. На живом домашнем сервере постоянно работают базы данных, пишутся логи и кэшируются тяжелые файлы. Если сделать бэкап "на горячую", файлы баз данных могут скопироваться в поврежденном состоянии. В этой главе мы разберем правильную стратегию резервного копирования домашнего сервера.

1. Какую стратегию выбрать: Что бэкапить, а что — нет?

Для полной безопасности личного сервера золотым стандартом является резервное копирование трех ключевых системных директорий:

    /home — Сердце сервера. Здесь живут все Docker-контейнеры, их конфигурационные файлы (docker-compose.yml) и, самое главное, примонтированные папки с пользовательскими данными и базами данных (Nextcloud, Matrix, Firefly III, Wiki). /etc — Конфигурация операционной системы. Здесь хранятся настройки сети, правила монтирования дисков (fstab), конфигурация веб-сервера Nginx и SSL-сертификаты от Certbot (папка /etc/letsencrypt). /root — Домашняя директория суперпользователя. Тут часто оседают кастомные скрипты автоматизации и важные ключи SSH.

    Что бэкапить СМЫСЛА НЕТ?

    Не нужно пытаться скопировать весь жесткий диск целиком (папки вроде /var/lib/docker с образами контейнеров, системные бинарники /usr или /bin). Сами образы Docker — это просто стандартные коробки, скачанные из интернета. Если сервер упадет, Docker автоматически выкачает их заново одной командой docker compose up -d. Главное — сохранить конфигурационные файлы и данные пользователей.

    2. Борьба за свободное место: Настройка исключений (Exclude)

    Restic умеет отсекать ненужный цифровой мусор прямо во время резервного копирования с помощью флага --exclude. Это экономит гигабайты места на сетевом диске и ускоряет процесс бэкапа.

    Мы исключаем из бэкапа две категории данных:

      Данные, которые легко скачать заново: Веса моделей для локальных нейросетей (Ollama, Whisper, Piper). Модели весят гигабайты, но они статичны. В случае сбоя их проще выкачать из сети за пару минут, чем каждую неделю гонять по локальной сети в бэкап. Временные файлы и кэш: Превью-картинки (thumbnails) в Nextcloud, кэш приложений. Зачем тратить место на миниатюры фотографий, если Nextcloud сам сгенерирует их заново при первом просмотре?

      3. Анатомия правильного бэкапа: Зачем тушить контейнеры?

      Такие сервисы как Matrix Synapse, Nextcloud или Firefly III постоянно пишут данные в свои базы (PostgreSQL, MariaDB, SQLite). Если Restic начнет копировать файл базы данных в момент, когда в него совершается запись, бэкап этого файла будет испорчен.

      Правильный алгоритм бэкапа выглядит так:

        Последовательно останавливаем все Docker-контейнеры (docker compose stop). Файлы баз данных "засыпают" и фиксируются на диске. Restic быстро выполняет инкрементальный бэкап (благодаря дедупликации это занимает минимум времени). Последовательно поднимаем все контейнеры обратно (docker compose up -d). Сервер снова в строю.

        4. Проверенное монолитное заклинание бэкапа

        Чтобы автоматизировать весь этот процесс (остановка, исключение мусора, бэкап, запуск), используется одна длинная, монолитная цепочка команд, соединенная оператором &&. Этот оператор гарантирует, что следующая команда выполнится только в том случае, если предыдущая завершилась успешно.

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

        cd ~/homecloud && sudo docker compose stop && cd ~/matrix && sudo docker compose stop && cd ~/firefly-iii && sudo docker compose stop && cd ~/wiki && sudo docker compose stop && cd ~/ollama && sudo docker compose stop && sudo restic -r /mnt/win_backup/homeserver_backup --password-file /home/stan/.restic_pw --exclude="/home/stan/ollama/ollama_data/models" --exclude="/home/stan/ollama/piper" --exclude="/home/stan/ollama/whisper" backup /home /etc /root && cd ~/homecloud && sudo docker compose up -d && cd ~/matrix && sudo docker compose up -d && cd ~/firefly-iii && sudo docker compose up -d && cd ~/wiki && sudo docker compose up -d && cd ~/ollama && sudo docker compose up -d

        Разбор заклинания по винтикам:

          cd ~/service && sudo docker compose stop — переходим в папку сервиса и тушим его контейнеры. Повторяется для Nextcloud, Matrix, Firefly, Wiki и Ollama (вместе с ней тушатся зависимые Piper и Whisper). sudo restic -r /mnt/win_backup/homeserver_backup — указываем Restic путь к нашей смонтированной сетевой шаре Windows. --password-file /home/stan/.restic_pw — скармливаем Restic наш защищенный файл с паролем, чтобы он не просил его интерактивно. --exclude="..." — трижды используем этот флаг, отсекая тяжелые папки с моделями Ollama, Piper и Whisper, расположенные внутри домашней директории. backup /home /etc /root — ключевая команда, запускающая резервное копирование трех важнейших столпов нашего сервера. cd ~/service && sudo docker compose up -d — финальная цепочка: запускаем обратно все контейнеры в фоновом режиме (флаг -d) в обратном или попутном порядке. Сервер снова доступен для пользователей.

          5. Что делать, если бэкап прервался?

          Если во время выполнения команды что-то пойдет не так (например, выключится компьютер с Windows или пропадет сеть), цепочка команд прервется на этапе работы Restic, и контейнеры останутся потушенными.

          В этом случае не нужно паниковать. Достаточно запустить команду принудительного поднятия всех сервисов:

          cd ~/homecloud && sudo docker compose up -d && cd ~/matrix && sudo docker compose up -d && cd ~/firefly-iii && sudo docker compose up -d && cd ~/wiki && sudo docker compose up -d && cd ~/ollama && sudo docker compose up -d
          Наверх