Правило 3-2-1 для домашней инфраструктуры целиком

Сводим воедино бэкап-скрипты из всех статей сайта в одну согласованную стратегию — вместо десятка разрозненных cron-задач, про половину которых вы забудете уже через месяц.

Что такое правило 3-2-1 и почему RAID — не бэкап

Правило простое: 3 копии данных, на 2 разных типах носителей, 1 из которых физически в другом месте. RAID на Synology защищает только от отказа одного диска — он не спасает от случайного rm -rf, шифровальщика, скачка напряжения или банального пожара в квартире. Если единственная копия данных живёт на RAID-массиве внутри одного корпуса, у вас есть отказоустойчивость, но не бэкап.

Дальше — как применить это правило не к абстрактным "данным", а к конкретному стеку сервисов, которые уже описаны в других статьях на сайте.

Инвентаризация: что вообще есть на этом NAS

Прежде чем настраивать копии, стоит явно перечислить, что вообще требует бэкапа — у каждого сервиса своя логика того, что критично, а что можно пересоздать заново:

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

Копия 1 — рабочие тома NAS

Это данные, с которыми сервисы работают прямо сейчас — тома в /volume1/docker/... и медиатека. RAID (SHR, RAID 1/5/6 — в зависимости от модели из статьи про выбор NAS) защищает эту копию от отказа одного диска, но это по-прежнему только одна физическая копия данных в одном корпусе.

Копия 2 — второй носитель локально

Второй носитель — не обязательно второй NAS. Для домашнего сценария этого достаточно: внешний USB-диск, подключённый к NAS, с расписанием через Hyper Backup (Панель управления → пакет Hyper Backup → задача на локальное USB-хранилище). Если в доме есть второй Synology — предпочтительнее Snapshot Replication между двумя NAS: она реплицирует именно снапшоты, устойчивые к изменению файлов "на лету", что особенно кстати для баз данных вроде Nextcloud и Immich.

Копия 3 — офсайт

Третья копия физически в другом месте защищает от всего, что угрожает самой квартире или дому целиком — пожар, потоп, кража. Варианты для домашней инфраструктуры, от простого к сложному:

• Hyper Backup в облако (Backblaze B2, S3-совместимое хранилище, Synology C2) — встроенная поддержка, минимум настройки, шифрование клиентской стороной (см. следующий раздел).
• Второй NAS у родственников/друзей — Snapshot Replication или Hyper Backup через интернет на NAS в другом городе, ноль ежемесячных затрат на облако, но требует чужого доверия и стабильного канала на обеих сторонах.
• Ротация внешних дисков — самый бюджетный вариант: раз в месяц забирать диск с полной копией к себе на работу или к родственникам, вручную. Менее удобно, но лучше, чем ничего, если облако и второй NAS не вариант.

Оркестрация: единое расписание вместо хаоса

У каждого сервиса в предыдущих статьях свой отдельный bash-скрипт бэкапа. Если запускать их все одновременно по крону — куски работы будут конкурировать за диск и сеть, а окно бэкапа Nextcloud (с включённым maintenance:mode) может наложиться на активное использование другого сервиса. Разумнее — один оркестрирующий скрипт с чёткой последовательностью и паузами:

#!/bin/bash
set -e
LOG=/volume1/docker/backup-orchestrator/last-run.log

echo "=== backup start: $(date) ===" > "$LOG"

/volume1/docker/vaultwarden/backup.sh          >> "$LOG" 2>&1
/volume1/docker/nginx-proxy-manager/npm-backup.sh >> "$LOG" 2>&1
sleep 30

/volume1/docker/nextcloud/nc-backup.sh         >> "$LOG" 2>&1
sleep 60

/volume1/docker/homeassistant/ha-backup.sh     >> "$LOG" 2>&1
/volume1/docker/immich/immich-backup.sh        >> "$LOG" 2>&1

echo "=== backup finished: $(date) ===" >> "$LOG"
mail -s "Бэкап NAS завершён" you@example.com < "$LOG"

Пауза после сервисов с базами данных (Nextcloud, Immich) — не формальность: дампу PostgreSQL нужно время освободить ресурсы диска, прежде чем следующий сервис начнёт свою часть работы, особенно на моделях NAS с 2–4 ГБ RAM без большого запаса.

Шифрование офсайт-копии

Копия, которая физически уезжает в чужой дата-центр (Backblaze B2, S3, Synology C2), обязана быть зашифрована на стороне клиента до отправки — Hyper Backup поддерживает это встроенно при создании задачи. Ключевой момент: пароль шифрования нужно сохранить отдельно от самого NAS — в менеджере паролей на другом устройстве, а не в текстовом файле рядом с бэкапом, который он же и защищает.

Тестирование восстановления

Эта мысль уже звучала в статье про Vaultwarden, но для всей инфраструктуры целиком она даже важнее: бэкап, который ни разу не разворачивали обратно, — это просто файл, про надёжность которого вы ничего не знаете наверняка.

Раз в квартал — минимальная периодичность, чтобы это не превращалось в разовую акцию "сделали и забыли":

• Разверните дамп базы данных одного сервиса (например, Nextcloud) на тестовом контейнере — не в проде.
• Убедитесь, что реально можете залогиниться и увидеть свои данные, а не просто что команда восстановления отработала без ошибок.
• Засеките время полного восстановления — это то, что нужно знать заранее, а не считать в момент реального инцидента.

Мониторинг: бэкап, который никто не проверяет — не бэкап

Оркестрирующий скрипт из раздела выше уже отправляет письмо по завершении — но стоит отдельно настроить алерт именно на отсутствие письма, а не только на явную ошибку внутри него. Простейший вариант — задача в Task Scheduler DSM, которая проверяет время модификации последнего файла бэкапа и шлёт отдельное тревожное уведомление, если оно старше ожидаемого расписания на день и больше: тихо сломавшийся cron не пришлёт письмо об ошибке просто потому, что не запустился вообще.

Итоговая сводная таблица по всем сервисам

Частые проблемы

Три копии, два носителя, одна из них физически в другом месте — и отдельная привычка раз в квартал реально восстанавливать что-то из бэкапа, а не только создавать его. Из всего описанного на этом сайте именно эта статья ничего не запускает нового — только связывает то, что уже работает, в стратегию, которая переживёт куда больше, чем отказ одного диска.