Мой личный Яндекс Диск. Домашнее облако
Обновлено 3 октября 2026 года. Первая версия статьи вышла в 2022 году.
В 2022 году я написал эту статью про старый мини-ПК с CasaOS, который стоял в тумбочке под телевизором и был для меня «своим Яндекс Диском». Прошло почти четыре года. Мини-ПК выключен, а весной 2026-го я собрал отдельный сервер в корпусе Jonsbo N1 и перенёс основную инфраструктуру на Proxmox.
Задача осталась прежней: семейный фотоархив с 2004 года, документы, заметки, исходники проектов, всё, что должно быть под рукой с компьютера, ноутбука и телефона. Но вопрос изменился. Раньше он звучал как «как сделать себе Яндекс Диск». Теперь: как сделать так, чтобы всё это спокойно работало годами и восстанавливалось после поломки.
Коротко
- Было (2022): мини-ПК на Core i3, CasaOS, Syncthing, PhotoPrism, FileBrowser, около 13 500 ₽ за всё.
- Стало (2026): Proxmox VE на отдельном сервере, 1 виртуальная машина и 23 LXC-контейнера, VPN через внешний VDS, локальные и внешние бэкапы, мониторинг.
- Что пережило все изменения: Syncthing, SMB и SSH.
- Что ушло: CasaOS, PhotoPrism, FileBrowser, KeenDNS.
- Главный урок: зелёный статус «backup выполнен» ничего не доказывает. Важно знать, что именно и откуда вы сможете восстановить.
- Экономии здесь нет. Если цель только в том, чтобы не платить за облако, такой сервер не нужен.
Как всё начиналось в 2022 году
У меня без дела лежал мини-ПК с Core i3-7100U, 8 ГБ памяти и SSD на 128 ГБ. Я добавил жёсткий диск на 1 ТБ и условно посчитал стоимость системы примерно в 13 500 рублей. Тогда же попытался сравнить это с подпиской на облачное хранилище и посчитать окупаемость. Сам себе написал:
Окупится через шесть лет? Кого я обманываю.
Как показало время, правильно написал.
Система строилась вокруг CasaOS. Для своего уровня на тот момент это было идеальное решение: не нужно сразу разбираться с Docker Compose, сетями контейнеров и reverse proxy, нажал кнопку и получил работающий сервис. Именно через CasaOS я втянулся в Linux и self-hosted.
Потом мне стало тесно в модели «один Linux-сервер с набором приложений». Захотелось нормально разделять сервисы и экспериментальные окружения, и весной 2026 года я переехал на Proxmox.
Как всё устроено сейчас
Железо и диски
Сервер собран в корпусе Jonsbo N1: Intel Core i5-6500, 16 ГБ памяти и четыре отдельных накопителя.
- системный SSD;
- SSD Crucial BX500 на 1 ТБ под приложения;
- WD Red на 1 ТБ под домашние данные (фотографии, документы, заметки);
- отдельный HDD под резервные копии.
ZFS и программного RAID нет. Платформа: Proxmox VE 9.2.x на Debian 13.
Сервисы
На основном хосте сейчас 1 виртуальная машина и 23 LXC-контейнера. Здесь живёт уже приличная часть моей личной инфраструктуры: Git, Vaultwarden, сайты, рабочие и тестовые сервисы, эксперименты, которые мне периодически приходят в голову запустить.
Большинство сервисов разнесены по отдельным LXC. Так они меньше зависят друг от друга, а переносить и восстанавливать их проще. Там, где приложению удобнее работать через Compose, внутри контейнера запущен Docker.
Что такое домашний сервер и нужен ли он вам
Если совсем просто, домашний сервер — это обычный компьютер, который постоянно включён и предоставляет другим устройствам какие-то ресурсы. В самом простом варианте это компьютер с большим диском и общей папкой. Дальше всё зависит от фантазии: синхронизация файлов, фотогалерея, умный дом, медиасервер, Git, собственные веб-приложения.
Для меня всё началось с файлов. Мне хотелось, чтобы основная копия моих данных физически находилась у меня. Не потому, что Яндекс Диск или Google Drive плохие: внешние сервисы я использую и сейчас, например S3 для бэкапов. Просто публичное облако для меня теперь один из уровней инфраструктуры, а не единственное место, где существуют данные.
Есть и бытовое преимущество. Чтобы посмотреть дома несколько гигабайт старых фотографий, не нужно сначала загружать их в интернет, а потом скачивать обратно в соседней комнате. Они открываются с сервера по локальной сети.
А дальше работает классический механизм: если дома уже стоит постоянно включённый Linux-сервер, на него постепенно переезжают другие задачи.
Облако, NAS или свой сервер
Сейчас я бы сравнивал варианты так:
| Публичное облако | Готовый NAS | Свой сервер | |
|---|---|---|---|
| Начать пользоваться | Очень просто | Просто | Нужно разбираться |
| Данные физически дома | Нет | Да | Да |
| SMB в локальной сети | Обычно нет | Да | Да |
| Собственные приложения | Ограниченно | Зависит от платформы | Практически любые |
| Обслуживание | На провайдере | Частично на владельце | Полностью на владельце |
| Расширяемость | По тарифу | В рамках платформы | Очень высокая |
| Резервные копии | Нужно понимать, что именно защищено | Нужно организовать | Нужно организовать самому |
Если вам нужно просто хранить семейные фотографии, документы и иногда смотреть фильмы по сети, я не уверен, что вам стоит повторять мою конструкцию. Готовый NAS будет проще. Мой сервер быстро перестал быть хранилищем: мне понадобились Git, Vaultwarden, поднимать свои пэт-проекты и эксперименты, тестовые окружения, и т.д. Полноценный сервер с виртуализацией оказался удобнее.
Сколько это стоит
В 2022 году сервер условно стоил 13 500 рублей. Эту цифру я оставляю как исторический срез: с нынешней системой её сравнивать бессмысленно. Новый корпус на 5 дисков, SSD для приложений, несколько HDD WD Red+, блок питания и остальные комплектующие — по ощущениям около 50 т.р. + регулярные расходы на внешний VDS и S3 бакет. Я даже не хочу выводить «стоимость за терабайт».
Если цель исключительно сэкономить на облачной подписке, такой домашний сервер покупать не надо. Если нужен один терабайт облака, просто купите один терабайт облака. Домашний сервер имеет смысл по другим причинам: контроль над данными, локальная скорость, возможность запускать собственные сервисы, учиться и строить инфраструктуру так, как нужно именно вам.
Три разные задачи: синхронизация, доступ, резервные копии
Когда только начинаешь, всё это легко смешать в одно понятие «моё облако». На практике это независимые уровни:
- Синхронизация (Syncthing) нужна, чтобы актуальные документы, заметки и фото автоматически появлялись на нужных устройствах.
- Сетевой доступ (SMB) нужен, чтобы открыть большой архив прямо с сервера и не хранить его копию на каждом компьютере.
- Резервное копирование нужно, чтобы пережить ошибку, удаление данных или потерю оборудования.
Syncthing: пережил все изменения
Несколько моих устройств должны иметь актуальные версии одних и тех же файлов без ручного копирования. Так у меня синхронизируются документы, заметки Obsidian и фотографии: документ можно начать на основном компьютере и продолжить на ноутбуке или телефоне, одна и та же база Obsidian доступна везде. Фото с телефона автоматически уходят на домашний сервер.
Схема изменилась. В 2022 году компьютер работал в режиме send-only, а сервер в receive-only, чтобы случайное удаление на сервере не разъезжалось по устройствам. Сейчас Syncthing живёт в отдельном LXC. Для проверенных папок с документами и заметками сервер работает в обычном двустороннем режиме sendreceive, а включённое staggered versioning хранит старые версии изменённых и удалённых файлов до 180 суток.
Syncthing — не резервная копия. Если файл изменился, правка может разъехаться по устройствам. Версионность помогает, но независимый backup всё равно нужен, поэтому документы и заметки дополнительно попадают в Restic и во внешнее хранилище.
SMB: как я открываю фотоархив
SMB — сетевой протокол общего доступа к файлам. В Windows папку на сервере можно подключить как сетевой диск и работать с ней почти как с локальной.
Samba у меня работает прямо на Proxmox-хосте. Семейный фотоархив лежит на отдельном HDD и опубликован как ресурс photos. Вход требует авторизации, гостевой доступ запрещён, ресурс доступен только для чтения. Запись я запретил намеренно: мне спокойнее, когда с обычного компьютера нельзя случайно удалить половину семейного архива. Новые фотографии попадают в архив отдельным процессом синхронизации.
С Android можно подключаться через любой файловый менеджер или плеер с поддержкой SMB (я так раньше смотрел медиа через VLC): нужны адрес сервера, имя ресурса и учётные данные.
Яндекс Диск, SMB и WebDAV
По поисковым запросам я вижу, что здесь постоянно возникает путаница. SMB в моей системе используется для доступа к моему собственному серверу. Яндекс Диск сам по себе SMB-сервером не является, и подключиться к нему адресом вида \\server\folder нельзя.
Для сценария «облако как сетевой диск» у Яндекс Диска есть WebDAV. Для стороннего WebDAV-клиента нужен отдельный пароль приложения, а в Windows используется адрес https://webdav.yandex.ru. Файлы при этом физически остаются в облаке, так что без интернета они недоступны. Яндекс сам рекомендует для большинства сценариев обычное приложение Диска; WebDAV имеет ограничения, например файл, удалённый через WebDAV, не попадает в корзину, а удаляется окончательно. Доступ к Яндекс Диску по WebDAV сейчас доступен в тарифах Яндекс 360.
| SMB (мой сервер) | WebDAV Яндекс Диска | Синхронизация | |
|---|---|---|---|
| Где лежат исходные данные | На моём сервере | В облаке Яндекса | На нескольких устройствах |
| Нужен интернет | Дома нет | Да | Для локальной копии нет |
| Мой сценарий | Большой фотоархив | Облако как сетевое хранилище | Документы, заметки, фото |
| Кто обслуживает сервер | Я | Яндекс | Зависит от решения |
«Сделать свой аналог Яндекс Диска», «подключить Яндекс Диск как сетевой диск» и «синхронизировать файлы между устройствами» — три похожие для пользователя задачи, но технически решаются они совершенно по-разному.
Удалённый доступ
В старой версии статьи для внешнего доступа я использовал KeenDNS. Сейчас он не используется.
У меня есть внешний VDS, к которому домашняя сеть подключена через VPN. Нужен доступ домой с ноутбука или телефона: клиент входит в VPN и получает доступ к разрешённым ресурсам домашней сети. Публичные сайты работают иначе: входящий HTTPS принимает Traefik на VDS и через существующий туннель отправляет запрос к нужному сервису дома.
У такой архитектуры важное свойство: домашнему серверу не нужен белый IP и не нужно принимать входящие подключения из интернета, потому что домашняя сторона сама устанавливает соединение с VDS.
SMB, SSH и административные интерфейсы наружу не публикуются, доступ к ним только через VPN. Reverse proxy удобен для веб-приложений, а для всего остального мне спокойнее VPN.
Практическая реализация такой схемы — в отдельной статье: Pangolin: доступ к серверу без открытых портов.
Резервные копии
Здесь моё отношение за четыре года изменилось сильнее всего. В старой статье можно было написать «всё это дело бекапится» и пойти дальше. Сейчас такой формулировки мне недостаточно.
Что и куда копируется
| Что | Как | Куда | Оговорки |
|---|---|---|---|
| Виртуальные машины и LXC | vzdump, ежедневно |
Отдельный backup-диск | Хранятся несколько дневных, недельных и месячных состояний |
| Данные приложений | Restic | Backup-диск | |
| Конфигурация серверов | Отдельное сохранение | Backup-диск | |
| Выбранные архивы, данные приложений, Syncthing | Restic (шифрование, дедупликация) | Внешнее S3 | 5 дневных, 2 недельных, 3 месячных версии; есть проверки репозитория с чтением части данных |
| Документы и заметки | Syncthing с версионированием 180 дней + Restic | Устройства и внешнее S3 | Syncthing сам по себе не backup |
| Фотоархив (~336 ГиБ) | Отдельная копия | Внешний HDD | Не входит в задания Restic и S3 |
Фотоархив не участвует в облачном бэкапе. Полный фотоархив семейных фото примерно на 336 ГиБ не входит в текущие задания Restic и S3. Это не значит, что фотографии существуют в единственном экземпляре: у меня есть отдельная актуальная копия на внешнем HDD. Следующий шаг уже запланирован: вернуть в работу старый мини-ПК, поставить его у родителей и автоматически копировать фотографии туда. Тогда появится копия в другом месте.
RAID — это не backup
Ещё в старой статье я думал про RAID1. Сейчас RAID у меня нет: система, приложения, домашние данные и бэкапы разнесены по отдельным дискам без зеркалирования, и я отношусь к этому спокойнее.
RAID полезен, если нужна непрерывность работы после отказа диска. Но от случайного удаления, повреждения базы, ошибки программы, шифровальщика или потери всего сервера он сам по себе не спасёт. Это не аргумент против RAID, просто RAID и backup решают разные задачи. Для домашней инфраструктуры мне важнее независимые копии и понятная процедура восстановления.
Проверять надо восстановление, а не копию
Годами можно успешно архивировать данные и однажды обнаружить, что внутри лежало уже повреждённое состояние приложения. У меня был именно такой случай с SQLite-базой Hermes: архив читался нормально, но внутри была повреждённая база. После этого я добавил проверку самой базы, а не только факта появления файла копии.
Теперь я периодически делаю реальные тестовые восстановления. Например, некоторые LXC восстанавливались в отдельные изолированные окружения, после чего проверяются база данных и HTTP-приложение. Это полезнее любой зелёной надписи «backup completed».
Про то, где хранить пароль от зашифрованного Restic-репозитория, я писал отдельно: «Пароль от зашифрованного бэкапа можно хранить рядом с самим бэкапом».
Мониторинг
Пока на сервере лежит несколько файлов, можно время от времени заходить и смотреть, жив ли он. Когда на нём два десятка контейнеров, VPN, сайты и бэкапы, так уже не получается.
Сейчас у меня собственный мониторинг: он проверяет состояние серверов и VPN-туннелей, свежесть резервных копий, SMART дисков и heartbeat отдельных приложений. Уведомления идут через ntfy и Healthchecks. Есть даже управление вентилятором HDD по температуре. Например, на момент написания этой статьи самый горячий HDD был около 33 °C, CPU около 45 °C.
Что уже успело сломаться
Самая полезная часть любой домашней инфраструктуры начинается после первой аварии.
- VPN-шлюз после обновления. Он загрузился без нужных headers, туннель не поднялся. Вывод: после обновлений проверять не только «загрузилось», но и работу туннелей.
- Зависшие locks в Restic. Копии создавались, но следующие этапы падали. Вывод: следить за всей цепочкой, а не только за созданием копии.
- Повреждённая SQLite внутри читаемого архива. Вывод: проверять содержимое резервной копии, а не только её наличие.
- Занятый IP у нового контейнера. Около десяти минут в сети был ARP-конфликт, а одно из приложений отвечало ошибкой 504. Вывод: адреса контейнеров нужно учитывать и не раздавать вручную наугад.
- Сломанная проверка SMART. Ошибка с
sudoсломала сам скрипт, мониторинг увидел отсутствие метрик, хотя диски были исправны. Вывод: «нет данных» тоже должно быть сигналом, и его причину надо разбирать отдельно.
Тема аварийного доступа разобрана отдельно: Как не остаться без доступа к серверу в критический момент.
Что случилось с PhotoPrism, FileBrowser и красивыми интерфейсами
В старой конфигурации PhotoPrism превращал папку с фотографиями в галерею, а FileBrowser открывал файлы через браузер. Сейчас я не использую ни то ни другое. Фото смотрю с Windows напрямую по SMB, а если на сервере нужно что-то найти или перенести, мне проще зайти по SSH.
Кроме того, у меня есть Hermes — инфраструктурный агент, которому доступна моя домашняя инфраструктура. Часть рутинных задач вроде проверки состояния сервиса или поиска файлов я поручаю ему.
Получилось забавно: когда я собирал домашнее облако, мне хотелось красивых веб-интерфейсов. Через четыре года значительную их часть я заменил терминалом и агентом.
Что я сделал бы иначе, если бы начинал сегодня
В 2022 году меня интересовало, какие ещё красивые приложения можно поставить. Сейчас я начал бы иначе:
- Определил бы, какие данные действительно нельзя потерять.
- Сразу сделал бы вторую независимую копию и проверил восстановление.
- Только после этого ставил бы фотогалереи, панели управления и медиасерверы.
- Гораздо раньше разделил бы синхронизацию, сетевой доступ и резервное копирование.
- Раньше занялся бы мониторингом. Сервер становится удобным не тогда, когда запущен двадцатый контейнер, а когда про него можно забыть и быть уверенным, что при проблеме он сам позовёт.
Новичку я вполне мог бы посоветовать CasaOS: он сильно снижает порог входа в self-hosted. А для своей нынешней системы я снова выбрал бы виртуализацию. Возможность держать сервисы в отдельных LXC, экспериментировать и независимо их восстанавливать оказалась ценнее красивой единой панели.
Итоги
В 2022 году я хотел сделать себе аналог Яндекс Диска. В 2026-м у меня дома стоит сервер с Proxmox, отдельными контейнерами, Syncthing, SMB, VPN, внешним VDS, локальными и внешними бэкапами, мониторингом и несколькими десятками сервисов.
Многое из казавшегося важным исчезло: CasaOS, PhotoPrism, FileBrowser, KeenDNS, сценарий с медиатекой и SMB на телевизоре. А простые инструменты пережили всё: Syncthing по-прежнему таскает файлы между устройствами, SMB позволяет открыть папку по сети, SSH остаётся удобнее очередной красивой панели.
Домашний сервер не обязан быть сложным. Сложность появляется сама, когда появляются реальные задачи. Поэтому лучше начинать с задач, а не со списка сервисов, которые хочется установить.
Больше заметок про серверы, сети и резервные копии — в рубрике «Инфраструктура».
Частые вопросы
Чем домашний сервер отличается от NAS? NAS в первую очередь хранит данные и отдаёт их по сети, но современные модели тоже умеют запускать контейнеры, так что граница условная. Полноценный сервер обычно даёт больше свободы в выборе ОС, виртуализации и конфигурации. См. таблицу выше.
Можно ли заменить Яндекс Диск своим сервером? Для хранения данных, доступа к файлам и синхронизации между своими устройствами да. Но вы берёте на себя оборудование, обновления, удалённый доступ и резервное копирование. У меня свой сервер спокойно сосуществует с внешними облаками.
Можно ли подключить Яндекс Диск по SMB? Напрямую нет. Для подключения Диска как сетевого хранилища Яндекс предлагает WebDAV (см. раздел Яндекс Диск, SMB и WebDAV).
Чем SMB отличается от WebDAV? SMB в моём сценарии работает внутри локальной или VPN-сети и даёт прямой доступ к файлам на собственном сервере. WebDAV работает поверх HTTP и в случае Яндекс Диска даёт доступ к файлам, которые остаются в облаке.
Как открыть файлы домашнего сервера в Windows?
Введите адрес SMB-ресурса в Проводнике (\\адрес-сервера\имя-ресурса) и авторизуйтесь; затем при желании подключите как сетевой диск.
Нужен ли белый IP для домашнего сервера? Не обязательно. Моя схема работает через исходящий VPN-туннель к внешнему VDS (см. раздел Удалённый доступ).
RAID заменяет резервную копию? Нет. RAID помогает продолжить работу при отказе диска, но не защищает от удаления файлов, повреждения данных или потери сервера. У меня RAID сейчас нет, вместо него независимые локальные и внешние копии.
Что будет с файлами, если сервер сломается? Зависит от типа данных: документы, заметки, конфигурация и часть сервисов имеют локальные и внешние копии, фотоархив дополнительно лежит на внешнем HDD. Следующий этап — ещё одна автоматическая копия фото на мини-ПК у родителей. Подробности в разделе Резервные копии.