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

Сейчас мой сервер выполняет следующие задачи:

• Резервное копирование всех моих ВМ по расписанию

• Хостинг собственных пет-проектов

• Тестовые рабочие стенды

• Мониторинг всех моих рабочих серверов и их параметров через Grafana / Prometheus

• Хостинг OpenStreetMaps карты мира

• Личная автоматизация через OpenClaw с управлением из Matrix-чата

• Matrix-чат для близких

• Домашний кинотеатр Jellyfin

• Личное облако для данных

• Эксперименты и тестирование новых сервисов или версий ПО

Железо

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

• Материнка — ASUS WS C246 PRO

• Процессор — Intel Xeon E-2276G 3.8 GHz

• Оперативка — Samsung 64gb DDR4 ECC 2666

• Видеокарта — Nvidia RTX 2060

• Жесткие диски — суммарно 8ТБ HDD, 1ТБ NVMe, 1ТБ SSD

Видеокарта мне оказалась особенно и не нужна, потому что мощные LLM она все равно не потянет, а мои текущие задачи закрывает процессор с графическим ядром. Единственное, она оказалась полезна в транскодинге фильмов.

Для бэкапов самого сервера я купил себе дополнительный NAS Synology DS220+ с двумя жесткими дисками, соединенными в RAID. Таким образом даже если что-то случится с основным сервером, всегда будет откуда восстановить данные.

Система

Сначала я поставил Proxmox и организовал домашнюю виртуализацию, но спустя несколько месяцев понял что мне этот путь не подходит, потому что много времени уходит на сопутствующие задачи, а не на те которые я изначально хотел решать. Каждый раз когда приходилось что-то сделать, нужно было совершать дополнительные телодвижения. А когда речь шла о каких-нибудь докер-контейнерах внутри виртуалки или LXC-контейнера (да, так тоже бывает), особенно с пробросом GPU, я вспоминал фильм Начало и быстро терял энтузиазм.

В конце концов я остановился на стандартном Ubuntu Server 24.04 LTS, который устраивает меня и по сей день.

Довольно долго я пытался придумать оптимальную и удобную мне структуру хранения данных внутри системы.

• 2х NVMe по 500ГБ: на одной система, другой выведен в папку /datahot, где у меня живет БД PostgreSQL, ClickHouse и прочие данные к которым нужен быстрый доступ.

• 1х SSD на 2ТБ: выведен в папку /datawarm, где крутится отдельный PostgreSQL-инстанс для OpenStreetMaps.

• 2х HDD по 4ТБ: диски соединены в RAID1 и выведены в /datacold, там хранятся бэкапы и те данные, потерять которые хочется меньше всего.

• Synology NAS: выведен в папку /dataice, куда я крон-скриптами бэкапирую чувствительные данные с сервера.

Таким образом все данные организованы по «температуре» и скорости самих дисков, примерно также как это делают облачные хостинги. SSD-дискам я не доверяю, поскольку неоднократно был свидетелем их внезапной и безвозвратной поломки, так что система получилась хоть и более сложной, но надежной.

Софт

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

Базы данных

Я не сторонник контейнеризации баз данных, поэтому на сервере установлено bare-metal несколько инстансов PostgreSQL и ClickHouse, где я под мои нужды создаю юзеров и БД и под нужды того или иного сервиса. В итоге все удобно хранится и управляется из одного места.

Самым прожорливым оказался ClickHouse, который очень любит оперативку. Если вы работаете с реально большими данными, я бы рекомендовал собирать сервер с бОльшим объемом RAM.

Веб-сервер и проксирование

Здесь стандартно установлен Nginx.

Поскольку сам я работаю из разных мест, где иногда не получается подключиться к домашнему VPN и зайти на тот или иной сервис внутри локальной сети, приходится выводить некоторые сервисы «в интернет» через обратный прокси.

Резервное копирование всех моих ВМ

Поскольку мой основной профиль и стэк это PHP / Laravel / PostgreSQL, и много пет-проектов и рабочих сервисов написаны именно на этом стэке, я старался найти то решение, которое мне ближе и понятнее. В моем «подчинении» десятки различных ВМ, и мне было важно централизованно на сервере сохранять как файловую систему, так и их БД.

• https://github.com/spatie/laravel-backup-server — еженедельные бэкапы файловой системы, в основном ценность несет именно сохранение .gitignore папок, которые не попадают в репозиторий (картинки, видео и т.д).

• https://github.com/spatie/laravel-backup — ежедневные бэкапы баз данных, в основном PostgreSQL.

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

Хостинг собственных пет-проектов

Если возникает какая-нибудь идея, я иду по отлаженной схеме, по небходимости используя Cursor / Claude Code.

• mkdir /var/www

• laravel new example-app / git clone

• npm install & npm run build & composer install

• nano /etc/nginx/sites-available/example & ln -s /etc/nginx/sites-available/example /etc/nginx/sites-enabled/ & certbot —nginx -d example.com

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

Тестовые рабочие стенды

История примерно такая же как и с разворачиванием собственных пет-проектов, но с импортом обезличенных данных из рабочих БД.

Мониторинг всех моих рабочих серверов и их параметров через Grafana / Prometheus

Стэк Prometheus / Grafana / Node Exporter закрывает все потребности. Prometheus и Grafana ставятся один раз на сервер, а Node Exporter экспортирует метрики с каждой ВМ, к которой нужно прикрутить мониторинг.

В самой Grafana настраиваются необходимые алерты в Matrix / Telegram, где по достижении какого-нибудь порогового значения уходит уведомление. Часто заканчивается место на диске или происходит аномалия по нагрузке.

Хостинг OpenStreetMaps карты мира

Под OSM базу необходимо закладывать больше 1ТБ места, поэтому я специально для таких целей купил отдельный SSD. Сам импорт в PostgreSQL происходит довольно просто, а дальше уже как фантазии хватит.

Иногда довольно интересно прокачать свои знания в сложных SQL-запросах и посмотреть любопытную статистику по количеству или распределению школ или общественных туалетов в мире :)

Личная автоматизация через OpenClaw с управлением из Matrix-чата

OpenClaw в целях безопасности необходимо устанавливать в docker-контейнер или на отдельный VPS, и сам сервис требует некоторой настройки и кастомизации под себя. В моем случае он решает несколько задач.

Ежедневная проверка балансов. У меня в памяти не всегда укладывается список сервисов или услуг, за которые я должен вовремя заплатить. Иногда я забываю оплатить хостинг, сервис отправки смс и так далее. В OpenClaw написан небольшой крон, который ежедневно обходит нужные мне сервисы, и присылает мне уведомления по балансам и аномалиям. Иногда это решается простым API-запросом, а иногда приходится просить его через Chrome / Playwright заходить в браузер и выполнять нужные мне действия.

Проверка погоды. Ежедневно бот присылает сводку по погоде на сегодня, рассказывая про условия для бега и велосипеда.

Еженедельный персональный дайджест по здоровью. Здесь индивидуально можно настроить под себя, например бот может проверять расписание фитнес-центра или массажного салона, или напоминать про занятия спортом, составлять график и так далее.

OpenClaw удобен тем, что можно использовать любой канал коммуникации, в том числе Matrix. В качестве ИИ-модели я рекомендую Minimax 2.7, она наиболее продвинутая для таких целей и оптимальна по цене.

Matrix-чат для близких

Последние недели я занялся поискком альтернативы заблокированным мессенджерам, и после вот этой статьи я решил рассмотреть стэк Matrix / Element / Synapse. В нем мы ведем семейные и дружеские переписки, периодически я переношу и дорабатываю различную ИИ-автоматизацию.

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

Удобным оказалось и то, все данные хранятся в моей же PostgreSQL-базе и уходят по тем же каналам бэкапирования, что и все остальное.

Домашний кинотеатр Jellyfin

Я очень долго пытался привыкнуть к Plex, но так и не смог. Гораздо удобнее оказался Jellyfin, который имеет все необходимые клиенты. На сервере хранятся любые фильмы, а на телевизоре в соседней комнате они по локальной сети выводятся.

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

Проблемы

Из-за последних блокировок, замедлений и ограничений часто в самых неожиданных местах даже в open-source коде возникают фантомные ошибки, на исправление которых уходит много времени. Иногда ты оказываешься в ситуации, когда вместо элементарного подключения API ты занимаешься исправлением ошибок с таймаутом и организацией многослойной системы с проксированием. И многие простые задачи теперь становятся сложными, когда банально даже apt update работает не всегда.

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

Мне помогает в этой ситуации только установка bare-metal решений на собственном железе, с минимумом контейнеризации.

Планы на будущее

Когда речь заходит о домашнем сервере, первым делом пишут про замену облачных сервисов. Так получилось, что у меня нет позитивного опыта работы с Nextcloud, который кажется очевидным выбором в таких случаях. Nextcloud показался мне слишком медленным и перегруженным. Я пробовал Seafile, но мне не хватило функциональности и не понравилась достаточно своеобразная система хранения данных. В будущем я намерен продолжить эксперименты и выбрать то, чем мне будет удобно пользоваться.

Дополнительно я планирую поставить сервис для хранения и обработки фотографий. Мне импонирует Immich, но ставить его я не пробовал.

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

Выводы

Надеюсь, вам было полезно ознакомиться с моим трехлетним опытом организации домашнего сервера. Статья не является инструкцией и пошаговым руководством к действию, а скорее моим подходом и общими принципами к цифровой независимости и автоматизации.

Буду рад почитать комментарии и увидеть ваш опыт.