Comments 6
У меня был в snap socks-сервер весом 300кб и одним файлом конфига. Он сам без спроса посреди дня обновился на новую версию, не совместимую с ядром оси, и отказался откатываться назад.
Ставить туда группу связанных сервисов с тучей зависимостей и конфигов - это гарантия, что всё внезапно упадёт.
С тех пор чем ставить сервис в Snap, я его лучше на смартфон поставлю, который с собой таскаю на работу и домой - надёжность выше будет.
Поддерживаю snap хорош для десктоп каких то приложений, но никак ни для серверных. Лучше как то иметь контроль над сервисом. Ставлю только руками Nginx-FPM + всё остальное. Более того иногда ну просто необходимо слазить рукам и в исходный код. Недавно мигрировал базу с MySQL в PostgreSQL того же NextCloud, не знаю насколько бы мне это было комфортно, когда бы это было всё промазано обертками. Если мне нужен сервис довольной стабильности и изолированности, то проще запилить виртуалку и не мучать голову с бекапами, бекапя сразу виртуалку с гипервизора.
Ну и да, у меня далеко не энтерпрайс. Обычный домашний сервер для фоточек.
Интересно, честно говоря с новыми сервисами в snap не сталкивался с такими проблемами, которые вызваны несовместимостью с ядром OC. Nextcloud активно поддерживается разработчиками, если ставить полноценные stable-релизы, то не должно быть таких проблем. Обновление делаются исключительно руками, все autoupdate отключены.
Спасибо за обратную связь.
Первый разворачиваемый некст тоже был в снап обернут.
Но время показало, что вся эта махина с кучами зависимостей завернутая в снап - весьма не надежная структура, плохо обновляемая и еще хуже с кастомизацией некоторых моментов внутри самой структуры некста.
Второй, уже зная эти моменты - полностью отдельными зависимостями( в рамках разумного).
И еще момент по переезду - достаточно просто хороший диск в локалке на емкость хранимых данных, и параллельно подключенные нексты к одной директории. И простой занимает 4 минуты .
Полагаю не применимо для объема больше 11Тб. Но 11Тб - это прям не маленький бизнес, сосответственно там и схд будет иначе организованнна, а не парой дисков в zfs.
Благодарю за комментарий!
Но очень хочу подсветить некоторые моменты.
Данную статью делал исходя из того, что не нашел одного простого и быстрого способа по развертыванию, резервному копированию и миграции Nextcloud в рамках одной OC (когда у вас нет под рукой больших решение по типу VMware + Veeam)
Именно поэтому, я подчеркнул в данной статье простоту Snap, понятное дело, что это решение не для всех, даже в статье есть момент в котором я постарался намекнуть для кого данная статья.
Цитирую сам себя:
...но если у вас огромный Enterprise сервер с кучей модулей и надстроек над nextcloud, то тогда вопрос:
-“Зачем вы продолжаете смотреть данную статью?"
В целом про надежность могу сказать лишь одно, если сломается, это очень быстро можно восстановить (при условии, если хотя бы раз в неделю делался пятничный общий бэкап всего snap-приложения), если конечно не сгорел ДЦ в провайдере, где брались сервера.
Но я очень надеюсь, что кому-то это было полезно и помогло немного лучше разобраться в Nextcloud в целом.
Установка, резервное копирование и миграция snap nextcloud-сервера (v27.1.8)