Планирование

Добрый день, мой дорогой читатель. Немного поговорим о таком этапе как “планирование”.
Первый вопрос в нашей ситуации, а зачем мигрировать? Чтобы ответить, на этот вопрос, то мы погружаемся в бизнес. Есть такие понятия как бюджет на инфраструктуру, отказоустойчивость, меняем провайдера услуг или закупили свое собственное оборудование, возможно улетаем в облака (означает это, что будет весело, но больно).

Итак, нам каким-то образом ответили на наш вопрос, зачем же мы мигрируем. Мы с вами отвечаем:
- “Сделаем, без проблем”.
Вопрос, который нам задают в ответ:
-”Сколько же понадобится времени на миграцию?”
Теперь мы начинаем смотреть, а сколько у нас занято места на сервере.
(Я не буду углубляться настолько подробно, вплоть до подключения к серверу через 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 на виртуальном машине хватит с головой, но если у вас огромный Enterprise сервер с кучей модулей и надстроек над 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

Настраиваем частоту выполнения и сохраняем изменения.

Вот и всё, всем спасибо за внимание, это моя первая статья, не судите строго!