RISH 2.9.16: бэкап большого сайта при небольшом запасе места

Допустим, сайт занимает около 60 ГБ на диске объёмом 80 ГБ. Часть оставшегося пространства нужна системе, базам данных и журналам. Для ещё одной большой копии места может не оказаться.

Раньше RISH сначала создавал архив на сервере и только затем выгружал его в облако. Архив уже делился на небольшие части, но все они накапливались локально. Если свободное место заканчивалось, это могло нарушить работу баз данных и других служб сервера.

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

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

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

Перед созданием каждой части RISH проверяет свободное место с учётом заданного резерва. Если места мало, но его можно освободить выгрузкой очереди, архивация ждёт. Если очередь уже пуста, а места всё равно недостаточно, обработка объекта завершается с ошибкой.

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

Для потоковой архивации добавлены два новых параметра:

• backup_queue_mib — максимальный объём очереди частей на выгрузку. Когда очередь заполняется, создание следующих частей приостанавливается до освобождения места.
• backup_min_free_mib — резерв свободного места на диске, где находится временная папка бэкапов. Перед созданием каждой новой части RISH проверяет, достаточно ли места для неё с учётом этого резерва.

Размер самих частей по-прежнему задаётся параметром splitarchive. Значения по умолчанию:

Очередь не занимает весь лимит заранее. При небольшом запасе места RISH работает с меньшим количеством частей.

2 ГиБ — это резерв, который скрипт старается оставить свободным. Для начала записи части размером 500 МиБ требуется резерв плюс эта часть: 2548 МиБ, или примерно 2,5 ГиБ свободного места. Считать это достаточным запасом для любой нагрузки нельзя: базы данных, журналы и другие процессы тоже продолжают записывать данные.

Изменить параметры можно в разделе «Бэкапы» через пункт «Редактировать файл настроек». Они хранятся в /root/rish/rish_config.sh. Оба новых параметра задаются целыми числами в МиБ. Лимит очереди должен вмещать хотя бы одну часть: при splitarchive=500m значение backup_queue_mib должно быть не меньше 500.

Размер бэкапа может превышать 50 ГБ. Нумерация частей рассчитана и на большие архивы: после part-99 идут part-100, part-101 и далее. При стандартном размере части 500 МиБ сотня частей — это примерно 50 ГБ архива.

При скачивании и восстановлении RISH располагает части в числовом порядке и проверяет, что в последовательности нет пропусков. Архив может состоять более чем из сотни частей.

6 ноября 2026 года новый механизм проверили на двух тестовых сайтах с файлами размером 10 и 20 ГиБ. Файлы были заполнены случайными данными, которые практически не сжимаются: уменьшение размера архива не могло скрыть нехватку места.

Части по 500 МиБ появлялись в облаке ещё до окончания архивации. Для сайта с файлом 10 ГиБ выгрузилась 21 часть архива файлов, для сайта с файлом 20 ГиБ — 41 часть.

При периодических наблюдениях максимальный замеченный объём локальной очереди составил 1500 МиБ. Минимальное замеченное свободное место было около 2,05 ГиБ при заданном резерве 2 ГиБ. Это результаты конкретного прогона, а не общий предел расхода места.

Копию с файлом 10 ГиБ затем скачали и распаковали. SHA-256 файла, прочитанного из архива, и отдельно извлечённого файла совпали с SHA-256 исходного. Для копии с файлом 20 ГиБ подтверждено завершение выгрузки.

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

Мы провели тестирование, однако механизм создания резервных копий изменился. Поэтому важно проверить весь процесс на вашем сервере — от создания копии до её восстановления.

В RISH 2.9.16 появился пункт «Восстановить сайт из бэкапа потоком». Он скачивает части из облака по очереди, передаёт данные в распаковку и удаляет обработанные временные файлы. Собирать полный архив на сервере перед восстановлением не требуется.

Место по-прежнему нужно для самого восстанавливаемого сайта, очередной скачиваемой части и резерва. Перед началом RISH проверяет последовательность частей; во время работы показывает текущую часть и прогресс передачи. Незавершённые выгрузки скрываются в списке выбора. При восстановлении в другую учётную запись владельцем файлов становится пользователь назначения, а для импортированной базы ему выдаются права доступа.

Отдельный пункт «Скачать копию из бекапа на сервер» сохраняет полный архив локально — для него место под архив потребуется. Скачивание доступно и из раздела «Архивы и импорт БД». Исходные имена архива и соседнего дампа базы сохраняются, чтобы их можно было использовать вместе при восстановлении.

Потоковое восстановление записывает данные по мере чтения. Если операция оборвётся, результат может остаться частичным; перед запуском RISH предупреждает об этом.

Главное меню RISH существенно переработано. В этой серии обновлений завершён постепенный переход к разделам по задачам администратора. Новая структура разработана с учётом советов реальных пользователей RISH.

Действия с выбранным сайтом собраны в «Управлении сайтом», общие настройки и обслуживание служб — в «Управлении сервером». Меню стало логичнее, удобнее и интуитивно понятнее: назначение раздела подсказывает, где искать нужное действие.

Десять основных разделов меню F2 вызываются клавишами 1–9 и 0.

Из меню сайта доступны PHP, операции CMS и phpMyAdmin, сертификаты, DNS, Composer и права доступа. Состав пунктов зависит от конфигурации сайта и подключённых возможностей RISH. Меню понимает контекст сайта и при вызове из его подпапок; вне сайта предлагает создать новый с выбором пользователя. Установка CMS предлагается для пустого DocumentRoot.

Появился пункт «Очистить папку сайта»: он удаляет содержимое, включая скрытые файлы, и создаёт пустой DocumentRoot, сохраняя конфигурацию сайта и базу данных. Это отдельное действие с подтверждением.

В меню Apache видны состояние службы и действие остановки с подтверждением. После проверок и восстановления настроек RISH, а также проверок PHP, Apache и MariaDB управление возвращается в меню обновления с сохранением выбранного пункта. При прерывании операции или потере терминала меню завершается.

В «Управлении сервером» появился пункт «Удалить версию PHP». Перед удалением RISH проверяет использование выбранной версии сайтами, CRON, службами systemd, ссылками CLI и работающими процессами, а также зависимости пакетов.

Если обнаружено использование, выводятся причины отказа. Если проверка разрешает продолжить, администратор видит список пакетов выбранной версии Remi и отдельно подтверждает удаление. Исправлены и ложные запреты из-за штатных systemd-настроек Remi.

Проверка существующих PHP больше не считает установку незавершённой только из-за отличий php.ini от шаблона RISH. Настроить и запустить PHP-FPM можно с уже существующими конфигурациями; сверка базовых значений с шаблоном остаётся для новой установки.

В меню обновления RISH добавлены проверка и установка обновлений MariaDB в пределах установленной ветки: например, с одной версии 11.4.x на другую 11.4.y. Переход на другую ветку этим действием не выполняется.

Пакеты загружаются и проверяются до остановки служб. RISH сохраняет копии конфигураций, временно останавливает MariaDB и работающий Apache, устанавливает обновления, запускает MariaDB и проверяет SQL-подключение. Apache возвращается в работу после успешной проверки базы.

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

Если сайт открывается через одного оператора связи, но недоступен через другого при исправном сервере, причиной может быть сетевая фильтрация HTTPS-трафика. FirstVDS описывает похожую ситуацию и среди временных мер рекомендует отключить TLS 1.3 и оставить TLS 1.2.

В «Управлении сервером» появился раздел «Управление TLS». Для выбранного сайта или подходящей группы сайтов можно установить режим «только TLS 1.2», а затем вернуть штатные настройки.

Режим TLS 1.2 сохраняет шифрование HTTPS и может помочь восстановить доступ при подобных сбоях. После переключения проверьте доступность сайта из той сети, где возникла проблема.

Перед применением RISH сохраняет конфигурации и проверяет Apache. После изменения выполняется проверка синтаксиса и перечитывание настроек; при ошибке предусмотрено восстановление исходных файлов. Служебные виртуальные хосты не меняются, а изменение базового HTTPS-vhost, способное повлиять на соседние сайты, блокируется.

В разделе firewall появился белый список доверенных IPv4, IPv6 и подсетей. Его можно редактировать с комментариями или добавить текущий SSH-IP отдельным пунктом.

Доверенные адреса исключаются из анализа активных IP, экспорта и блокировок RISH. Если такой адрес уже заблокирован внутри подсети, RISH освобождает его, сохраняя блокировку остальных адресов и сроки временных правил. Белый список не открывает дополнительные порты.

Добавлен режим временного ограничения новых входящих подключений ко всему серверу. Исключения — текущий SSH-IP и адреса белого списка; уже установленные соединения сохраняются. Можно выбрать 15 минут, час, сутки или ручное снятие. Перезагрузка сервера или правил firewall снимает этот временный режим. Пока он активен, RISH не позволяет случайно сбросить его действием, требующим перечитывания сохранённых правил.

В таблице активных IP появилась колонка со статусом блокировки.

Резервные копии CRON, появившиеся ранее, теперь можно восстановить из меню — как обычные, так и зашифрованные. RISH показывает задания из архива и текущий crontab выбранного пользователя. Можно заменить текущие задания или добавить архивные в конец. Если crontab изменился после показа, операция останавливается для повторной проверки.

После ручного запуска CLI-команды Joomla показываются варианты её выполнения из CRON владельца сайта и от root. После смены PHP сайта диагностика помогает найти задания CRON с прежней явно указанной версией PHP и предлагает открыть их для редактирования. Автоматической замены команд нет.

Если Joomla уже обновлена до актуальной версии, повторный запуск обновления пропускается. При смене пароля MariaDB запись в configuration.php стала точнее: заменяется только значение пароля, остальные данные и формат файла сохраняются. Перед заменой проверяется, не изменился ли файл; сохраняются резервная копия, владелец и права.

Для переустановки той же версии phpMyAdmin требуется отдельное подтверждение, по умолчанию выбран выход. Установщик также напоминает о возможности использовать DBeaver Community на своём компьютере с подключением через SSH-туннель.

Проверки HTTP, IP и TLS получили ограничения времени ожидания: медленный или недоступный сайт больше не должен надолго задерживать весь обход. Улучшена проверка соответствия сертификата имени сайта, включая wildcard-сертификаты.

Помимо Joomla, в статистике определяются WordPress, MODX Revolution и Bitrix с их версиями. Поиск идёт в DocumentRoot Apache, в том числе когда он находится в подпапке сайта. Версии читаются из файлов без выполнения PHP-кода сайта.

• Меню бэкапов показывает включённые объекты, пользователя, тип копии, шифрование, исключения и отсутствующие папки. Выбранный в Midnight Commander сайт можно добавить в список с учётом его связи с базой данных.
• Ошибка одного объекта не блокирует ротацию остальных успешно обработанных объектов пользователя. Причины ошибок архивации, очереди и свободного места записываются в системный журнал с тегом rish-backup.
• В меню видны количество частей и прогресс передачи. Восстановление сайта расположено перед восстановлением папки.
• При установке и обновлении RISH проверяются правила ротации основных системных журналов и запуск logrotate по таймеру или CRON. Если пакетных правил нет, добавляются необходимые пакеты; некорректные или неполные пользовательские правила требуют исправления по диагностике.
• Для репозитория Cisco OpenH264 на EL9/10 добавлено резервное зеркало Яндекса с сохранением официального источника и пользовательских настроек.
• Предупреждения needs-restarting отделены от списка служб, которым нужен перезапуск. После обновления Apache отдельно сообщается, нужна ли перезагрузка сервера или определить это не удалось.
• В установщике ограничено ожидание настройки репозитория MariaDB. При удалении пользователя добавлены проверки домашнего каталога, его владельца, точек монтирования и вложенных домашних каталогов других пользователей.
• Уточнены подсказки при создании пользователя и подключении сервера для клонирования.

При длительной архивации большого работающего сайта его файлы могут успеть измениться. tar может вывести об этом предупреждение, а создание копии продолжится. Файлы и база данных в такой копии могут относиться к разным моментам времени.

После обновления проверьте настройки бэкапов, создайте тестовую копию и проверьте её восстановление.