Nextcloud резервное копирование файлов
После установки Nextcloud им можно сразу же пользоваться. (А если вы здесь по вопросу отключения техобслуживания Nextcloud, то вот команда — sudo -u www-data php /path/to/nextcloud/occ maintenance:mode —off (перед off ставьте два дефиса) )
Но, если вам хочется большей производительности, а также не хочется видеть предупреждение о текущей конфигурации, которое будет видно каждый раз при заходе в административную панель, то следующие советы для вас.
Как и ранее я писал, Nextcloud стоит на Ubuntu 18.04 и работает под связкой nginx + php-fpm (версии 7.4) + mysql. Язык интерфейса — русский. Nextcloud установлен в /usr/share/nginx/nextcloud/
После внесения изменений не забываем перезапускать php-fpm. Или можете после применения всех изменений перезапустить его один раз.
Содержание:
Убираем предупреждение о 4-х байтовых символах
MySQL используется в качестве базы данных, но не поддерживает 4-байтовые символы.
Чтобы иметь возможность обрабатывать 4-байтовые символы (например, смайлики) без проблем в именах файлов или комментариях, рекомендуется включить 4-байтовую поддержку в MySQL. Для получения более подробной информации обратитесь к документации.
Так как первоначально Nextcloud я ставил на базе MariaDB, то по ссылке выше для возможности обработки ошибки я не заметил продолжение про MariaDB, а сразу стал применять шаги для MySQL. Не надо так. Поэтому распишу по шагам, что и как надо делать.
P.S. Убедитесь, что MariaDB версии выше 10.2. У меня была версия 15.1
Убедитесь, что на вашем сервере MySQL установлены следующие параметры InnoDB в файле:
и если их нет, то вставьте в конец файла.
Перезапустите сервер MariaDB
Выясните был ли изменён формат файла на Barracuda
Если формат файла — «barracuda» для каждой отдельной таблицы, то ничего особенного не остается делать. Продолжайте с инструкциями для MySQL. Во время тестирования формат файла всех таблиц был “Antelope”.
Таблицы должны быть перенесены в “barracuda” вручную, одна за другой. Однако команды SQL можно легко создавать:
Скопируйте появившийся ответ и уберите в нем символ «|». После этого вставляйте текст в консоль mariadb
После всего проделанного формат файла должен поменяться на Barracuda. Проверим.
Инструкции для MySQL
Вводим в режим обслуживания.
Должен быть такой результат
Отключаем режим обслуживания.
Конфигурируем балансировщик
В качестве примера я приведу простой в базовой конфигурации и эффективный nginx. Да, различные дополнительные failover-плюшки у него доступны только в платной версии, но даже в базовом варианте он отлично выполняет свою задачу. Учтите, что балансировка типа round robin или random нам не подходит, так как application-сервера хранят кеши для конкретных клиентов.
К счастью, это решается использованием метода ip_hash. В таком случае сессии пользователя будут закреплены за конкретным бэкендом, к которому будут направляться все запросы со стороны пользователя. Этот момент описан в документации:
Задаёт для группы метод балансировки нагрузки, при котором запросы распределяются по серверам на основе IP-адресов клиентов. В качестве ключа для хэширования используются первые три октета IPv4-адреса клиента или IPv6-адрес клиента целиком. Метод гарантирует, что запросы одного и того же клиента будут всегда передаваться на один и тот же сервер. Если же этот сервер будет считаться недоступным, то запросы этого клиента будут передаваться на другой сервер. С большой долей вероятности это также будет один и тот же сервер.
К сожалению, при использовании этого метода могут быть проблемы с пользователями, которые находятся за динамическим IP и постоянно его меняют. Например, на клиентах с мобильным интернетом, которых может кидать по разным маршрутам при переключении между сотами. sticky cookie, который решает эту проблему доступен только в платной версии.
В конфигурационном файле nginx это описывается следующим образом:
В этом случае нагрузка будет по возможности равномерно распределяться между application-cерверами, хотя из-за привязки клиента к конкретной сессии могут возникать перекосы нагрузки. Для небольших и средних инсталляций этим можно пренебречь. Если у вас бэкенды разные по мощности, то можно задать вес каждого из них. Тогда балансировщик будет стараться распределять нагрузку пропорционально заданным весам:
В приведенном примере из 5 пришедших запросов 3 уйдут на backend1, 1 на backend2 и 1 на backend3.
В случае, если один из application-серверов откажет, nginx попробует переадресовать запрос следующему серверу из списка бэкендов.
Конфигурирование SSL/TLS
Однозначно стоит рассчитывать на TLS 1.3, если вы делаете новую инсталляцию и нет проблем с пакетами nginx, которые зависят от свежести системного openssl. В частности, 0-RTT и другие плюшки позволяют временами ощутимо ускорить повторное подключение клиентов за счет кеширования. Безопасность также выше за счет выпиливания устаревших протоколов.
Приведу актуальный конфиг для nginx application-сервера, который находится общается с балансировщиком по TLS:
Убираем предупреждение о кешировании.
Не настроена система кеширования
Для увеличения производительности сервера, по возможности, настройте memcache. Более подробная информация доступна в документации
Поэтому прикручиваем систему кэширования, состоящую из локальной системы кэширования на основе APCu и системы распределённого кеширования Redis.
Деплоим Application ноды
Есть несколько вариантов деплоя:
- snap
- docker-image
- ручное обновление
Да, там есть каналы подписки, а мажорные релизы, по идее он не должен переключать, но все же подумайте. Я бы рекомендовал полный контроль за процессом обновления, тем более, что нередко он сопровождается изменением структуры данных в БД.
Docker-image — хороший вариант, особенно, если у вас часть инфраструктуры крутится уже на Kubernetes. Та же нода Redis, скорее всего уедет в кластер следом за application-серверами.
Если у вас нет инфраструктуры для этого, то ручное обновление и развертывание из tar.gz вполне удобно и контролируемо.
Не забудьте, что на application-сервера вам потребуется установить веб-сервер для обработки входящих запросов. Я бы рекомендовал связку из nginx + php-fpm7.4. С последними версиями php-fmp ощутимо выросло быстродействие и отзывчивость.
Environment
- VERBOSE=1 выводим ошибки на экран сразу (stdout).
- SAVELOGSONSUCCES=1 сохраняем лог при успехе.
- INIT_REPO_IF_NOT_EXIST=1 Создаем репозиторий, если его не было. По-умолчанию выключено.
- TIMEOUT максимальное вермя на основную операцию. You can set it as 'm', 'h' or 'd' at the end.
Режим храниения старых копий. По-умолчанию:
- KEEP_DAILY=7
- KEEP_WEEKLY=4
- KEEP_MONTHLY=6
Как это работает
На бэкапируемой ноде запускается раннер с башевским экзекьютером. По планировщику в специальной репе запускается job CI/CD. Раннер запускает скрипт универсальную обертку для таких задач, в нем проходят проверки валидности репозитория бэкапа, точек монтирования и всего что захотим, затем выполняется бэкапирование и очистка старого. Сам готовый бэкап отправляется на S3.
Мы работаем по такой схеме — это внешний провайдер AWS или российский аналог (это быстрее и данные не покидают РФ). Либо клиенту ставим отдельный minio кластер на его площадке для этих целей. Обычно так делаем по соображениям безопасности, когда клиент совсем не хочет чтобы данные покидали их контур.
Пользоваться фичей отправки бэкапа по ssh мы не стали. Безопасности это не добавляет, а сетевые возможности провайдера S3 сильно выше одной нашей ssh машины.
Для того чтобы обезопасить от хакера на локальной машине — ведь он может стереть данные на S3, обязательно нужно включить версионирование.
бэкапер всегда шифрует бэкап.
У Borg есть режим без шифрования none , но мы категорически не рекомендуем его включать. В этом режиме не будет не только шифрования, но не вычисляется контрольная сумма того что записывается, а значит целостность проверить можно только косвенно, по индексам.
По отдельному шедулеру производится проверка бэкапов на целостность индексов и содержимого. Проверка происходит медленно и долго, поэтому мы запускаем ее отдельно раз в месяц. Может идти несколько суток.
Удобный плагин Nextcloud WebDAV — Windows и Linux интерфейсы
Строим архитектуру
К сожалению, в последних версиях документация по корпоративному внедрению Nextcloud доступна только для владельцев платной подписки. Впрочем, в качестве референса можно взять более старые мануалы, которые до сих пор в открытом доступе.
Типовой вариант для домашнего использования и единичных инсталляций.
Вариант «все в одном» неплох до тех пор, пока у вас немного пользователей, а вы можете себе позволить простой на время регламентных работ. Например, во время обновления. Также у монолитной схемы, с размещением на одной ноде есть проблемы с масштабированием. Поэтому, мы попробуем второй вариант.
Масштабируемый вариант деплоя, рекомендованный для более высоких нагрузок.
Основные компоненты системы:
- 1 Балансировщик. Можете взять HAproxy или Nginx. Я рассмотрю вариант с Nginx.
- 2-4 штуки Application server (web-server). Сама инсталляция Nextcloud с основным кодом на php.
- 2 БД. В стандартной рекомендованной конфигурации это MariaDB.
- NFS-хранилище.
- Redis для кеширования запросов к БД
Restic vs Borg
Сравнения Borg и Restic есть в том числе здесь на Хабре, и у нас не было задачи сделать просто еще одно, но своё. Нам было важно как это будет выглядить на наших данных, с нашей спецификой. Мы их приводим.
Наши критерии выбора, помимо уже упоминавшихся (дедупликация, быстрое восстановление и пр.):
- Устойчивость к незавершенной работе. Проверка на kill -9.
- Размер на диске.
- Требовательность к ресурсам (ЦПУ, память).
- Размер хранимых блобов.
- Работа с S3.
- Проверка целостности.
Для тестирования мы взяли одного клиента с реальными данными и общим размером 1,6Тб.
Условия.
Borg не умеет напрямую работать с S3, и мы монтировали как fuse диск, через goofys. Restic отправлял в S3 сам.
Goofys работает очень быстро и хорошо, и к нему есть модуль дискового кеша, что еще больше ускоряет работу. Он находится в стадии beta, и, признаться, у нас падал с потерей данных на тестах (других). Но удобство в том, что сама процедура бэкапа не требует большого чтения, а в основном запись, поэтому кеш мы используем только во время проверки целостности.
Чтобы снизить влияние сети, использовали местного провайдера — Яндекс Облако.
Результаты тестирования сравнения.
- Kill -9 с дальнейшим перезапуском оба прошли успешно.
- Размер на диске. Borg умеет сжимать поэтому результаты ожидаемые.
- По CPU
Сам по себе borg расходует мало, с дефолтным сжатием, но оценивать надо вместе с процессом goofys. В сумме они сравнимы и утилизируют около 1,2 ядра на одной и той же тестовой виртуалке. - Память. Restic приблизительно 0,5Гб, Borg около 200Мб. Но это все незначительно в сравнении с файловым кешем системы. Так что памяти желательно выделять побольше.
- Разница в размере блобов оказалась разительной.
Backuper | Размер |
---|---|
Borg | около 500Мб |
Restic | около 5Мб |
- Работа с S3 от Restic отличная. Работа Borg через goofys вопросов не вызывает, но замечено, что желательно по окончании бэкапа делать umount чтобы полностью сбросить кеш. Особенность работы S3 в том, что недокачанные чанки никогда не будут отправлены в бакет, а значит не полностью залитые данные приводят к большим повреждениям.
- Проверка целостности работает хорошо в обоих случаях, но скорость отличается значительно.
Restic – 3,5 часа.
Borg, с файловым кешем в 100Гб SSD – 5 часов.Приблизительно такой же результат по скорости если данные лежат на локальном диске.
Borg читает прямо с S3 без кеша 33 часа. Чудовищно долго.
В сухом остатке Borg умеет сжимать и имеет бОльшие блобы — что делает более дешевым хранение и операции GET/PUT в S3. Но за это приходится платить более сложной и медленной проверкой. Что касается скорости восстановления — то мы разницы не заметили. Последующие бэкапы (после первого) restic делает несколько дольше, но не существенно.
Не на последнем месте в выборе стоял размер коммьюнити.
И мы выбрали borg.
Настройка обратного прокси для доступа
Для примера IP обратного прокси — 192.168.0.1, IP Nextcloud-сервера — 192.168.0.2
В файле nextcloud/config/config.php
Таким образом, опция trusted_proxies исправляет проблему «Заголовки обратного прокси настроены неправильно, либо вы подключены к серверу Nextcloud через доверенный прокси«
Для этого добавьте в файл конфигурации nginx на стороне nextcloud следующее содержимое в секцию server
Веб-сервер не настроен должным образом для разрешения «/.well-known/caldav». .
Дополнительная информация может быть найдена в нашей документации
В конфиге nextcloud в статье есть строки с настройкой доступа к этому пути. Для удобства повторю тут
Регион размещения сервера
Не указан регион размещения этого сервера Nextcloud, что требуется для возможности проверки номеров телефонов без указания кода страны.
Чтобы разрешить пользователям сервера указывать номера телефонов без указания кода страны, добавьте параметр «default_phone_region» с соответствующим кодом страны в соответствии с ISO 3166-1↗.
Опять же после обновления до 21 версии Nextcloud появляется такое предупреждение. Точную причину почему в Nextcloud понадобилось указывать номер телефона я не знаю, но как устранить это предупреждение — знаю.
Открывает файл config.php, расположенный в директории Nextcloud по пути config/config.php и внизу вставляем строку
Не знаю для чего вообще понадилось разработчикам из Nextcloud вставлять в код такое требование (а это требование, потому что иначе бы не было предупреждения на странице проверки конфигурации), но пока обновляться до 21 версии не стоит. Хотя, возможно, это из-за многочисленных требований регуляторов многих стран, в государственных учреждениях которых используется Nextcloud. Всё может быть. Со временем такое категоричное непринятие 21 версии у меня пропадёт. 🙂
Сегодня я хочу рассказать о нашем опыте автоматизации резервного копирования больших данных хранилищ Nextcloud в разных конфигурациях. Я работаю СТО в «Молния АК», где мы занимаемся конфигурационным управлением IT систем, для хранения данных используется Nextcloud. В том числе, с распределенной структурой, с резервированием.
Проблемы вытекающие из особенностей инсталляций в том, что данных много. Версионирование которое дает Nextcloud, резервирование, субъективные причины, и другое создает много дублей.
Управление созданием резервных копий
Borg и Restic хороши, но ни тот ни другой продукт не имеет централизованного механизма управления. Для цели управления и контроля мы выбрали инструмент который и так у нас внедрен, без которого мы не мыслим свою работу, в том числе по автоматизации — это известный CI/CD – GitLab.
Идея состоит в следующем: на каждую ноду хранящую данные Nextcloud ставится gitlab-runner. Раннер запускает по расписанию скрипт следящий за процессом бэкапирования, и тот запускает Borg или Restic.
Что мы получили? Обратную связь от выполнения, удобный контроль за изменениями, подробности в случае ошибки.
Вот здесь на GitHub мы выложили примеры скрипта для разных задач, а мы его в итоге прикрутили к бэкапу не только Nextcloud, но и многих других сервисов. Там же лежит планировщик, если неохота руками его настраивать (а нам неохота) и .gitlab-ci.yml
В API гитлаба пока нет возможности менять таймаут CI/CD, а он там небольшой. Его надо увеличить, скажем до 1d .
GitLab к счастью умеет запускать не только по коммиту, но только по расписанию, это ровно то что нам надо.
Теперь о скритпе-обертке.
Мы поставили такие условия для этого скрипта:
Полный лог сохраняется в виде артефакта в GitLab, если ошибки нет, то лог удаляется. Скрипт пишем на bash.
Любые предложения и замечания по опенсорсу будем рады рассмотреть — welcome.
Копирование и восстановление из Nextcloud — преимущества Handy Backup
Handy Backup Standard
Handy Backup Standard позволяет использовать интерфейс Nextcloud WebDAV для резервного копирования, восстановления и синхронизации данных. Бесплатный полнофункциональный пробный период - 30 дней!
Регламентное обслуживание
Не забудьте, что в промышленном окружении требуется обеспечить минимальный и нулевой простой сервиса при обновлении или тем более резервном копировании. Ключевая сложность тут — зависимость состояния метаданных в БД и самих файлов, которые доступны через NFS или объектное хранилище.
При обновлении application-серверов на новую минорную версию особых проблем не возникает. Но кластер все равно надо переводить в mainenance mode для обновления структуры БД.
Выключаем балансировщик в момент наименьшей нагрузки и приступаем к обновлению.
После этого выполняем на нем процесс ручного обновления из скачанного tar.gz, с сохранением конфигурационного файла config.php. Обновление через веб на крупных инсталляциях — очень плохая идея!
Выполняем обновление через командную строку:
После этого включаем балансировщик и подаем трафик на обновленный сервер. Для этого выводим все необновленные application-сервера из балансировки:
Остальные ноды постепенно обновляем и вводим в строй. При этом occ upgrade уже выполнять не нужно! Нужно только заменить php-файлы и сохранить конфигурацию.
При резервном копировании нужно останавливать репликацию на Slave и выполнять одновременный дамп метаданных из БД одновременно с созданием снапшота файлов в хранилище. Хранить их нужно попарно. Восстановление аналогично должно происходить из дампа БД и файлов за один и тот же период. В противном случае возможны потери данных, так как файл может лежать в хранилище, но не иметь метаданных в БД.
Список наиболее полезных и используемых мной программ nextcloud. Конечно, нижеперечисленные приложения — это некоторые из многих приложений, доступных для Nextcloud. Существует множество других, которые могут еще больше расширить функционал облака.
External sites
Внешние сайты – даёт возможность создать ссылки на необходимые сайты в различных местах
- заголовок – главное верхнее меню пользователя
- меню настроек – выпадающее меню пользователя в правом верхнем углу пользователя
- квота пользователя –
- публичный нижний колонтитул – в низу окна на страница авторизации nextcloud, где необходимо ввести логин и пароль
можно настроить показ ссылок на определённых устройствах:
- все устройства
- только в приложении для Android
- только в приложении для iOS
- только на клиенте для настольных устройств
- только в браузере
есть возможность настроить открытие ссылки в новой вкладке или в окне nextcloud (frame), показ определённым группам и иконку ссылки
Checksum
Контрольная сумма — позволяет вычислять и просматривать контрольные суммы файлов. МОжно выбрать следующие алгоритмы: md5, sha1, sha256, sha384, sha512, crc32
File Access Control
Контроль доступа к файлам – позволяет настраивать доступ к файлам и каталогам пользователей на основе тэгов и созданных вами правил.
Deck
Колода – позволяет создавать карточки для задач и упорядочивать их. Также вы можете делать заметки, для задач. При командном использовании есть возможность комментирования задач для обсуждения.
News
AppOrder
Порядок приложений – позволяет каждому пользователю nextcloud расположить значки приложений в любом удобном порядке. С помощью этого приложения, администратор nextcloud может определить макет по умолчанию для значков.
Passwords
Пароли – менеджер паролей включающий в себя монитор безопасности паролей, безопасное шифрование, папки и теги для структурирования паролей. Есть возможность поделиться паролями с другими пользователями Nextcloud.
OnlyOffice
это пакет онлайн-офиса, без которого, файлы документов не будут открываться в облаке.. Вы получаете текстовый процессор, электронную таблицу и приложение для презентаций, все в вашем личном облаке. В nextcloud существует два варианта: Collabora и OnlyOffice. Для работы обоих вариантов необходимо устанавливать плагин и настраивать сервер офиса
Calendar
Календарь – приложение позволяет вести календари в облаке. делиться с пользователями облака.
Talk
Разговор – позволяет совершать защищенные аудио и видеозвонки через веб-интерфейс или мобильное приложение Nextcloud Talk. Для связи используется WebRTC.
Impersonate
позволяет администратору пользоваться nexcloud от имени другого пользователя.
Brute-force settings
защита от подбора паролей к учётным данным
End-to-End Encryption – включает сквозное шифрование на клиенте.
Копирование на Nextcloud - удобная и функциональная возможность бэкапа данных с использованием открытой облачной архитектуры Nextcloud WebDAV. Облачные сервисы Nextcloud стабильны, легко управляются и предоставляют большой набор функций хранения. Handy Backup осуществляет бэкап Nextcloud через плагин WebDAV.
Попробовать бесплатно
Версия 8.3.5 от 6 мая 2022. 111 MB
30-дневный полнофункциональный пробный период
Модуль php-imagick и SVG
Модуль php-imagick в этом случае не поддерживает SVG.
Для лучшей совместимости рекомендуется установить его
В русском переводе на 2021.03.25 фраза переведена немного неправильно. В оригинале это выглядит как «Module php-imagick in this instance has no SVG support. For better compatibility it is recommended to install it.» — «У модуля php-imagick на этом сервере отсутствует поддержка формата SVG. Для лучшей совместимости рекомендуется установить его»
Конфигурируем БД
Подробно Master-Slave конфигурацию можно посмотреть в основной документации.
Разберем несколько ключевых моментов. Для начала создаем пользователя для репликации данных:
Затем правим конфиг мастера:
В районе блока «Logging and Replication» вносим нужные правки:
На Slave конфигурируем конфиг:
В районе блока «Logging and Replication» вносим нужные правки:
Перезапускаем оба сервера:
Далее надо будет скопировать БД на Slave.
На Master выполняем для начала выполняем блокировку таблиц:
А затем смотрим статус:
Не выходим из консоли БД, иначе блокировки снимутся!
Нам понадобится отсюда master_log_file и master_log_pos для конфигурации Slave.
Делаем дамп и снимаем блокировки:
Затем на Slave импортируем дамп и рестартуем демон:
После этого в консоли настраиваем репликацию:
Запускаем и проверяем:
В ответе не должно быть ошибок и два пункта укажут на успешность процедуры:
Балансировщик
В данной архитектуре у вас будет меньше точек отказа. Основная точка отказа — это балансировщик нагрузки. В случае его недоступности пользователи не смогут достучаться до сервиса. К счастью, его конфигурация того же nginx довольно проста, как мы рассмотрим дальше, а нагрузку он держит без особых проблем. Большинство аварий на балансировщике решается рестартом демона, всей ноды целиком или развертыванием из бэкапа. Не будет лишним иметь настроенный холодный резерв в другой локации с ручным переключением трафика на него в DNS.
Переменные внутри скрипта
- ERROR_STRING — string for the check in log for error.
- EXTRACT_ERROR_STRING — expression for show string if error.
- KILL_TIMEOUT_SIGNAL — signal for killing if timeout.
- TAIL — how many strings with errors on screen.
- COLORMSG — color of mesage (default yellow).
Тот скрипт, который называется wordpress носит название условно, его фишка в том, что он еще бэкапит базу mysql. А значит может применяться для однонодовых установок Nexcloud, где можно заодно и забэкапить базу. Удобство не только в том, что все в одном месте, но и содержимое базы близко к содержимому файлов, так как разница во времени минимальна.
Пару слов о сжатии
У Borg’а есть в арсенале прекрасный новый алгоритм сжатия — zstd. По качеству сжатия не хуже gzip, но значительно быстрее. И сравним по скорости с дефотным lz4.
Например дамп MySQL базы сжимается раза в два лучше lz4 при той же скорости. Однако, опыт на реальных данных показывает, что очень небольшую разницу в степени сжатия ноды Nextcloud .
В Borg есть довольно бонусный режим сжатия — если файл имеет большую энтропию, то сжатие не применяется вообще, что увеличивает скорость работы. Включается опцией при создании
-C auto,zstd
для алгоритма zstd
Так вот с этой опцией в сравнении со сжатием по-умолчанию мы получили
560Gb и 562Gb соответственно. Данные из примера выше, напомню, без сжатия результат 628Gb. Результат в 2Гб разницы несколько нас удививший, но мы посчитали что выберем все-таки auto,zstd .
Ставим APCu
В файле php.ini включаем apcu
вставив в начало
Сохраняем файл и перезапускаем php-fpm.
Редактируем файл config/config.php в директории установки Nextсloud
и вставляем следующую строку перед закрывающем скобкой «);»
Новый dashboard
Следующая опция для тех, кто обновился до 20 версии и при заходе на главную облака видит новый dashboard вместо знакомого списка файлов.
Исправляется просто добавлением в файл config.php следующей строки
Убираем ошибку отсутствия индексов
В базе данных отсутствуют некоторые индексы.
Так как создание таких индексов может занять достаточно продолжительное время, оно должно быть запущено вручную. Для создания индексов необходимо запустить команду «occ db:add-missing-indices» во время работы сервера Nextcloud. При созданных индексах, как правило, запросы к базе данных выполняются значительно быстрее.
При успешном индексировании будет следующий текст:
Некоторые индексы базы данных не были преобразованы в тип big int.
Так как преобразование таких индексов может занять продолжительное время, оно должно быть запущенно вручную. Чтобы выполнить преобразование, необходимо включить режим обслуживания и запустить в терминале команду «occ db:convert-filecache-bigint». Дополнительные сведения приведены на соответствующей странице документации.
Вводим сервер в режим обслуживания и выполняем преобразование
И выводим из режима обслуживания
Режим шифрования
Задействован устаревший режим шифрования файлов на стороне сервера.
Рекомендуется отключить такое шифрование. Более подробные сведения содержатся в документации.
Как я понял, устаревший режим шифрования был введён в ранних версиях Nextcloud и впоследствии заменён на новый. Однако в хранилище могли остаться файлы со старым (legacy) типом шифрования.
В документации сказано, что найти эти файлы можно командой
или более полный вариант
В процессе сканирования occ начнёт искать файлы со старым типом шифрования или если в базе такие файлы отсутствуют, выдаст предупреждение, «does not have a proper header«.
Такие файлы я просто заменил копиями тех, у кого есть нужные заголовки. Так как таких файлов у меня просто не было.
После этого в файле config.php можно отключить поддержку устаревшего формата шифрования, удалив строку
или, выставив значение false вместо true
С самими файлами в хранилище ничего не произойдёт, они так же будут зашифрованы как и раньше. В данном случае, мы просто отключили поддержку старого режима шифрования.
Убираем предупреждение о php
Разрешённое максимальное значение использования памяти PHP ниже рекомендуемого значения в 512 МБ.
Ищем memory_limit и вводим, например, 512M вместо 128M. И перезапускаем php-fpm
или если хотим побыстрее
Убираем первое предупреждение:
«PHP не настроен правильно для получения переменных системного окружения.
Запрос getenv(«PATH») возвращает пустые результаты.
Обратитесь к разделу о конфигурации PHP и примечаниям к конфигурации
PHP из руководства по установке. Обратите внимание на настройку
параметров PHP, особенно при использовании механизма php-fpm.»
Как сказано в документации
Когда вы используете php-fpm, системные переменные среды, такие как PATH, TMP или другие, не заполняются автоматически так же, как при использовании php-cli. Вызов функции PHP, такой как getenv(‘PATH’); может возвращать пустой результат. Поэтому вам может потребоваться вручную настроить переменные среды в файле конфигурации php-fpm.
Ищем такие строки:
И раскомментируем их.
Или, если побыстрее
Не забываем перезапустить php-fpm
Готово. Идём дальше.
Убираем второе предупреждение
«PHP OPcache не настроен правильно»
Для обеспечения лучшей производительности рекомендуется задать в файле php.ini следующие параметры настроек:
opcache.enable=1
opcache.enable_cli=1
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=10000
opcache.memory_consumption=128
opcache.save_comments=1
opcache.revalidate_freq=1
Заменим вручную вышеуказанные параметры в файле /etc/php/7.4/fpm/php.ini или сразу заменим значения sed’ом
Что нужно компаниям?
Главное отличие сервиса на уютном домашнем сервера собранного из желудей и спичек от корпоративного сегмента — ответственность перед пользователями. Впрочем, даже в своей домашней инсталляции я считаю хорошим тоном делать рассылку пользователям с предупреждением о плановой работе или потенциальной аварии. Ведь именно вечером в субботу ваш друг может внезапно решить поработать с данными, которые он у вас хостит.
В случае же компании, даже небольшой, любой простой важного сервиса — это потенциальные убытки и проблемы. Особенно, если на сервис завязано много процессов.
В частности, по моему опыту, в Nextcloud востребовано несколько функций среди небольших компаний:
- Предоставление доступов к общим каталогам и синхронизация.
- Киллер-фича с предоставлением доступа вовне в рамках федерации. Можно интегрироваться с аналогичным продуктом у коллег и другой компании.
- Предоставление доступов вовне по прямой ссылке. Очень помогает, если вы, например, работаете в полиграфии и надо обмениваться с клиентами большими объемами тяжелых данных.
- Редактор документов Collabora, который выполняется на стороне сервера и работает как фронтенд к LibreOffice.
- Чаты и видеозвонки. Немного спорная, не совсем стабильная функция, но она есть и работает. В последней версии ее уже стабилизировали.
Быстрая и надёжная работа программы
Копирование и восстановление облаков Nextcloud контролируется в стандартном графическом интерфейсе, через который задачи создаются пользователем в простом и продвинутом режиме, контролируется ход выполнения, автоматически составляются отчёты о резервном копировании, запускаются пропущенные задачи и т. д.
Рекомендуемое решение
2700 ₽ за лицензию
Как создать задачу бэкапа на Nextcloud?
С помощью данной инструкции вы сможете быстро создать задачу резервного копирования на Nextcloud:
- Откройте Handy Backup и нажмите кнопку "Создать" на панели или клавиши Ctrl+N.
- Выберите задачу резервного копирования на Шаге 1.
- На Шаге 2 выберите данные для бэкапа на Nextcloud.
- Перейдите к Шагу 3 и выберите плагин WebDAV слева в списке хранилищ. Нажмите по строчке "Создать подключение. ". Откроется окно диалога.
- Введите параметры подключения:
- Имя подключения: выберите имя для вашего соединения с Nextcloud.
- Имя сервера: имя конкретного сервера Nextcloud, который вы используете.
- Порт: обычно следует сохранить значение 443 для соединения через SSL.
- Пользователь: ваш логин от Nextcloud.
- Пароль: ваш пароль для доступа к серверу.
- Нажмите ОК. Выберите в открывшемся списке ваше новое подключение.
- Выберите папку или создайте новую, в которой вы поместите резервную копию на Nextcloud.
- Нажмите ОК, затем нажмите "Далее". Продолжайте создавать задачу. За подробностями вы можете обратиться к Руководству пользователя.
- На последнем шаге дайте имя вашей задаче - например, Nextcloud backup.
Задача создана и готова к работе! Теперь осуществление резервного копирования на Nextcloud будет осуществляться при каждом ручном запуске или в указанное время/по системному сбытию, если соответствующий режим был выбран на шаге "Задать расписание".
Ставим Redis.
Проверяем, что он запустился
В тот же файл config/config.php
вставьте следующее опять перед закрывающей скобкой «);»
Сохраняем файл. Перезапускаем php-fpm, если вы это ещё не сделали и наслаждаемся ускоренной работе Nextcloud.
то тогда пропишите в файл php.ini, который находится по пути /etc/php/7.4/cli следующий текст
Ошибка должна исчезнуть
Service functions
- cleanup записываем ошибки или стираем лог файл.
- checklog парсим лог на вхождение строки с ошибкой.
- ret exit handler.
- checktimeout проверка на таймаут.
Методика проверки бэкапа
По планировщику запускается виртуалка прямо у провайдера или у клиента, что сильно снижает сетевую нагрузку. Как минимум это дешевле, чем поднимать у себя и гонять трафик.
По этой же схеме мы проверяем файлы антивирусом (постфактум). Ведь пользователи заливают разное в Nextcloud и не у всех есть антивирус. Проводить проверку в момент заливки занимает слишком много времени, и мешает бизнесу.
Масштабируемость достигается запуском раннеров на разных нодах с разными тегами.
В нашем мониторинге собираются статусы бэкапов через API GitLab в одном окне, при необходимости проблемы легко замечаются, и так же легко локализуются.
Восстановление из Nextcloud
Восстановление копии из Nextcloud также выполняется с помощью задачи восстановления в Handy Backup.
- Вызовите мастер новых задач, выберите на Шаге 1 задачу восстановления данных.
- На Шаге 2 выберите плагин WebDAV и щелкните по нему.
- В открывшемся диалоговом окне выберите соединение с Nextcloud или создайте новое подключение.
- В облаке Nextcloud выберите папку с бэкапом и выделите файл backup.hbi.
Для бэкапов, хранящихся на Nextcloud, можно настроить восстановление в другое место. Чтобы изменить место восстановления для резервной копии, на Шаге 1 отметьте галочку "Продвинутый режим", далее на Шаге 3 нажмите "Изменить место" и выберите новое хранилище.
-
Закончив создание задачи Nextcloud восстановления, дайте ей подходящее имя на последнем шаге, например, Nextcloud restore.
Обратите внимание! Handy Backup хранит незашифрованные данные в исходном формате. Поэтому вы можете работать с данными из копии на Nextcloud в привычном режиме, то есть открывать, редактировать, удалять без восстановления.
Попробовать бесплатно
Версия 8.3.5 от 6 мая 2022. 111 MB
30-дневный полнофункциональный пробный период
Программа Handy Backup предоставляет эффективные инструменты для резервного копирования на Nextcloud. Попробуйте её в действии, скачав 30-дневную пробную версию программы бесплатно!
Резервное копирование на Nextcloud по расписанию
С Handy Backup легко настроить автоматический бэкап Nextcloud по расписанию с заданным интервалом повторения от нескольких минут до месяцев. Также в продвинутом режиме можно настроить выполнение задачи по системному событию.
Убираем третье предупреждение
Некоторые индексы базы данных не были преобразованы в тип big int
Так как преобразование таких индексов может занять продолжительное время, оно должно быть запущенно вручную. Чтобы выполнить преобразование, необходимо включить режим обслуживания и запустить в терминале команду «occ db:convert-filecache-bigint». Дополнительные сведения приведены на соответствующей странице документации.filecache.mtime
filecache.storage_mtime
Для того, чтобы не потерять данные, или чтобы не было ошибок на клиентах, или просто для спокойствия нервной системы введите Nextcloud в режим обслуживания.
В браузере вы можете увидеть, что система находится в режиме обслуживания. Теперь в консоли выполните следующее:
Затем выключите режим обслуживания.
Заключение
Как итог мы точно знаем что бэкапы мы делаем, что наши бэкапы валидные, проблемы которые с ними возникают занимают мало времени и решаются на уровне дежурного администратора. Бэкапы занимают реально мало места в сравнении с tar.gz или Bacula.
Есть очень крутой комбайн для совместного ведения проектов, LDAP-авторизацией, синхронизацией файлов с версионированием и чем-то вроде корпоративного мессенджера с видеоконференциями, которые прикрутили в последних версиях. Да, я про Nextcloud. С одной стороны, я сторонник Unix-way и четкого дробления приложений по отдельным функциям. С другой — этот продукт более чем устойчив, работает много лет в нескольких проектах без особых проблем и дополнительные свистелки особо не мешают ему работать. Если очень хочется, то туда можно прикрутить практически любую дичь. Коммьюнити живое и вполне допиливает различные плагины, которые доступны как отдельные приложения.
Сегодня мы будем его разворачивать. Я не буду давать полной пошаговой инструкции, но постараюсь упомянуть про ключевые моменты архитектуры, на которые стоит обратить внимание. В частности, разберем балансировку нагрузки, репликацию БД и регламентное обслуживание без прерывания сервиса.
Деплоить будем в отказоустойчивом варианте для небольшой компании в 150-1000 пользователей, но для домашних пользователей тоже пригодится.
Предыстория
При администрировании Nextcloud остро встает проблема организации эффективного бэкапа который нужно обязательно шифровать, так как данные ценны.
Мы предлагаем варианты хранения бэкапа у нас или у заказчика на его отдельных от Nextcloud машинах, что требует гибкого автоматизированного подхода к администрированию.
Клиентов много, все они с разными конфигурациями, и все на своих площадках и со своими особенностями. Тут стандартная методика когда вся площадка принадлежит тебе, и бэкапы делаются из крона подходит плохо.
Для начала посмотрим на вводные данные. Нам нужно:
- Масштабируемость в плане одна нода или несколько. Для крупных исталляций мы используем в качестве хранилища minio.
- Узнавать о проблемах с выполнением бэкапа.
- Нужно хранить бэкап у клиентов и/или у нас.
- Быстро и легко разбираться с проблемами.
- Клиенты и установки сильно отличаются один от другого — единообразия добиться не получается.
- Скорость восстановления должна быть минимальна по двум сценариям: полное восстановление (дизастер), одна папка — стерто по ошибке.
- Обязательна функция дедупликации.
Для решения задачи управления бекапами мы прикрутили GitLab. Подробнее подкатом.
Безусловно, мы не первые кто решает подобную задачу, но нам кажется что наш практический выстраданный опыт может быть интересным и мы готовы им поделиться.
Поскольку в нашей компании принята политика opensource, решение мы искали именно с открытым исходным кодом. В свою очередь мы делимся своими разработками, и выкладываем их. Например, на GitHub есть наш плагин для Nextcloud, который мы ставим клиентам, усиливающий сохранность данных на случай случайного или преднамеренного удаления.
Storage
Любое оптимальное для вас решение, которое предоставляет NFS-протокол. В случае высоких нагрузок можно рассмотреть IBM Elastic Storage или Ceph. Также возможно использование S3-совместимого объектного хранилища, но это скорее вариант для особо крупных инсталляций.
Ридми на русском
HDD или SSD
В принципе, для средних по размеру инсталляций вполне достаточно использования только HDD. Узким участком тут будут iops при чтении из БД, что сильно сказывается на отзывчивости системы, но, при наличии Redis, который кеширует все в RAM, это не будет особой проблемой. Так же часть кеша будет лежать в memcached на application-серверах. Тем не менее, я бы рекомендовал, по возможности, размещать application-сервера на SSD. Веб-интерфейс становится намного отзывчивее по ощущениям. При этом та же синхронизация файлов на десктопных клиентах будет работать примерно так же, как и при использовании HDD для этих узлов.
Скорость синхронизации и отдачи файлов будет определяться уже производительностью вашего NFS-хранилища.
Основные функции
- prepare подготовка
- testcheck проверка готовности
- maincommand основная команда
- forcepostscript функция которая выполняется вконце или по ошибке. Используем чтобы отмонтировать раздел.
Средства бэкапирования
Поиск методов решения мы начали с выбора средства создания бэкапа.
Обычный tar + gzip работает плохо — данные дублируются. Инкремент часто содержит очень мало изменений по факту, и большая часть данных внутри одного файла повторяется.
Есть еще одна проблема — избыточность распределенного хранилища данных. Мы используем minio и его данные в принципе избыточны. Либо нужно было бэкап делать через сам minio – нагружать его и пользоваться всеми прокладками между файловой системой, и что не менее важно, есть риск забыть про часть бакетов и мета-информации. Либо использовать дедупликацию.
Средства бэкапирования с дудпликацией есть в опенсорсе (на хабре были статьи на эту тему) и нашими финалистами стали Borg и Restic. О нашем сравнении двух приложений ниже, а пока расскажем как мы организовали всю схему.
База данных
Типовое решение — MySQL/MariaDB в кластерном исполнении в master-slave репликации. При этом у вас активна только одна БД, а вторая работает в режиме горячего резерва на случай аварийного отказа основной или при проведении плановых работ. Можно рассмотреть и вариант с балансировкой нагрузки, но она технически сложнее. При использовании MariaDB Galera Cluster с вариантом master-master репликации нужно использовать нечетное количество нод, но не менее трех. Таким образом минимизируется риск split-brain ситуаций, при рассечении связности между нодами.
Читайте также: