Установка, резервное копирование и миграция snap nextcloud-сервера (v27.1.8)
Планирование
Добрый день, мой дорогой читатель. Немного поговорим о таком этапе как «планирование».
Первый вопрос в нашей ситуации, а зачем мигрировать? Чтобы ответить, на этот вопрос, то мы погружаемся в бизнес. Есть такие понятия как бюджет на инфраструктуру, отказоустойчивость, меняем провайдера услуг или закупили свое собственное оборудование, возможно улетаем в облака (означает это, что будет весело, но больно).
Итак, нам каким-то образом ответили на наш вопрос, зачем же мы мигрируем. Мы с вами отвечаем:
— «Сделаем, без проблем».
Вопрос, который нам задают в ответ:
-«Сколько же понадобится времени на миграцию?»
Теперь мы начинаем смотреть, а сколько у нас занято места на сервере.
(Я не буду углубляться настолько подробно, вплоть до подключения к серверу через ssh или консоль, я верю, что вы это уже умеете или научитесь, прежде, чем сюда заходить)
Посмотрим наш диск базовой командой (на моем личном nextcloud-сервере все просто с разметкой LVM, почти все пространство монтировано в корень)
# df -h
Вывод команды:
Использовано 72G из 400G, хорошо, значит сервер на который мы должны мигрировать, обязан иметь диск не менее 100G с возможностью дальнейшего увеличения и добавления внешних средств хранения данных.
Сколько будет длится простой?
В целом берем с запасом, простой сервиса будет около 2–4 часов, если у нас примерно столько же как и в примере данных для переноса. Во время передачи архива бэкапа сервис будет доступен, недоступность будет в двух местах, во время начала бэкапа на исходном сервере, далее когда будем выполнять переключение между серверами.
Планируем работы на ночь и все у нас хорошо. (На время работ при желание можно выставить maintenance mode в конфигурационном файле php, чтобы никто не попытался ломится на сервер)
# nano /var/snap/nextcloud/current/nextcloud/config/config.php
Меняем строчку:
# maintenance mode => false, на maintenance mode => true.
Хорошо, далее, мы должны понимать, что переезжать на более слабый сервер, не очень хорошая идея. nextcloud монолит, который сильно грузит систему php-модулями. Если хранение данных будет производиться чаще всего в «холодном» режиме, то есть, зашли-скачали-вышли, то 2 vCPU/ 2RAM на виртуальном машине хватит с головой, но если у вас огромный Enterprice сервер с кучей модулей и надстроек над nextcloud, то тогда вопрос:
-«Зачем вы продолжаете смотреть данную статью?»
Посмеялись и хватит. Надеюсь, суть вы уловили.
О способе в целом
Если у вас виртуализация, есть поверх нее средства бэков по типу Veeam или Commvault, то наверное быстрее перенести саму виртуальную машину целиком, сделав бэкап всей файловой системы и не парится. Может вообще стоит выгрузить вм полностью, в формате .ova (для VMware), остальные форматы я не знаю)
Мой вариант нужен, если у вас нет доступа до виртуализации или же это железный сервер, когда есть две OS и у них между собой есть только соединение по ssh.
На чем он основан, этот мой способ? На работе со snap-приложением целиком и его полной архивации, далее архив передается, распаковывается, приложение начинает работать уже с ним. Способ еще подходит просто для того, чтобы иногда делать бэкап системы и выгружать к себе локально.
Сам способ в виде инструкции
(Работаю через root, вы подставляйте sudo перед командами, если нет rootна сервере)
Представим, у нас уже есть сервер, который мы установили через snap.
Об установке через snap:
По умолчанию пакетного менеджера snap в системе может не быть, его надо установить: # apt update && apt install -y snapd.
Затем можно устанавливать и nextcloud:
# snap install nextcloud
Переходим по IP сервера в браузере, устанавливаем логин и пароль для администратора. Есть возможность изменить основной путь хранения данных пользователей, меняем если нужно, но дальше тогда запоминаем его и идем выдумывать свою инструкцию поверх моей.
Я не менял, так как все хранится на виртуальной машине, которая подключена к резервному копированию, плюс выгружаю бэкап данных к себе локально, но об этом чуть попозже.
Можно подключить внешние диски, хранить на них, хранить через ftp и S3, в целом всё одно и тоже, все монтируется к вашей основной файловой системе и оттуда nextcloud берет информацию о данных пользователей.
Прописываем доверенный домен для нашего сервер или IP.
Само значение храниться в файле конфигурации php:
# nano /var/snap/nextcloud/current/nextcloud/config/config.php
Ищем поле «trusted_domains» и прописываем свое значение в поле как на скриншоте ниже:
Или можно пойти по простому пути и прописать команду ниже:
# snap run nextcloud.occconfig:system:settrusted_domains 1 --value=*example.com
(Когда будем менять на новом сервере данное значение, нужно его менять только через сам конфигурационный файл)
Выдаем нашему php необходимое значение оперативной памяти:
# snap set nextcloud php.memory-limit=1024M
Вот у нас установленный сервер, ставим свой SSL-сертификат или Let`s encrypt
(я покажу, как ставить бесплатный)
Вызываем создание сертификата командой:
# snap run nextcloud.enable-https lets-encrypt
Чтобы продолжить, введите «у».
Затем нужно предоставить адрес электронной почты.
# Please enter an email address (for urgent notices or key recovery): your_email@domain.com
В конце нужно ввести домен сервера nextcloud:
# Please enter your domain name (s) (space-separated): example.com
После этого запрос на сертификат будет отправлен в Let«s Encrypt, и при условии, что все хорошо, для немедленного внедрения SSL демон Apache будет перезапущен автоматически.
# Attempting to obtain certificates… done Restarting apache… done Теперь вы можете войти в Nextcloud.
В целом на исходном сервере всё, работаем, создаем пользователей и радуемся до момента необходимости миграции)
Немного об управлении через snap:
# snap list --all (вывести все snap-демоны)
# snap start/stop/disable/enable/restart/ *snapd (обычные действия как и в systemctl)
Чтобы узнать все сервисы и приложения, которые предоставляет этот snap, вы можете взглянуть на файл определения snap.yaml:
# cat /snap/nextcloud/current/meta/snap.yaml
Процедура обновления snap nextcloud (не забываем о снапшотах системы через snap или виртуализацию)
Останавливаем сервис:
# snap stop nextcloud
Принудительно обновится на стабильный релиз от разработчиков пакета:
# snap refresh nextcloud --stable
Выбрать из листа стабильных версий:
# snap refresh --channel=25/stable nextcloud (downgrade так просто не работает, проверено)
Подробнее о snap по ссылке: https://snapcraft.io/nextcloud
О снапшотах:
Останавливаем сервис (опционально, необходимо чтобы клиенты не заливали данные сервис)
# snap stop nextcloud
Создаем снапшот сервиса:
# snap save nextcloud
Получаем примерно следующее:
root@nextcloud:/# snap save nextcloud
Set Snap Age Version Rev Size Notes
1 nextcloud 9m22s 27.1.8snap1 41 512 14.3GB -
Сам снапшот можно найти по пути /var/lib/snapd/snapshots/*
Включаем сервис, если останавливали:
# snap start nextcloud
Далее восстанавливаем по ID снапшота сервис, в нашем случае это »1»
# snap restore "snapshot-ID"
Если снапшот не нужен, то просто удаляем его следующей командой:
# snap forget "snapshot-ID"
Ну и наконец-то, сам способ миграции:
Для удобства восприятия пути, создаем директорию на исходном сервере:
# mkdir /bakups/snap
Создаем скрипт:
# nano backups.sh
Прописываем в файл следующее:
nextcloud.export
tar cvpzf /backups/snap/backup_snap_$(date +%Y%m%d-%H.%M.%S).tgz /var/snap/nextcloud/common/backups/*
rm -rf /var/snap/nextcloud/common/backups/*
Даем ему привилегии для исполнения:
# chmod 700 backups.sh
Выполняем его:
# ./backup.sh
Пока он выполняется, можно подготовить второй сервер под миграцию, устанавливаем сервер nextcloud через snap той же самой версии. Как это сделать описано выше. Доходим до момента с установкой доменного имени и сертификаты, их установим после миграции.
На новом сервере создаем аналогичные директории для бэкапа:
# mkdir /backups
# mkdir /backups/snap
# mkdir /var/snap/nextcloud/common/backups
Заходим на старый сервер и переносим архив бэкапа сделанного через скрипт:
# scp /backups/snap/*имя файла архива root@*адрес нового сервера:/backups/snap
На новом сервере даем привилегии до этой директории:
# chown -R root:root /backups/snap
На новом сервере даем привилегии до этой директории:
# chown -R root:root /var/snap/nextcloud/common/
Распаковываем архив:
# tar -xvzf backup_snap_20240412-00.24.44.tgz -C /var/snap/nextcloud/common/backups/ --strip=5
Импортируем конфигурацию:
# nextcloud.import /var/snap/nextcloud/common/backups/
Проверяем и радуемся, в целом на этом всё с переносом, далее прописываем наш домен в конфигурацию php и выдаем сертификат, смотрим выше как это сделать.
Так как данные копируется из директории /var/snap/nextcloud/common/backups/20240414–010325/data, в директорию /var/snap/nextcloud/common/nextcloud/data/ (или в указанную ранее при установке).
Поэтому чтобы не тратить столько места на диске, удаляем лишние данные, которые уже итак скопированы:
# rm -rf /var/snap/nextcloud/common/backups/20240414-010325/data
Как использовать всё вышеописанное для резервного копирования?
Используем скрипт, для создания архива выше, только в путь можем указать удаленное хранилище, типа Ceph или чего-то еще, дальше на ваше усмотрение.
Далее этот скрипт передаем в Cron:
# crontab -e
Настраиваем частоту выполнения и сохраняем изменения.
Вот и всё, всем спасибо за внимание, это моя первая статья, не судите строго!
