nashosted.com

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

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

Когда в квартире появляется NAS, кажется, что данные наконец-то в безопасности. Диски в зеркале, том на ZFS, всё крутится в Proxmox на отдельной машине — что ещё нужно? Но потом ловишь себя на мысли: а что будет, если случайно удалить папку с проектами? Или если шифровальщик доберётся до сетевой шары? Или если блок питания NAS коротнёт и утянет за собой оба диска разом? В такие моменты становится понятно: NAS — это удобная точка хранения, но не резервная копия. Без продуманной стратегии бэкапов вы по-прежнему сидите на пороховой бочке, просто красиво оформленной.

Базовый ориентир, который я для себя вывел за годы экспериментов с домашними серверами, — правило 3-2-1. А для спокойного сна стоит сразу закладываться на расширенную версию 3-2-1-1-0: три копии, два типа носителей, одна копия вне дома, одна офлайн или неизменяемая, ноль ошибок при проверке восстановлением. Звучит как заклинание, но на практике это просто набор привычек и несколько строчек в cron.

Что именно нужно защищать в домашней системе

Первое, с чего я начинаю аудит любого своего сервера, — разделение данных по уровням. Если валить всё в одну кучу, вы либо раздуете объём бэкапов до невменяемых размеров, либо пропустите действительно важное. В домашней self-hosted среде обычно выделяются три категории.

Критичные данные

Это то, без чего жизнь встанет: семейные фото и видео, сканы договоров, базы паролей и ключи 2FA, конфиги NAS, роутера, Home Assistant, Docker Compose-файлы, переменные окружения, рабочие документы, если NAS используется как часть домашнего офиса. Потеря любого из этих элементов — это не просто «обидно», а часы или дни восстановления, а иногда и невосполнимые утраты. Например, без резервной копии конфига Zigbee2MQTT после сбоя вы заново будете сопрягать все датчики, а это десятки устройств по всей квартире.

Важные, но не жизненно важные

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

Что не обязательно бэкапить

Кэши приложений, корзины, временные файлы, транскодированные версии видео, которые Jellyfin создаёт на лету, — всё это либо восстанавливается автоматически, либо не представляет ценности. Если вы используете Docker, тома с данными, которые контейнер подтягивает из интернета при первом запуске (например, базы геоданных), тоже можно исключить из бэкапа, но лучше проверить, не хранится ли там пользовательская конфигурация.

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

Базовая стратегия: 3-2-1 для дома

Правило 3-2-1 остаётся самым практичным ориентиром: три копии данных, на двух разных типах носителей, одна копия — вне дома. В моей квартире это реализовано так: основная рабочая копия лежит на десктопе и ноутбуке, локальная резервная — на NAS в слаботочном щите, удалённая — на втором NAS у родственников, связанном через WireGuard, плюс критичные документы дополнительно льются в облачное S3-совместимое хранилище.

Почему одной копии на NAS недостаточно

NAS с RAID или зеркалом ZFS повышает отказоустойчивость к смерти одного диска, но не спасает от остальных рисков: случайное удаление или перезапись файла, шифровальщик, который по сети доберётся до шары, пожар, потоп, кража всего корпуса, выход из строя контроллера или блока питания, повреждение файловой системы после внезапного отключения электричества. Я как-то раз после скачка напряжения потерял сразу два диска в RAID1 — благо, была отдельная холодная копия на внешнем HDD. Именно поэтому NAS — это лишь элемент стратегии, а не финальная страховка.

Что означает 3-2-1-1-0 и зачем оно дома

Расширенная схема добавляет два критически важных элемента: одна копия должна быть офлайн или неизменяемой (immutable), а проверка резервных копий должна завершаться без ошибок. Для домашней инфраструктуры, где сервер работает 24/7 и умный дом постоянно пишет логи, это особенно актуально. Если ваш бэкап хранится на постоянно подключённом по USB диске, шифровальщик может зашифровать и его. А если вы ни разу не пробовали восстановиться, вы не знаете, работает ли бэкап вообще.

Практический смысл

  • 1 offline — диск, который лежит в ящике стола и подключается только на время копирования. У меня это 2,5-дюймовый HDD в антистатическом пакете, раз в месяц я делаю на него Borg-репозиторий и сразу отключаю.
  • 1 immutable — копия, которую нельзя изменить обычным доступом в течение заданного срока. В домашних условиях это можно реализовать через WORM-атрибуты на уровне файловой системы (ZFS snapshot с hold), через объектное хранилище с блокировкой версий (S3 Object Lock) или через append-only режим в Borg/Restic. Я использую Borg в режиме append-only на удалённом NAS, куда у меня нет прав на удаление старых архивов.
  • 0 errors — восстановление регулярно проверяется. Недостаточно просто видеть «успешно» в логах задания. Раз в месяц я восстанавливаю случайный файл и целую папку, раз в квартал — поднимаю тестовую виртуалку из бэкапа.

Для дома это не роскошь, а способ пережить не только железный отказ, но и сетевые инциденты, которые в эпоху умных розеток и IoT становятся всё более вероятными.

Какая схема подходит для квартиры в России

Ниже — рабочие варианты, которые я опробовал сам или помогал настроить знакомым. Без экзотики, только то, что реально работает с учётом типичных каналов связи и бюджетов.

Сценарий Подходит кому Плюсы Минусы
NAS + внешний USB-диск Для старта и небольшого бюджета Дёшево, просто, быстро восстанавливать Диск легко забыть подключить, слабая защита от кражи и пожара, риск заражения при постоянном подключении
NAS + второй NAS у родственников Для тех, кто хочет offsite без облака Хорошая скорость, полный контроль, конфиденциальность Нужен второй узел и стабильный канал связи, желательно с пробросом портов или VPN
NAS + облако для критичных данных Для фото, документов, конфигов Географическое разделение, удобно, не нужно своё железо Стоимость трафика и хранения, зависимость от интернета, потенциальные риски доступа третьих лиц
NAS + USB offline + облако Лучший домашний баланс Близко к 3-2-1-1-0, покрывает большинство рисков Нужна дисциплина и настройка нескольких инструментов

В своей квартире я остановился на комбинации: локальный NAS (самосбор на базе Proxmox с TrueNAS в виртуалке) для оперативных данных, внешний USB-HDD для офлайн-копии, удалённый NAS у родственников для основного offsite и S3-бакет для самых критичных документов и конфигов. Всё это завязано на rclone и Borg, расписание — в systemd-таймерах.

С чего начать: пошаговый план

Шаг 1. Составьте инвентаризацию данных

Список должен быть коротким и понятным: документы, фото и видео, проекты, конфиги, пароли и ключи, данные умного дома, медиатека. Для каждого типа данных укажите: где хранится оригинал, как часто меняется, сколько хранить версий, насколько быстро нужно восстановление. Я для этого использую простую таблицу в Markdown, которая лежит в корне бэкап-репозитория.

Шаг 2. Разделите данные по важности

Простая схема, которая у меня прижилась:

  • уровень A — критичные данные, бэкап ежедневно или чаще (документы, конфиги, базы паролей);
  • уровень B — важные данные, бэкап 1–2 раза в неделю (медиатека, проекты);
  • уровень C — данные «на всякий случай», бэкап по остаточному принципу (ISO, загрузки).

Такое разделение сразу подсказывает, какие задания должны быть в ежедневном cron, а какие можно запускать раз в неделю.

Шаг 3. Определите точку восстановления

Полезно задать себе два вопроса: сколько данных я готов потерять максимум (RPO) и сколько времени я готов потратить на восстановление (RTO). Если ответ: «не больше суток и не больше часа на восстановление», схема нужна одна. Если: «можно восстановить за вечер», — другая. Для критичных данных я держу RPO в пределах 24 часов, а RTO — до 30 минут на восстановление отдельного файла и до 2 часов на полный откат сервера.

Шаг 4. Выберите два независимых носителя

Хорошая пара для дома: NAS с RAID или зеркалом — для отказоустойчивости, и внешний HDD/SSD или облако — для резервной копии. Важно: RAID не заменяет бэкап. Он лишь помогает не остановиться при смерти одного диска, но не спасает от логических ошибок. Я предпочитаю связку «NAS на ZFS + внешний диск на XFS/ext4», потому что разные файловые системы снижают вероятность одновременного бага.

Шаг 5. Настройте автоматизацию

Резервное копирование работает только тогда, когда не зависит от памяти и настроения. У меня автоматизировано: ежедневный бэкап документов и конфигов через Borg на внешний диск, еженедельный бэкап фото и видео на удалённый NAS через rclone, ночное копирование дампов баз данных контейнеров (pg_dump, mysqldump) в отдельную директорию, ротация версий с помощью prune, отчёты об ошибках на почту через healthchecks.io. Всё это прописано в systemd-сервисах и таймерах, а не в GUI-планировщиках, чтобы не зависеть от веб-интерфейса.

Шаг 6. Проверьте восстановление

Бэкап без восстановления — это надежда, а не защита. Раз в месяц я восстанавливаю один случайный файл и одну папку, проверяю, открываются ли фото, архивы, документы. Раз в квартал делаю тест полного восстановления на запасной виртуальной машине: разворачиваю Borg-архив, поднимаю Docker Compose, проверяю, что Home Assistant стартует и видит устройства. Только так можно быть уверенным, что в час X всё сработает.

Какие данные стоит бэкапить в домашнем self-hosted

NAS и файлы

Семейные архивы, общие папки, рабочие документы, сканы и бухгалтерия, проекты. Я храню всё это в отдельных датасетах ZFS, что позволяет делать снапшоты и отправлять их на удалённую машину инкрементально.

Домашний сервер

Конфиги Docker Compose, переменные окружения (.env), базы данных контейнеров (обычно это дампы SQL), конфиги reverse proxy (Nginx Proxy Manager или Traefik), настройки сервисов. У меня все compose-файлы лежат в Git-репозитории, который автоматически пушится на удалённый сервер, а сами данные томов бэкапятся Borg-ом. Так я могу восстановить сервер с нуля за пару часов.

Умный дом

Резервная копия Home Assistant (встроенный механизм backup или ручной снапшот папки config), сценарии автоматизации, интеграции, ключи доступа, карты устройств и конфигурации Zigbee2MQTT. Без этого восстановление умного дома превращается в рутинную перенастройку десятков датчиков и выключателей. Я настроил автоматический еженощный бэкап HA через его API и сохраняю архив на NAS.

Сеть и инфраструктура

Конфиг роутера (MikroTik, Ubiquiti, OpenWrt — у каждого свой формат экспорта), настройки Wi-Fi, VLAN, списки резервных DNS, схемы кабельной разводки, пароли к админским интерфейсам. После переезда и настройки слаботочного щита я сделал экспорт конфигурации коммутатора и роутера и храню их вместе с остальными критичными данными. Это спасло меня, когда после экспериментов с VLAN пришлось откатываться.

Частые ошибки при бэкапах дома

  • Хранить копию только на том же NAS — даже если это другой том, риск пожара или кражи общий.
  • Использовать один внешний диск как «архив навсегда» и не проверять его состояние по SMART.
  • Не проверять восстановление — самый опасный промах. Бэкап может быть битым, а вы узнаете об этом слишком поздно.
  • Бэкапить всё подряд без приоритизации — забиваете место и увеличиваете окно бэкапа.
  • Хранить единственную офлайн-копию в той же комнате — при локальном пожаре или потопе теряется всё.
  • Забывать про конфиги, считая, что важны только файлы. Без конфига Home Assistant вы потратите дни на восстановление автоматизаций.
  • Не фиксировать, где лежит копия и как к ней получить доступ. Если вы один знаете пароль от облака, а с вами что-то случится, семья останется без данных.
  • Игнорировать шифрование бэкапов — внешний диск может быть украден, и данные утекут.

Хорошая домашняя стратегия: минимум, который реально работает

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

  • Рабочие документы и фото лежат на ПК и синхронизируются на NAS (например, через Syncthing или Resilio Sync).
  • На NAS ежедневно делается локальная резервная копия версий с помощью Borg или restic в отдельный репозиторий на том же устройстве, но на другом диске или пуле.
  • Раз в неделю критичные данные копируются на внешний диск (можно через rsync или rclone).
  • Раз в месяц внешний диск уходит в офлайн (отключается и хранится отдельно).
  • Самые важные файлы дублируются в облако или на удалённый узел (у родственников с VPN).
  • Раз в месяц выполняется тест восстановления случайного файла и папки.

Такой план уже близок к 3-2-1-1-0 и подходит для обычной квартиры. У меня он реализован с небольшими вариациями: вместо еженедельного копирования на внешний диск я делаю это раз в месяц, но чаще обновляю удалённую копию.

Чек-лист домашнего бэкапа

  • Есть список критичных данных с указанием частоты копирования.
  • Для каждого типа данных определена глубина хранения версий.
  • Основные данные лежат не в одном месте (ПК + NAS + внешний носитель/облако).
  • Есть как минимум одна локальная копия на отличном от основного носителе.
  • Есть одна копия вне дома (географически удалённая).
  • Одна из копий отключается от сети или хранится неизменяемо (immutable).
  • Проверка восстановления проводится регулярно (минимум раз в месяц).
  • Конфиги NAS, роутера, Home Assistant и Docker входят в бэкап.
  • Пароли и ключи шифрования хранятся отдельно и защищены (менеджер паролей, бумажный бэкап).
  • Есть документированный порядок восстановления после сбоя, понятный не только вам.

Как хранить бэкапы, чтобы они не стали новой проблемой

Резервная копия сама по себе требует дисциплины. Я подписываю все внешние диски маркером с датой последнего обновления, веду простую таблицу в Nextcloud, где указано, какой носитель за что отвечает. Не смешиваю архив и рабочую копию — для архива использую отдельный диск, который не участвует в повседневной работе. Раз в несколько месяцев обновляю офлайн-носитель, проверяю состояние дисков по SMART (раз в неделю автоматический скрипт шлёт отчёт на почту). Держу инструкцию восстановления в текстовом виде в зашифрованном контейнере Veracrypt на флешке, которая лежит вместе с документами. Если бэкап есть, но никто в семье не понимает, как его использовать, это слабое место всей системы.

Вывод

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

FAQ

Нужно ли бэкапить NAS, если у него RAID?

Да, обязательно. RAID защищает только от отказа одного диска, но не от удаления файлов, шифровальщика, пожара и ошибок пользователя. У меня был случай, когда в RAID1 из-за контроллера повредилась файловая система, и без внешней копии данные было бы не спасти.

Что лучше для дома: внешний диск или облако?

Для быстрого и дешёвого старта удобнее внешний диск. Он не зависит от скорости интернета и позволяет быстро восстановить большой объём. Но для защиты от квартиры как точки отказа лучше добавить облако или удалённый NAS. Я использую оба: внешний диск для локальной офлайн-копии и облачное S3-хранилище для самых критичных данных.

Как часто делать бэкап фотографий и документов?

Документы — ежедневно или при каждом изменении. Фото и видео — по мере загрузки, а важные папки лучше держать в автоматической синхронизации. У меня на телефоне настроена синхронизация фото в Nextcloud сразу после съёмки, а оттуда они уже попадают в общую систему бэкапов.

Нужно ли бэкапить конфиги Home Assistant и Docker?

Да, обязательно. Без них восстановление умного дома и домашнего сервера может занять часы или дни. Я храню конфиги в Git и делаю ежедневные дампы томов Docker, чтобы можно было откатиться к любому состоянию.

Как понять, что бэкап рабочий?

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