Домашний сервер. Второй гайд. Бэкапы.

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

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

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

Еще раз постараюсь коротко донести смысл моего прошлого лонга.

Я не претендовал на то, что описанное мной решение самое правильное и лучшее. Но я старался сделать его очень доступным широкому кругу, доступным по средствам и напрягу. Цель была - заинтересовать хотя бы пару-тройку толковых ребят, популяризировать эту тему и пополнить этим ряды умных и увлеченных технарей.
Короче, это было просто описание одного из способов начать. А дальше замотивированный и увлеченный человек пойдет в гугл, в жтп, в сообщества, в хабр, и доделает всё так, как захочет с высоты полученного опыта.

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

Так что, всем тем, кто ожидаемо нафлудил кучу комментов с похожими шаблонами "Тратишь кучу времени, проще 500 рублей заплатить" / "Не вижу смысла, если все есть онлайн" / "Мне хватает флешки, VLC+dlna, торрсервера" мы даем вместе с Павлом общий ответ: не хочется, не видишь смысла - иди и плати кому-нибудь, или заливай кинчики на флешку, экономь свое драгоценное время и не перенапрягай себе мозги этими сложными консолями. Но и не считай дебилами тех, кто видит в этом интерес и смысл.
Вообще, всегда охреневал от людей, которые искренне не понимают, почему другие прилагают усилия и тратят время на что-то сложное, учатся чему-то, когда можно просто потреблять готовое. Зачем некоторые находят мотивацию и умеют чем-то увлекаться? Если ты тоже это не понимаешь, то объяснять тебе это, все равно, что слепому рассказывать про цвет. А если понимаешь - зачем пишешь этот коммент?

И еще небольшие ответы на несколько тем, чаще всего поднимаемых.

"NAS лучше" - он не лучше, он другой. Это некий компромисс между тем самым пердолингом и возможностями. Удобство, за которое нужно заплатить деньгами и меньшей гибкостью. Тебе это подходит и большего не нужно? Есть деньги на это? Покупай и ставь, мои лонги тебе тогда не нужны. Это можно сравнить с организацией путешествия. Одни покупают неделю в олл-инклюзив, ходят по отелю от пляжа до шведского стола и кайфуют от чилла. Другие сами снимают апартаменты, берут машину напрокат, планируют каждый день по часам, чтобы получить максимум свободы и впечатлений от этой недели и заодно сэкономить на жадности туроператора. Правда, ценой собственного напряга. И те и другие по-своему правы. Вот, что такое nas vs свой сервер. Выбирай по душе.

"Миник - херня, надо нормальное железо" - отдельно же писал про то, что это всё очень опционально, и миник предлагал только в случае если железа нет, места нет, понимания о том взлетит ли эта тема у тебя тоже нет, но при этом хочется попробовать с минимальными вложениями. Не согласен - собирай на чем хочешь. Есть деньги - покупай по-мощнее. Есть готовый midi-tower системник, есть куда его поставить и не беспокоит шум и потребление - вообще повезло. Линкус нормально живет на чем угодно. Статья была вообще не об этом, на эту тему написано куча всего в интернетах, можно поискать.

"Сервак без 10 дисков по 5 терабайт каждый - бесполезен, а жесткие стоят дорого" - если ты понимаешь, что тебе эти объемы нужны, то, опять же, вряд ли тебе нужны эти гайды. Но начинающему это не нужно, а когда станет нужно, он сам поймет и доделает, апгрейд пространства доступен разными способами, и без необходимости менять системник. На попробовать хватит вообще только системы + 200 ГБ, а для полноценного старта достаточно 1-2 ТБ на библиотеку кинчиков (если их не оставлять навсегда) и музыки, туда же фотки, плюс еще 0.5-1 ГБ отдельный жесткий для их бэкапа - это недорого, и мне, например, хватает до сих пор. Нет, если ты любишь слушать в lossless, или киноман с библиотекой в 500 фильмов в 4К, и при этом стоишь на раздаче всего этого 24/7 - то респект, но какое это отношение имеет к стартовому гайду для новичка?

"Автор молчит про бэкапы, и вообще где RAID1 ?!" - про бэкапы я не молчу, читай первую статью глазами. RAID1 имеет минусы, об этом всём будет дальше.

"Белый айпишник не обязателен, есть ddns" - да, действительно, спасибо всем тем, кто про это указал, ddns - это вариант, правда зависимый от роутера. Он мне не подошел бы, потому что я делал домен с ssl-сертификатом для работы vaultwarden, поэтому посоветовать забыл.

"Безопасность..." - отдельный респект тем, кто написал объективную критику связанную с безопасностью, видно, что многие ребята явно грамотнее меня, и, кстати, комментарии об этом всегда написаны максимально дружелюбно и доступно. Еще раз подтверждает корреляцию между интеллектом и вежливостью.
Признаюсь честно, я не сильно разбирался в этом вопросе, я не претендую на роль всезнайки, сам только разбираюсь со всем постепенно. Но я все же думал об этом, и оценил и принял риски для себя в этом вопросе. Если честно, я из комментов так и не понял, чем грозит взлом жопы в моем случае. Какие риски есть при публикации вовне пары-тройки веб-интерфейсов на нестандартных портах, процессы которых живут в контейнерах, запущенных без суперюзер прав. Мой опыт говорит, что риски и последствия не страшные, Лжедмитрий мои сомнения, кстати, подтвердил. SSH, если что, вовне я открывать не рекомендовал, по крайней мере без нормальной настройки с доступом только по ключу и нестандартному порту (аргумент "ключ можно просрать" - странный).
Я без лишней самоуверенности говорю, я искренне не знаю так ли страшны риски, и хочу разобраться, если кто-то шарит, расскажи в комментах, желательно с пруфами.
Думаю, что займусь вопросом безопасности сразу, как только появится много времени. И моя рекомендация всем, кто пойдет в тему хоумсервера - поступить так же. Умные люди в комментах написали подсказки куда рыть - vps, шифрованный туннель, реверс-прокси, виртуализация и т.д. Когда-нибудь разберусь как это все дружит с моим сервером и моими потребностями, что подходит лучше всего и, может, накатаю об этом отдельный гайд.
А пока что, осознанно заявляю - прям сейчас мне похер, я не думаю что меня ломанут, а если и ломанут, то я как-то сильно от этого пострадаю. Поэтому продолжаю.

"Надо разделить по поддоменам" / " Надо все сделать однотипно, например только через docker compose" и прочее подобное. Да, надо-надо. Но, только зачем усложнять настолько прямо в первом же гайде? Тут народ в 95% отвалится при первой же несостыковке с написанным. Это все можно сделать, когда появится опыт и увлечение. А пока я осознанно опирался при написании гайдов на официальную документацию, а она обычно содержит блок "quick start", что для моих целей и подходило.

Ну и хватит, теперь к сути.

Запомни навсегда, свои ценные данные надо бекапить! И настраивать бекап сразу, как только эти данные начали появляться.
Щас скажу страшную вещь, за которую в меня сразу полетят какашки, типа "Ага, сам себе противоречишь! Заманил нубов на селфхостед, а теперь заднюю даешь". Сохранность данных в коммерческих облаках настроена лучше, чем скорее всего это сможешь сделать ты. Ты даже не задумываешься, но каждая твоя нюдсо-фоточка хранится в нескольких копиях, и, может быть, даже когда-то пара копий всех твоих данных в облаке были безвозвратно потеряны, но сервис сам восстановил всё из резерва, а ты это даже не заметил. Это, пожалуй, действительно единственный повод платить за эти облака. Если бы не несколько "но".

Первое - западные облака не хотят брать наши деньги, точнее хотят, но так чтоб ты их перевел через жопу (казахскую, например). Чтоб не запятнать свою безупречную репутацию. Короче, и рыбку съесть и покататься. Для одних это не важно, но для других принципиально, как и для меня. Молчу уж про замедления и риски вообще полной потери доступов к западным облакам и сервисам. Только давайте в политоту не скатываться, я участвовать не буду. Так что, у меня круг сужается только до наших.

Второе - и западные и наши облака стоят дорого, я охренел от ценников того же яндекса, только за счет экономии на этом можно отбить цену равнозначного по объему жесткого за 2-3 года.

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

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

Пятое - они хитрят, не дают возможность пользоваться хранилкой как хочется кроме как базовым функционалом. Примерно как опсосы с моб. интернетом. Например, яндекс диск безбожно ограничивает скорость загрузке/скачиванию данных через webdav. То есть ограничивают продвинутых юзеров, заманивая их на еще более дорогие тарифы Яндекс-Клауда. Поэтому, например, они не подходят в качестве резервной облачной хранилки бэкапов с сервера.

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

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

Восьмое - все данные хранятся ХЗ где, кто имеет к ним доступ и как их использует. Актуально для некоторых, дрочащих на самодостаточность и независимость, для меня например это не было аргументом перехода на свой сервер, но все же. Во многом селфхостинг создали и развивают параноики, это факт.

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

Принцип полноценного бэкапа называется "3-2-1" или "Правило трех копий". Первая копия - основная. Вторая - хранится обязательно на другом накопителе, но в пределах одного места, то есть, на соседнем диске. Третья - где-то в физически отдаленном месте, как минимум за пределами здания. Эта схема защищает от выхода из строя одного или даже обоих дисков в основном хранилище, а также полной потери доступа к серверу или существования всего сервера целиком, например, по причине пожара/кражи.
Так вот, полноценное хранение по этой схеме больших объемов данных сильно усложняется из-за той самой третьей копии, отдаленной физически. Не будешь же каждый день приносить жесткий, копировать на него все нужное и уносить снова. Очевидно, что нужно бэкапить на удаленное облако автоматически. А оно стоит денег. Вот мы и снова вернулись к тому, от чего пытались уйти.

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

Небольшие объемы данных, например документацию, записки, базу паролей, я держу полноценно в 3 копиях, используя для третьей копии бесплатный объем Яндекс Диска. Разумеется, в зашифрованном виде.

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

А теперь конкретнее.

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

Пару слов про RAID1, про который многие отписались в комментах в прошлом посте.

RAID1 (то есть физическое зеркалирование всего диска на другой аналогичный аппаратными средствами) можно применять. Пожалуй, RAID1 был бы полезен для копирования системного диска, насколько я понимаю, он копирует все, включая загрузочные области. И в случае проблем с системным диском можно будет легко и быстро восстановить систему. Но именно для целей бэкапа ценных данных на мой взгляд это не самый оптимальный вариант. Вот почему:
1. Это дорого. Если у тебя не полноценный сервер с RAID-контроллером на материнской плате, то потребуется покупать довольно навороченную недешевую "корзину" для жестких.
2. Тебе потребуется второй в точности такой же по объему и желательно по скорости работы жесткий, как и копируемый. Что, опять же, будет дороже, чем в случае с управляемым копированием, когда можно попробовать обойтись более медленным и меньшим диском.
3. Ты не сможешь выбрать что именно копировать. Если на основном диске у тебя лежат и фотки и фильмы, контроллер скопирует все подряд. Кстати вместе и со всеми ошибками в файловой системе, повреждениями данных и т.п., которые были бы заметны при контролируемом копировании. А если так получилось, что ценные данные у тебя оказались на разных дисках, что покупать дубли для каждого?
4. Этим сложнее управлять. Я не знаю точно, как происходит контроль работы копирования в рейде, но подозреваю, что всё не так просто, как с простым копированием. Что будет, если произойдет какой-то аппаратный сбой, проблемы с жесткими и т.д. Не сталкивался, но просто проверка лога о результатах копирования мне кажется гораздо более простым способом контроля.

Поэтому для целей экономии и гибкости я выбрал другой способ. Заключается он в следующем. Независимо от того какой диск (или диски) уже стоит у тебя под основное хранилище, оцениваем нужный объем только под критичные данные - фото, музыку (лично мне очень не хочется потом вспоминать, что там было и восстанавливать заново), базы паролей, цифровые заметки и т.п., и покупаем подходящий диск, разумеется с запасом на будущее. Затем монтируем его в систему как обычный раздел, и настраиваем регулярное копирование всех этих данных с одного на другой на уровне файловой системы в ОС.

Теперь к выбору железа. В прошлой статье про быстрый старт я говорил, что на первых порах сойдет любой встроенный диск для хранилки. Но для второй копии всё же есть смысл задуматься о надежности. Вот что важно знать:

1. Избегай БУ и авито. Избегай откровенного дешмана. Хотя, даже в сетевых магазинах и на маркетлейсах, поговаривают, всё завалено палью и восстановленным БУ. Надо искать что-то проверенное.
2. 3.5 дюймов надежнее чем 2.5
3. Скорость не важна, наоборот меньшая скорость - это больший ресурс по часам работы. Поэтому 5400 оборотов/сек.
4. Как ты уже понял, только HDD, не SSD
5. У крупных брендов диски выпускаются прямо с заточкой под определенные потребности, изучи.
6. Если у тебя миник, то воткнуть в него 3.5 жесткий не получится, потребуется внешняя корзина или хотя бы бокс на 1 диск.
7. Если же у тебя большой системник, позаботься об минимальном охлаждении, особенно если он стоит в углу маленькой и душной кладовки.

Немного подробнее о корзинах и боксах. Наверное, кто-то возмутится, но я не вижу никаких проблем с их использованием, скорости передачи по USB3.0 вполне достаточные. С открытым типом охлаждение естественное, в моделях подороже есть активное. И совсем не обязательно покупать дорогие брендовые корзины с доп функциями и свистоперделками. Для минимальной сборки сойдет даже самый дешманский бокс на 1 диск. Я для себя купил китайскую док-станцию на 2 диска за полторы тысячи, работает прекрасно. А если и сломается - не жалко, и я увижу это довольно быстро. Так что, внешняя корзина - это то, на чем можно сэкономить. Минимальный бюджет примерно такой - 1 ТБ HDD и внешний бокс/китайская нонейм корзина для него. Это в районе 5-6 т.р.

Кстати, задумайся, что всё что здесь было написано - актуально не только для сервера, но и для простых домашних или рабочих компов. Не боишься когда-нибудь потерять всё, что для тебя имеет значение? Если, конечно, есть что-то, имеющее для тебя значение.

Раз уж заявился, что пишу гайды для новичков, подскажу как добавить новый диск в систему. Дальше пишу, продолжая прошлый гайд, для ОС, указанной там (Кубунта lts 24.02).

При первом подключениии нового диска, как и в винде, он не появится в файловой системе, его нужно отформатировать. Сделать через GUI этом можно в стандартной утилите "Диспетчер разделов KDE". Новый диск будет видно в колонке слева, выбрав свободное пространство нажимаем на "Создать" и создаем на нем раздел с файловой системой ext4. Ничего сложного там нет, только создай раздел с понятной читаемой меткой, типа "1TBbackups", это потом пригодится. Если диск установлен внутри корпуса, то есть подключен через контроллер материнки, он примонтируется сам и будет делать это при каждом включении автоматически, делать больше ничего не нужно.

В случае, если диск стоит во внешнем боксе/корзине, подключенной по USB, система определяет его как "внешний накопитель" и не пытается примонтировать при включении сервера. Это значит, что при каждом ребуте диск не будет доступен без дополнительных движений. Научимся это исправлять. Проверь, что диск примонтировался в первый раз, просто зайдя на него в файловом менеджере. Теперь выполняем команду:

Будет выведен список всех примонтированных разделов. По названию метки находим вновь подключенный диск и копируем значение UUID. Теперь выполняем:

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

В значение UUID, разумеется, подставь своё.
Путь /mnt/1TBbackup - это точка монтирования, то есть каталог, где потом будет появляться всё содержимое диска, можешь оставить эту, можешь поменять на свою, если понимаешь, что делаешь. Остальное без изменений.

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

Готово, теперь можно настраивать туда создание бэкапов.

Как договорились раньше, бэкап настраиваем обычным копированием всего нужного на отдельный диск. Само собой, всё будет автоматизированно.

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

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

Теперь создадим bash-скрипт. Способ первый, нубский - создать как в винде, правой кнопкой в нужной директории внутри файлового менеджера, например Dolphin. Можно создать файл прямо внутри домашнего каталога, например, с именем rsync_backup.sh. Затем нужно поставить галку "исполняемый" в свойствах файла.
Способ второй, трушный - через консоль:

Отредактировать также можно через оконный редактор или консольный nano. Пример содержимого:

Пояснения. rsync будет запущен с параметрами, которые:
- скопируют все файлы рекурсивно (то есть со всеми вложенными директориями
- с сохранением структуры каталогов, то есть увидишь в бэкапе всё то же, как было в оригинале, включая права и владельцев.
- определяя изменение файлов по чексумме, а не по дате
- удаленные в оригинале файлы также будут удалены в бэкапе
- проигнорирует возникшие ошибки, доведя синхронизацию до конца
- весь подробный процесс копирования будет записан в лог
По путям все тоже довольно просто, в столбик записаны пути каталогов для синхронизации, кавычки используй при наличии пробелов.
В последней строчке до > указан путь хранения бэкапа. После > путь файла с логом.

Когда доделаешь под свои задачи, попробуй запустить файл командой ./rsync_backup.sh. Скрипт отработает первый раз, проверь, что все файлы появились в каталоге бэкапа, загляни в файл лога, проверь на предмет возможных ошибок. Далее делай это время от времени. Хотя бы раз в месяц.

Теперь сделаем так, чтобы скрипт запускался самостоятельно и регулярно. Используем для этого классический cron:

При первом запуске он запросит выбор редактора, выбираем привычны nano в первой опции. В открывшемся редакторе в конец добавляем такую строчку:

Не забудь поменять путь. Управление временем запуска происходит через числа в начале. В указанном примере скрипт будет запускаться в 4:30 ежедневно. Настройка гибкая, если нужно более сложное правило, например, через день, или только по понедельникам - гугли.

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

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

Предположим, ты накатил себе vaultwarden, и теперь хранишь базу паролей на сервере. Объем данных там не большой, но очень ценный. Во-первых, проеб базы логопассов вместе с сервером создаст миллион проблем, поэтому их хорошо бы все же сохранить в 3 копии. Во-вторых, хранить где-то в чужом облаке пароли ссыкотно, поэтому третью копию нужно дополнительно зашифровать перед заливкой в чужое облако.

Вот как это можно сделать. В начале разберемся с Яндекс Диском. Пользоваться им можно не только в браузере или приложениях, но и по протоколу webdav - фактически это просто передача файлов поверх http. Яндекс, хоть и заявляет такую возможность, но для таких хитрых перцев как мы создает проблемы, например дико режет скорость закачки. Поэтому, способ подойдет только для не очень больших объемов данных, лучше в пределах десятков мегабайт. Если аккаунт уже есть, то и диск с некоторым бесплатным объемом тоже есть. Идем на страничку:

https://yandex.ru/dev/disk/doc/ru/concepts/quickstart#quickstart__oauth

Инструкция к настройке простая, сводится к получению токена.

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

Добавляем в конец строчку по шаблону MY_SECRET="MYPASSWORD"
Назвать переменную можешь как хочешь. Для применения нужен ребут.

Теперь создаем .sh скрипт, как в первой задаче, например, с именем archive_backup.sh:

В него пишем следующее:

exec ... - в строчке указан путь, куда будет записан весь лог выполнения скрипта
pass="$MY_SECRET" - тянем созданную переменную с паролем
zip ... - создаст архив указанной директории, закрытый твоим паролем. Есть мнение, что шифрование в zip слабоватое, желающие могут раскурить использование 7zip вместо него. А кто-то обязательно скажет, что шифровать надо исключительно rsa-ключом. Но тогда быстро посмотреть содержимое не выйдет.
curl ... - зальет архив на яндекс диск, создав под это папку backup, обрати внимание как происходит авторизация, здесь будет указан адрес твоей почты и полученный у яндекса токен. Кстати, хорошо бы его тоже сначала засунуть в переменную окружения... Но я поленился.
mv ... - переместит созданный архив на диск с бэкапами.

Теперь снова автоматизируй через крон. Как это сделать, было описано в первой задаче. Верю в тебя.

Собственно, на этом пока все. Не уверен, что буду продолжать эти логни. Во-первых, самому надо сначала подучиться. Во-вторых, думаю, что человек, который осилит хотя бы это, сможет продолжить самостоятельно. Вот пара ссылок для пытливых, где можно продолжить, а лучше даже и начать, вместо моей дилетантской писанины.

https://awesome-selfhosted.net/

https://samohosting.ru/

Всем мир, всем пока!