Битрикс, PHP 7 и restore.php
Если вы еще не восстанавливали/переносили Битрикс на свеженький (или не очень) сервер с PHP 7, то вы счастливый человек. Нет, сам Битрикс на PHP 7 работает более чем хорошо, я бы даже сказал, что намного лучше, чем на 5.X.
Т.е. все прекрасно, кроме самого процесса переноса. Если вы воспользуетесь официальным инструментом от Битрикса – скриптом restore.php, то столкнетесь с проблемами. Собственно, как только дело дойдет до восстановления базы данных – сервер упадает в 500 ошибку, а в логах появится следующая запись:
Т.е. в скрипте по прежнему используется старая библиотекой php для работы с MySQL, вместо mysqli – уже как несколько лет обозначенной, как единственно верное и поддерживаемое решение.
А в PHP 7 больше нет поддержки старой библиотеки для mysql, это известно всем, кроме тех людей которые занимаются скрипом восстановления (я уверен, что им уже сказали, но пока они раскачаются…).
Решение тут понятно простое – восстановить базу руками, что, понятно, несложно. Нет один, два раза без проблем, но на десятый уже конечно надоедает.
Собственно решение тут одно, взять и поправить код скрипта, благо правок так немного. Что и было сделано:
- Убран код, который скачивает свежую версию скрипта с Битрикса и подменяет текущий файл;
- Собственно все старые не поддерживаемые функции заменены на аналоги из mysqli
Как только в Битрикс выпустят свою нормальную версию – ссылку заменю на официальный продукт.
Upd: Вышел официальный restore.php с поддержкой mysqli.
Читайте также
В CentOS 7+ и RH 7+ сервисы (в их числе и нужный нам httpd) теперь…
Если вы установили Битрикс в кодировке UTF-8 и собираетесь использовать mPDF для генерации pdf-документов, то…
В начале этого года Битрикс выпустили новую, седьмую, версию своего «Веб-окружения». Самое главное — теперь…
Источник
Ошибка restore.php
1. Скопировал в корень сайта резервную копию сайта созданную БУС
2. Скопировал туда же restore.php
3. Запустил /restore.php
Fatal error: Unable to read 24118 bytes in /home/. путь . /restore.php on line 0
БУС устанавливается без проблем.
Хостинг Majordomo.ru
а что делать, если данная ошибка возникает не на удаленном хостинге, а на локальном и файл заливался не по ftp, а посредством копирования файла из одной папки в другую,
| Цитата |
|---|
| Михаил Митрофанов пишет: Добрый день, |
Описание ошибки и способы её решения приведены ниже:
http://www.1c-bitrix.ru/support/faq/f. 2382#25237
| Цитата |
|---|
| Дмитрий Попов пишет: а что делать, если данная ошибка возникает не на удаленном хостинге, а на локальном и файл заливался не по ftp, а посредством копирования файла из одной папки в другую, |
Михаил Митрофанов пишет:
Добрый день,
Описание ошибки и способы её решения приведены ниже:
http://www.1c-bitrix.ru/support/faq/f. 2382#25237
Господа, эта ссылка не работает, о ОЧЕНЬ хотелось бы посмотреть, как решается проблема с этой ошибкой!
| Цитата |
|---|
| Alexey Erokhin пишет: Господа, эта ссылка не работает, о ОЧЕНЬ хотелось бы посмотреть, как решается проблема с этой ошибкой! |
Fatal error: Unable to read 26374 bytes in /usr/home/eucenter/domains/eu-center.ru/public_html/restore.php on line 0
Спасибо, Михаил.
Ссылка помогла Теперь ошибка не выдается, а сайт просто не запускается. Т.е. index.php в корне оставляет пустой экран и надпись «Готово» в строке состояния браузера.
Системщики хостинга разбираются, в чем проблема.
Если подобная ситуация встречалась, поделитесь секретом, плиз.
В любом случае спасибо.
Источник
Во время восстановление через restore.php выадет ошибку.
Запускаю восстановление бэкапа, но после скачивания архива и во время распаковки выдает ошибку:
Can’t create file: /var/www/tesk/data/www/tesk.pro/18a5ace48a8c.html
Права на папку сайта установил в 777, я даже cделал права на файл restore.php в 777, но все равно не помогает.
Что с этим делать?
Нужна срочная помощь.
места на диске хватает, вот данные хостинга
Память (ОЗУ) 47% от 1400 МБ
Диск 56% от 30 ГБ
Люди, мне срочно нужна помощь, рабочий сайт лежит, заказчик рвет и мечет, а я даже идей ни каких не имею в каком направлении копать.
Отзовитесь кто нибудь, буду очень благодарен за любое предположение, даже самое невероятное!
Вам нужно вытащить из архива БД и восстановить её.
Пытаясь в панике восстанавливать из, возможно, битого бэкапа, вы можете убить ещё и сам сайт.
База лежит в архиве. Не стоит восстанавливать весь архив.
Заходите по ssh, вытаскивайте БД, создайте параллельно ещё одну БД, распакуйте туда бэкап, переключите сайт на новую БД.
Если все плохо-плохо — быстро возвращаете все обратно и думаете дальше, что делать.
| Цитата |
|---|
| Сергей Емельянов написал: Пытаясь в панике восстанавливать из, возможно, битого бэкапа, вы можете убить ещё и сам сайт. |
C бекапом все нормально, сайт локально поднялся без проблем, но на хостинге ни чего не получается.
| Цитата |
|---|
| Сергей Емельянов написал: Заходите по ssh, вытаскивайте БД, создайте параллельно ещё одну БД, распакуйте туда бэкап, переключите сайт на новую БД. |
Этот вариант я рассматриваю на самый крайний случай, если вообще ни чего не получится.
| Цитата |
|---|
| Денис Сон написал: Возможно, что-то нужно временно подправить в .htaccess чтобы не перенаправляло на https. |
убрал все настройки из .htaccess , которые перенаправляют на протокол https, теперь восстановление бекапа идет через протокол http, но ошибка во время распаковки архива не куда не исчезла:
Can’t create file: /var/www/tesk/data/www/tesk.pro/images/sale.png
| Цитата |
|---|
| Настройка прав на сервере хостинг-провайдера может быть индивидуальна, но прежде всего должны быть установлены права на чтение/запись из скрипта для пользователя, под которым запущен веб-сервер Apache. |
Тема конечно устарела, но поиск прислал меня сюда и навел на правильные мысли.
Так что добавлю, что подобная проблема скорей не в правах доступа как таковых, а в том, что файл создан или получил нового владельца. Причиной такого события может быть то, что какие-то скрипты выполняются из CRON’а причем от имени пользователя, отличного от того, под которым запущен Апач с Битриксом.
Если говорить и типовом случае, когда Битрикс работает под Bitrix VM с CentOS, то все файлы Битрикс имеют и должны иметь владельца/группу «bitrix», если по каким-то причинам владелец/группа поменялись, то их можно восстановить командой в SSH консоли:
Источник
Восстановление бэкапа — restore.php
Всем привет, такая проблема. Есть бэкап сайта, нужно его как-то восстановить.
50мб) в корень сайта
2. Туда же положил битрикосвый restore.php
3. Запускаю restore.php, жму далее, потом выбираю «Архив загружен в корневую папку сервера» и выбираю там единственный мой бэкап. Жму далее
4. Вижу ошибку:
«Доступны не все части многотомного архива.
Общее число частей: 4″
| Цитата |
|---|
| Лежат все четыре части архива |
Сергей Хренасдва
Полностью с вами согласен.
Уже третий рабочий день пытаюсь разобраться как это «чудо инженерной мысли» работает.
Дико бесит что нельзя удалять бэкапы из Облака, собственно такое облако нахрен не надо. Чем это мотивировано тоже неясно, не хочу что бы у вас хранились какие-то наши данные. на вышіх же форумах всплывала информация «Резервные копии удаляются из облака автоматически при создании новых или по истечении месяца. » там валяются бэкапы за 2014 год, КАРЛ!
Восстановление бэкапа это вообще какой-то бред.
На текущей системе бэкап делался
на только что развернутой чистой, Cent OS обновленной и установленой через ваш баш-скрипт.
Бэкап чистой ситемы завис на 50% после 10 минут и так и не сделался, (ничего не настраивалось ничего не менялось)
Может был какой глюк, но такое повсюду, то работает, то не работает.
Перенести бэкап с одного сервера на другой вообще ад какой-то.
Как вы представляете переносить 30 гигов, выбирая один из трех методов.
1. загрузить с облака
2. загрузить по прямой ссылке
3. загрузить с компьютера
При прямой ссылке можно только вставить одну, ну спасибо и в самом битриксе вы не рекомендуете создавать одним файлом бэкап (а по 100 мб, считайте сколько частей из 30Гб) и то если скормливать системе ссылку она ругается и уходит в редирект
что говорить, если у вас даже форум работает через пень колоду. (пока писал сообщение)
пробуя перехитрив систему, перекачал 30 гигабайт с одного сервера на другой и подложив в папке увидел в списке резервных копий, уже хорошо -подумал я но зря. восстанавливая таким образом оно потребовало пароль.. я не включал опцию шифрования данных но при физическом переносе требует пароль.
Какой пароль*? откуда, чьерт возьми!
ВСЕ СКАЧЕНО С ВАШЕГО САЙТА, НИКТО НИЧЕГО НЕ ЛОМАЛ В НАСТРОЙКАХ, ПРАВА ДОСТУПА ВЫСТАВЛЕНЫ ПРАВИЛЬНЫЕ/
Источник
Где на сайте битрикса скачать свежий restore.php
ссылка на файл тут
ваш_сайт/bitrix/admin/dump_list.php?lang=ru
сам файл тут
ваш_сайт/bitrix/admin/dump_list.php?action=restore.php&sessid=id_сессии
сюда топайте Рабочий стол -> Настройки -> Инструменты -> Резервное копирование -> Список резервных копий
Скрипт restore.php обновляется автоматически, для верности можете скачать его напрямую с нашего сайта: http://www.1c-bitrix.ru/download/scripts/restore.php
Что касается ошибки восстановления .settings.php, мы знаем о ней и уже исправили. Обновление restore её не решит, т.к. неправильный файл .settings.php попадал в архив резервной копии.
Мы понимаем, что это неудобно и просим извинить за это. В самом ближайшем обновлении ошибка будет исправлена.
Но сейчас обойти проблему очень просто: надо в этот файл в начало дописать код:
подскажите пожалуйста а для старых версий Корпоративный портал «совместная работа»
это restore.php актуален ? или надо искать старую версию
резервная копия создавалась еще в 2014-м году в июле
файлы резервный копий имеют название
20140723_114415_full_6d933620.tar.gz размер 13,7 МБ
20140723_114415_full_6d933620.tar.gz.1 размер 92,6 МБ
20140723_114415_full_6d933620.tar.gz.2 размер 82,6 МБ
20140723_114415_full_6d933620.tar.gz.3 размер 91,2 МБ
20140723_114415_full_6d933620.tar.gz.4 размер 63,1 МБ
20140723_114415_full_6d933620.tar.gz.5 размер 3,24 МБ
еще подозреваю что они могут быть битыми так как размеры файлов разные
При запаковке архива берётся кусок того объёма, которое соответствует ограничению в настройках резервного копирования (например 900мб или 100мб), а потом сжимается. Поэтому если у вас ограничение маленькое, то вы можете получить несколько файлов разного объёма (после сжатия-то размеры одного исходного размера могут получиться архивами разного размера, смотря как сжать получится).
после запуска restore.php
указал с локального диска файлы
дальше начиная с 0 валятся ошибки
Archive is corrupted, wrong block: 28678
Archive is corrupted, wrong block: 28679
Источник