Перейти к содержимому
BXWiki

Восстановление из копии не проходит - причины по убыванию частоты

Скрипт восстановления обрывается на распаковке, отдаёт пятисотую ошибку на шаге базы или доходит до конца, а сайт после этого не открывается. Разбираем причины по убыванию частоты, начиная с прав и свободного места.

С чего начать

Смотрим, дошло ли дело до распаковки:

Окно терминала
ls -A /home/bitrix/www/ | head        # появились ли каталоги bitrix и upload
ls -lh /home/bitrix/www/*.tar.gz*     # части архива на месте и нужного размера
df -h /home/bitrix                    # места нужно втрое больше размера копии
df -i /home/bitrix                    # и запас по числу файлов на разделе
tail -40 /var/log/php-fpm/error.log   # текст отказа, которого нет в браузере

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

Считаем части архива и проверяем их целостность:

Окно терминала
ls -1 /home/bitrix/www/*.tar.gz* | wc -l            # столько частей доехало на сервер
tar -tzf /home/bitrix/www/backup.tar.gz | wc -l     # первая часть читается целиком
md5sum /home/bitrix/www/*.tar.gz*                   # суммы сверяем с исходным сервером

Мастер называет общее число частей и останавливается, пока не найдёт их все. Недокачанная часть чаще всего отличается размером от соседних, а битая не проходит проверку суммой.

Проверяем права на запись в корень сайта:

Окно терминала
stat -c '%U:%G %a' /home/bitrix/www /home/bitrix/www/restore.php
chown bitrix:bitrix /home/bitrix/www/restore.php   # владелец - пользователь веб-сервера
chown bitrix:bitrix /home/bitrix/www/*.tar.gz*     # части архива тоже читает он
sudo -u bitrix touch /home/bitrix/www/.probe && echo 'запись есть'

Сообщение «Не могу записать файл» рядом с десятком свободных гигабайтов означает именно права, а не диск. Скрипт работает от пользователя веб-сервера, и владелец корня обязан совпадать с ним.

Сверяем окружение нового сервера с требованиями продукта:

Окно терминала
php -v && php -m | grep -E 'mysqli|mbstring|zip|gd'
php -r 'var_dump(ini_get("mbstring.func_overload"));'   # допустимо только 0
ls /etc/php.d/*.ini.disabled 2>/dev/null                # модули после обновления окружения

Полнее тот же ответ даёт штатный скрипт проверки сервера, который кладут рядом с восстановлением. Обновление окружения переименовывает файлы подключения модулей, и расширение пропадает молча.

Проверяем доступ к базе до шага восстановления:

Окно терминала
mysql -h localhost -u siteuser -p -e 'SELECT VERSION();'
mysql -e "CREATE DATABASE sitedb CHARACTER SET utf8mb4;"   # мастеру нужны права на создание
mysql -e "SHOW GRANTS FOR 'siteuser'@'localhost';"         # хватает ли прав на импорт дампа
grep -A 6 "'connections'" /home/bitrix/www/bitrix/.settings.php | grep -E 'host|database'

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

Причины

  1. Не хватает прав на запись или места на диске примерно 30% случаев

    ПризнакСкрипт сообщает о невозможности записать файл и тут же показывает свободные гигабайты.

    ПроверкаСмотрим владельца корня сайта и самого скрипта, а следом свободное место на разделе.

    Что делатьОтдаём корень и скрипт пользователю веб-сервера и освобождаем места втрое больше размера копии.

  2. Доехали не все части многотомного архива примерно 22% случаев

    ПризнакМастер пишет о недоступных частях архива и называет их общее число.

    ПроверкаСверяем число файлов частей в корне сайта с числом, которое называет сам мастер.

    Что делатьДокачиваем недостающие части и грузим многотомный архив партиями по девять-десять файлов.

  3. Реквизиты базы не подходят новому серверу примерно 18% случаев

    ПризнакФайлы распакованы, а шаг восстановления базы отдаёт отказ доступа или пятисотую ошибку.

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

    Что делатьСоздаём пустую базу заранее и вводим в мастере реквизиты нового сервера, а не прежнего.

  4. На новом сервере другая версия PHP или набор расширений примерно 15% случаев

    ПризнакБелый экран при запуске скрипта либо ошибка о неизвестной функции сразу после разворота.

    ПроверкаСравниваем версию языка и список расширений с требованиями продукта штатной проверкой сервера.

    Что делатьДоставляем недостающие расширения, возвращаем отключённые модули и обнуляем перегрузку строковых функций.

  5. Распаковка не укладывается в память или время примерно 10% случаев

    ПризнакРазворот падает с сообщением об исчерпанной памяти либо соединение обрывается на середине.

    ПроверкаСмотрим предел памяти процесса и размер одной части архива резервной копии.

    Что делатьПоднимаем пределы на время разворота, а копию пересобираем частями поменьше и без кэша.

  6. Многосайтовая копия поднимает только первый сайт примерно 5% случаев

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

    ПроверкаИщем файлы прочих сайтов в каталоге резервных копий и сверяем пути корней в настройках.

    Что делатьПереносим каталоги остальных сайтов руками и пересоздаём символические ссылки на ядро платформы.

Частые вопросы

Не разворачивается бэкап через restore.php, соединение сбрасывается.

Архив слишком велик для одного прохода. Копию пересобирают без кэша, загрузок и прежних архивов, а свободное место на приёмнике проверяют заранее.

Белый экран при запуске restore.php, ничего не происходит.

Скрипт либо не подходит версии PHP на сервере, либо не может записать файл. Помогает свежая версия скрипта и правка прав на корень сайта.

Можно ли распаковать архив копии обычным архиватором?

Штатно нет: копии платформы лежат в формате GNU tar и разворачиваются скриптом восстановления. Ручная распаковка сторонним инструментом - обычная причина неполного разворота.

Как подключить базу данных к восстановленному сайту?

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

При загрузке архива приходит «413 Request Entity Too Large».

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

Смежное

Первоисточник