Привет, Хабр. Месяц назад я рассказывал, как в одиночку построил AI-платформу на железе под столом. Та статья вышла с опозданием на день, «потому что вчера я чинил NFS». Через три недели NFS-сервер — старенький QNAP TS-220 — умер окончательно. А вечером того же дня мне переслали список б/у железа «под NAS, не надо?».
Эта статья — о том, что выросло из этого совпадения: домашнее ZFS-хранилище из б/у комплектующих, три слоя бэкапов и, главное, проверка восстановления, которая теперь запускается сама. В комментариях к прошлой статье мне резонно заметили, что своё железо — это ещё и время на «поддержку хозяйства». Эта статья во многом о том, куда оно уходит. Грабель было больше, чем хотелось бы, и почти все — в самих бэкапах.
Как умирал QNAP
QNAP делал у меня две вещи: хранил ночные бэкапы платформы и данные Gitea по NFS. Второе было ошибкой, но поначалу удобной.
За месяц случилось три эпизода.
29 августа. Перестал работать
git push. Порт открыт, контейнер Gitea в статусе Up, веб отвечает 200, а в логе ssh-шелла —stale file handle. Завис NFS-демон QNAP при аптайме 280 дней; помог только перезапуск самого NAS.22 сентября, вечер. Второй раз за месяц: первый, в августе, был в прошлой статье. Аварийная перезагрузка основного сервера (kernel oops, SysRq — отдельная история). NFS-маунт не успел подняться за 90 секунд, Gitea стартовал на пустом локальном каталоге и радостно предложил «первичную установку». Пока я разбирался, повторный
mvна висящем маунте унёс настоящие данные — 1,1 ГБ, шесть репозиториев — в/var/tmp. Вернули без потерь, но холодок я помню.Через полтора часа. QNAP завис целиком: ни веба, ни ssh. Выключил кнопкой.
Вывод сделали в тот же вечер: данные Gitea переехали на NVMe сервера, а NAS остался только целью ночного бэкапа. Правило с тех пор простое: рабочие данные не живут на сетевом хранилище, сетевое хранилище хранит копии.
А потом пришёл тот самый список.
Железо
Купил у коллеги друга:
материнская плата ASRock H570M-ITX/ac и Intel Core i3-10100;
корпус Thermaltake Core V1, блок питания 400 Вт;
2× Intel DC S3610 480 ГБ — серверные SSD с защитой от потери питания (PLP);
Samsung 870 EVO 1 ТБ, Toshiba DT01ACA200 2 ТБ, WD Black 2 ТБ;
плата M.2 → 6 SATA на ASM1166, кабели, салазки;
Toshiba X300 10 ТБ.
Вышло 50 тысяч рублей плюс 10-терабайтник. Через неделю сверху ушло ещё 26 тысяч: б/у i7-11700 вместо i3, 64 ГБ памяти (2×32 — частично обменом на старые Ryzen 5 5600X и Fury Beast RGB 2×8, доставшиеся мне вместе с GPU-нодой), низкопрофильный кулер на процессор, 200-миллиметровый вентилятор на фронт и внешняя корзина для дисков — напечатанная на 3D-принтере в корпус не влезла. Процессор менял из-за двух ограничений 10-го поколения на этой плате. Новая память DDR4-3200 работает на своей частоте только с 11-м поколением: i3-10100 официально держит лишь 2666. И верхний слот M.2 от процессора на H570 тоже оживает только с ним. После апгрейда — Memtest86+ без ошибок. Кулер низкопрофильный не от хорошей жизни: в Core V1 выше 140 мм не встаёт ничего, поэтому длительная мощность процессора ограничена 65 Вт. А вот кратковременный лимит, как выяснилось при сверке этой статьи с железом, так и остался заводским — 224 Вт вместо задуманных 95. Сверяйте планы с машиной. Пока статья ждала публикации, я выставил 95 Вт и проверил под нагрузкой: все 16 потоков, 75 секунд. Первые секунд двадцать процессор берёт 95 Вт, держит 3,6–4,4 ГГц и греется до 59 °C, потом опускается на длительные 65 Вт и 2,8–2,9 ГГц и стоит на 50 °C. Маленький кулер справляется с большим запасом — заводские 224 Вт ему были не нужны.
Ещё два диска по 3 ТБ позже переехали из самого QNAP. Перед вводом в строй все восемь дисков прошли расширенный SMART-тест. Самый старый — Seagate с 58 тысячами часов наработки; он в зеркале и под отдельным наблюдением.
Собранная нода встала в ту же стойку-обувницу, что и остальное железо из прошлой статьи. Преемственность.
Раскладка: зеркала, SLOG и диск без избыточности
Пул | Диски | Что живёт |
|---|---|---|
| два зеркала: 2+2 ТБ и 3+3 ТБ, zstd, ≈ 4,5 ТБ | бэкапы, фото семьи, история мониторинга, общие файлы |
| зеркало из двух S3610 | базы и конфиги контейнеров |
| Toshiba X300 10 ТБ, одиночный | фильмы и музыка |
| NVMe 480 ГБ, одиночный | недокачанные торренты, транскодинг, CI |
система | Samsung 870 EVO, ext4 | ОС и docker |
NAME SIZE ALLOC FREE CAP HEALTH fast 428G 1.72G 426G 0% ONLINE media 9.09T 1.11T 7.98T 12% ONLINE scratch 444G 1.32G 443G 0% ONLINE tank 4.53T 260G 4.28T 5% ONLINE
Почему зеркала, а не RAIDZ. Диски разного размера: RAIDZ из 2+2+3+3 обрезал бы всё под 2 ТБ. Зеркала растут парами, ресильвер у них быстрый, а вторую пару я как раз добавил позже, когда освободились диски QNAP.
SLOG. На тех же S3610 — зеркальный SLOG на 16 ГБ. Сразу оговорюсь, чтобы не поправляли в комментариях: SLOG ускоряет только синхронную запись. У меня это как раз она — бэкапы приходят с сервера по NFS, а NFS по умолчанию пишет синхронно. И именно поэтому SSD с защитой от потери питания: обычный потребительский SSD может подтвердить сброс кэша, которого на самом деле не было.
Диск без избыточности. media — одиночный диск, и это осознанно. Фильмы можно скачать заново, фотографии — нельзя. Поэтому семейные фото лежат на зеркальном tank, а не на большом диске, где места больше.
Отдельный пул для мусора. Всё, что часто пишется и не жалко, — на scratch, без снапшотов. Иначе автоснапшоты на основном пуле раздувались бы от каждого недокачанного торрента.
Сверху: ARC 24 ГиБ, автоснапшоты, scrub во второе воскресенье месяца. Наружу NAS не смотрит вообще — только локальная сеть и ufw с запретом по умолчанию. Это урок другой истории: в сентябре через уязвимость в публично доступной веб-аналитике в контейнер на основном сервере заехал майнер. Держать её открытой наружу было моим решением — и моей ошибкой.
Переезд: этапы с гейтами
Основное развернули за три дня, 25–27 сентября, по скриптам-этапам. Каждый этап заканчивается проверкой, без которой следующий не начинается: смонтировалось ли, совпадают ли размеры дампов, проходит ли restic check. QNAP оставался включённым как страховка до утренней сверки первых ночных бэкапов на новом месте, и только потом его диски переехали в tank вторым зеркалом.
Делал это не один. Скрипты писали и вели ИИ-агенты, на мне была физическая часть и всё, что требует sudo. Об этом формате работы — следующая статья. Здесь важно другое: даже при такой дисциплине ошибки случились. Обе — в бэкапах. Но сначала — как они устроены.
Как устроены бэкапы
Каждую ночь:
Время | Что | Куда |
|---|---|---|
03:30 | зеркало данных Gitea | NAS, отдельный датасет |
04:00 | дампы основной базы и базы хелпдеска, архив всех docker-томов | NAS, хранение 30 дней |
04:30 | restic: полный дамп PostgreSQL, файлы пользователей из MinIO, данные, секреты и релизы платформы | зашифрованный репозиторий на GPU-ноде по SFTP |
следом |
| третий репозиторий на NAS |
Поверх всего — ZFS-снапшоты, а в 09:00 сторож проверяет свежесть и размер каждого слоя и пишет в Telegram.
Проверка размера появилась после июльской истории. Однажды ночной дамп основной базы весил 20 байт: pg_dump упал, а gzip в конце пайпа честно вернул 0, и скрипт отчитался об успехе. С тех пор в скриптах set -o pipefail, проверка размера дампа и внешний сторож, который не верит скрипту на слово.
Грабли №1: чистка, которая съела репозиторий
При переезде третий restic-репозиторий положили внутрь /tank/backups. В тот самый каталог, где ночной скрипт чистит всё старше 30 дней через find -mtime +30 -delete. Копия сохранила старые даты файлов.
В 04:09 первой же ночи чистка удалила из репозитория config, ключи и 111 пак-файлов. В 04:30 restic copy упал с «repository does not exist». Утренний сторож заметил несвежий слой, к обеду репозиторий восстановили с ещё живого QNAP — уже в отдельный датасет со своим экспортом.
Два урока:
У каждого потребителя хранилища — свой датасет. Чистка по возрасту и репозиторий с дедупликацией не должны видеть друг друга: для restic старый пак-файл — не мусор, а данные.
Старое хранилище не выключают, пока новое не пережило ночь. Именно включённый QNAP превратил эту историю из потери в неприятность.
Грабли №2: бэкап, который молча не запускался
Вторая история тише и поэтому страшнее. В systemd-юните бэкапа Gitea осталась зависимость RequiresMountsFor от старого маунта QNAP, хотя сам скрипт давно писал на новый NAS. Пока старый маунт был жив, всё работало. В начале октября задание стало завершаться с ошибкой «NAS не смонтирован».
Четыре ночи подряд — и ни одного алерта. Сторож следил за основными слоями, а за возрастом маркера успешного бэкапа Gitea не следил никто. Нашли случайно: агент проверял NAS по другому поводу и увидел, что маркеру последнего успешного бэкапа 90 часов.
Починка — одна строка в юните. Урок важнее: алерт должен смотреть на возраст последнего успеха, а не на ошибку задания. Задание, которое не запустилось, не падает — оно просто не случается. Теперь на каждый слой есть правило «последний успех старше 26 часов».
Бэкап без восстановления — это надежда
month: 2026-10 status: PASS phase: COMPLETE databases_connected: 12 user_tables_and_partitions: 268 extensions: 13 invalid_indexes: 0 repositories: 6 container_cleanup_verified: true work_cleaned: true
Самая важная часть. Три копии — это хорошо, но ни одна из них ничего не стоит, пока из неё ни разу не восстановились. Поэтому восстановление теперь проверяется по расписанию.
Раз в неделю — restic check --read-data: полное чтение всех данных репозитория, не выборка. На текущем объёме это около минуты.
Раз в месяц, первого числа — автоматическая учебная тревога:
Из restic-снапшота не старше 36 часов достаётся свежий
pg_dumpallсrestore --verifyи проверкой контрольной суммы gzip.Дамп заливается в одноразовый PostgreSQL 17.10. У контейнера нет сети, нет опубликованных портов и нет доступа к файлам хоста; данные живут в tmpfs, память ограничена.
Проверяется результат: число баз, схем, таблиц, расширений, сломанных индексов. Первый реальный прогон: 12 баз, 268 таблиц и секций, 13 расширений, 0 невалидных индексов.
Статус пишется в два поля: последняя попытка и последний успех. Неудачная попытка не затирает прошлый успех и не повторяется сама — её разбирает человек.
На это смотрят три алерта: попытка упала или результат неизвестен, проверка идёт дольше 90 минут, успешной проверки не было больше 35 дней.
Gitea восстанавливается отдельно. Официальный образ, закреплённый по digest, база из restic, репозитории с зеркала на NAS. Всё — в изолированном окружении без сети и с файловой системой только для чтения. Проверка: веб отвечает 200, все шесть репозиториев читаются вместе с ветками и коммитами. После починки юнита такая проверка прошла за 80 секунд прямо наутро после ночного бэкапа.
Честно о границах. Что эти проверки не доказывают:
целостность LFS-объектов и SSH-ключи хоста Gitea — их в проверку сознательно не берём;
полную согласованность: база и зеркало репозиториев снимаются с разницей в час;
архив docker-томов: его проверяет только сторож по размеру, восстановление из него ни разу не репетировалось.
Грабли №3: вспомнил, пока писал эту статью
Готовя этот текст, я задал себе простой вопрос: базы проверены, Gitea проверен, а где файлы пользователей? Загрузки, вложения из чатов, сгенерированные файлы — всё это живёт в объектном хранилище MinIO.
Ответ оказался неприятным. MinIO попадал только в ночной архив всех docker-томов: копия живого тома на лету, один слой из трёх, хранение 30 дней. В restic его не было, восстановление из архива не репетировал никто. Получалось, что лучше всего защищено то, что можно пересоздать, а хуже всего — то, что пользователи доверили мне.
Починили в тот же день:
Каждую ночь перед restic том MinIO копируется в каталог подготовки вспомогательным контейнером — только чтение, без сети. Рядом пишется манифест с sha256 каждого файла. Дальше копия сама уезжает в restic, а значит во все три места.
Раз в месяц — своя учебная тревога. Восстановить из restic с
--verify, сверить манифест побайтно, поднять одноразовый MinIO тем же образом, что в проде: без сети, от обычного пользователя, со случайными ключами. Продовые секреты для этого не нужны. Затем вычитать каждый объект бакета и сверить их число.Сторож теперь кричит, если ночная копия старше 26 часов или успешной тревоги не было больше 35 дней.
Первый прогон: 265 объектов из 265, около 300 МБ, восемь секунд. И отдельно проверил обратное: испортил один байт в восстановленном файле — проверка упала, как и должна. Проверка, которая ни разу не падала, тоже ничего не доказывает.
Раз уж полез в архив томов, посмотрел и на то, что в нём лежит. Из 73 томов 53 оказались анонимными, без единого контейнера: каталоги одноразовых PostgreSQL от августовских репетиций миграций. Скорее всего, с копиями продовой базы — и они каждую ночь честно архивировались. Рядом лежали node_modules dev-проектов, тома раннеров CI и история метрик Prometheus, которая восстанавливаться из архива работающей базы всё равно не обязана. Анонимные тома удалил совсем, остальное убрал из архива. Список томов теперь строится каждую ночь по запрещающим правилам, так что новый осмысленный том попадёт в бэкап сам. Содержимое архива сжалось с 12,4 до 3,2 ГБ — и среди этих гигабайт больше нет лишних копий ненужных данных.
Не только NAS: третья нода
Ещё на этапе покупки я решил, что это не «коробка с дисками», а третья нода платформы с ролью хранилища. Правил у такой ноды три: наружу она не смотрит; у каждого сервиса свой лимит памяти; на ней не живёт ничего, без чего ляжет прод. Хранилище может упасть — платформа этого не заметит, просто ночью не будет свежей копии, и об этом скажет алерт.
Что на ней живёт, кроме дисков:
Полигон для восстановлений. Учебные тревоги из раздела выше — база и Gitea — разворачиваются именно здесь, в изолированных контейнерах. Проверять бэкап на том же сервере, который бэкапишь, — так себе идея: продовый сервер в момент проверки занят продом, а при настоящей аварии его может просто не быть.
CI. Раннер Gitea Actions: сборки и тесты идут в контейнерах с потолком 8 ГБ памяти и 6 ядер, кэши — на быстром
scratch. Задачи только в контейнерах, без режима «прямо на хосте»: всё-таки рядом лежат бэкапы. Раньше сборки делили продовый сервер и GPU-нода, и задачи раннера на продовом сервере вдобавок запускались в его внутренней сети. Теперь он снят.Мониторинг, который не зависит от основного сервера — о нём ниже.
Под эти роли и понадобился i7: 16 потоков на сборки и восстановления, а встроенная графика 11-го поколения заодно умеет аппаратно декодировать AV1.
Дальше в очереди — перенести сюда основной мониторинг платформы и сбор логов со всех нод. Идея та же: всё, что должно кричать, когда лежит основной сервер, не должно жить на основном сервере.
Мониторинг, который переживёт основной сервер
У NAS свой Prometheus: история за год на tank, 27 правил — здоровье пулов, заполнение больше 85%, SMART, scrub, свежесть каждого слоя бэкапа, статус учебных восстановлений, а теперь и обороты вентиляторов, температура процессора и дисков. Алерты идут в Telegram через отдельного бота, не через продовый. Логи самого NAS собирает Loki там же; подключить к нему остальные ноды — в очереди.
Питание: NAS вместе с GPU-нодой сидит на втором ИБП. Он подключён по USB к самой GPU-ноде, она раздаёт его состояние по NUT, и NAS погасится штатно, если батарея начнёт кончаться. Почему ИБП подключён именно туда — в граблях №6. Следующий шаг — перенести на NAS основной мониторинг, чтобы алерты продолжали приходить, когда лежит сам сервер платформы.
Бонус: что NAS делает для семьи
Раз уж в доме появилось 10 ТБ и процессор с Quick Sync — на NAS живёт Jellyfin с аппаратным транскодированием. Проверяли на настоящем фильме: 4K HDR10 в HEVC на лету превращается в 1440p с аппаратным тонмаппингом, в Safari на Mac при 8 Мбит/с — плавно и с нормальными цветами.
А на зеркальном tank теперь живёт Immich для семейных фотографий. Только локальная сеть, распознавание лиц на процессоре. Это, пожалуй, самые ценные данные во всём доме — и именно поэтому они лежат на зеркале, а не на большом диске.
Грабли №4: браузер решил за меня
Пока я дописывал эту статью, перестали открываться Jellyfin, торрент-клиент и фотографии. При этом на NAS всё было живо: контейнеры здоровы, с соседнего сервера страницы отдавались. Ответ нашёлся в логе фаервола — 120 отброшенных попыток зайти на порт 443 с моего устройства за три часа. Браузер всё настойчивее переводил адреса на HTTPS, а NAS по HTTPS не отвечал вовсе: обратный прокси слушал только 80-й порт, а фаервол молча выбрасывал остальное. Браузер ждал ответа и сдавался, вместо того чтобы вернуться на http.
Certbot для имён вида jellyfin.c.lan не поможет: Let's Encrypt выдаёт сертификаты только на настоящие домены. Поэтому домашние сервисы переехали на поддомен моего домена, и на него выпущен wildcard-сертификат с проверкой через DNS. Наружу для этого не открывается ничего: Let's Encrypt проверяет TXT-запись у регистратора, а не стучится в NAS. Сами имена знает только домашний роутер, снаружи они не резолвятся. Сертификат выпускает основной сервер, где certbot уже стоял, и при каждом продлении сам отвозит его на NAS. Теперь в адресной строке замок, и ни на одно устройство не пришлось ставить свой корневой сертификат.
Без граблей не обошлось и тут. Первая попытка упала: Let's Encrypt не увидел TXT-запись, хотя в панели регистратора она уже была. DNS-серверы регистратора публикуют изменения дольше тех двух минут, что я ждал, а ответ «такой записи нет» резолверы могут помнить до трёх часов. С ожиданием в 15 минут всё прошло. Заодно выяснилось, что у другого wildcard-сертификата, на тестовый стенд, в настройках стояла одна минута. Работало ли это раньше честно или на везении — уже не выяснить, но проверять в декабре не хочется: поднял до 15 минут заранее.
Грабли №5: сторож, который молчал
NAS шумел, и я переделал кривые вентиляторов. Два задних вентилятора без PWM и вентилятор дисковой корзины висят на одном разъёме через разветвитель, а его обороты плата считает по температуре процессора. Получается неприятная вещь: ночью идут бэкапы, диски работают, процессор холодный — и корзина крутится на минимуме. Поэтому я добавил ранний алерт: жёсткий диск теплее 45 °C дольше получаса. Сейчас в простое они держат 24–36 °C, максимум за неделю — 40.
Полез проверить, как алерты доходят, — и выяснил, что они не доходят вообще. Больше двух суток в Telegram не пришло ни одного. Пересыльщик алертов из Prometheus в Telegram написан строгим: он знает правила поимённо и при незнакомом имени отказывается читать вообще всё, чтобы не переслать ничего лишнего. За два дня до этого три правила про вентиляторы и температуру процессора добавил ИИ-агент по моей задаче, а список в пересыльщике не обновил. Доставку после этого не проверили ни он, ни я. С тех пор каждый опрос заканчивался отказом. Docker всё это время честно показывал у контейнера unhealthy — только туда никто не смотрит.
В тот же вечер нашлось второе молчание: после перезагрузки с настройкой BIOS не поднялся сам Prometheus на NAS. Политика перезапуска стояла «если не остановлен вручную», но docker его так и не запустил. Почему — до конца не выяснил. Поставил «всегда» и проверяю мониторинг после каждой перезагрузки.
Урок: «правило загрузилось» ничего не говорит о доставке. Алерт, который не доходит, хуже отсутствующего: он создаёт ощущение, что за тобой присматривают. Теперь после каждой правки правил пересыльщик прогоняется вхолостую.
Грабли №6: дешёвый USB, который уронил сеть
Раз уж проверял сторожей, заглянул и в NUT. Оба ИБП — и тот, что держит основной сервер, и тот, что держит NAS с GPU-нодой, — были подключены по USB к основному серверу, китайскому мини-ПК. И оба уже неделю отдавали Data stale: данных нет. При отключении света ни одна нода не выключилась бы штатно. Алерта на «ИБП пропал» не было, поэтому никто и не знал.
Журнал ядра показал, что USB на мини-ПК болел давно. С конца сентября один из портов сыпал ошибками сотнями в день: устройство отключалось и подключалось по кругу. Вечером 4 октября ядро отключило соседний порт с пометкой «возможна электромагнитная помеха», и USB-контроллер перестал принимать устройства вообще. Кабели при этом сидели плотно. Когда я переткнул их в поисках плохого контакта, контроллер умер окончательно — и забрал с собой второе устройство на нём: USB-адаптер 2,5G, через который GPU-нода ходит к основному серверу за сетевым хранилищем. GPU-нода повисла на NFS.
Перезагружать продовый сервер не пришлось. Контроллер оживает, если отвязать его от драйвера и привязать заново: две команды в sysfs. Оба ИБП и сетевой адаптер вернулись. Но на том же порту всё тут же началось снова — 57 переподключений за минуту. Этот ИБП я перенёс на GPU-ноду: он и так её питает. Там он стоит ровно с первой минуты. Значит, дело скорее не в ИБП, а в самом мини-ПК — в USB-порте или его питании на плате.
Урок: на дешёвом железе не стоит вешать на один USB-контроллер и ИБП, и сетевой адаптер. А «NUT настроен» не значит «NUT работает».
Чего это всё НЕ решило
Все три копии — в одной квартире. Пожар, кража или потоп заберут всё сразу. Облачный офсайт — осознанно отложенное решение, и это главный долг всей схемы.
mediaбез избыточности. Сознательно, но если X300 умрёт, библиотеку придётся собирать заново.Сеть. Свитч приехал за день до публикации: сеть хранения на 2,5 Гбит с 10-гигабитным аплинком уже работает, и бэкапы ходят по ней втрое быстрее. Без граблей не обошлось и тут — NFS показывал новый адрес, а данные гнал по старому. Это история для следующей статьи.
Сторожа никто не сторожит. Если замолчит пересыльщик алертов, сам Prometheus или NUT, я узнаю об этом случайно, как в граблях №5 и №6. Внешняя проверка «я жив» и алерт на пропавший ИБП — в очереди.
Семейный бюджет. За моим хобби внимательно наблюдает любимая — и смотрит, как из кошелька улетают деньги. Эту утечку видно без всякого мониторинга, и от неё не спасают ни зеркала, ни снапшоты.
Вместо вывода
Месяц назад я опоздал со статьёй на день из-за NFS. За этот месяц QNAP умер, а я понял, что «три копии» и «проверенное восстановление» — это разные уровни спокойствия. restic check говорит, что архив цел. Только восстановление говорит, что в архиве то, что нужно.
Три вопроса к комментариям:
Офсайт. Чем вы шифруете и куда отправляете внешнюю копию, если живёте в России и не хотите зависеть от одного облака?
Зеркала против RAIDZ на разнокалиберных дисках — сделали бы иначе?
Учебные тревоги. Как часто вы восстанавливаетесь из бэкапа «понарошку» и что именно проверяете?
Продукт по-прежнему называется VoiceMind, ссылки в профиле.
