Не работает restore php битрикс

Битрикс, 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

Всем привет, такая проблема. Есть бэкап сайта, нужно его как-то восстановить.

50мб) в корень сайта
2. Туда же положил битрикосвый restore.php
3. Запускаю restore.php, жму далее, потом выбираю «Архив загружен в корневую папку сервера» и выбираю там единственный мой бэкап. Жму далее
4. Вижу ошибку:
«Доступны не все части многотомного архива.
Общее число частей: 4″

Цитата
Лежат все четыре части архива

Сергей Хренасдва
Полностью с вами согласен.

Уже третий рабочий день пытаюсь разобраться как это «чудо инженерной мысли» работает.

Дико бесит что нельзя удалять бэкапы из Облака, собственно такое облако нахрен не надо. Чем это мотивировано тоже неясно, не хочу что бы у вас хранились какие-то наши данные. на вышіх же форумах всплывала информация «Резервные копии удаляются из облака автоматически при создании новых или по истечении месяца. » там валяются бэкапы за 2014 год, КАРЛ!

Восстановление бэкапа это вообще какой-то бред.
На текущей системе бэкап делался

на только что развернутой чистой, Cent OS обновленной и установленой через ваш баш-скрипт.
Бэкап чистой ситемы завис на 50% после 10 минут и так и не сделался, (ничего не настраивалось ничего не менялось)
Может был какой глюк, но такое повсюду, то работает, то не работает.

Перенести бэкап с одного сервера на другой вообще ад какой-то.
Как вы представляете переносить 30 гигов, выбирая один из трех методов.
1. загрузить с облака
2. загрузить по прямой ссылке
3. загрузить с компьютера

При прямой ссылке можно только вставить одну, ну спасибо и в самом битриксе вы не рекомендуете создавать одним файлом бэкап (а по 100 мб, считайте сколько частей из 30Гб) и то если скормливать системе ссылку она ругается и уходит в редирект

что говорить, если у вас даже форум работает через пень колоду. (пока писал сообщение)

пробуя перехитрив систему, перекачал 30 гигабайт с одного сервера на другой и подложив в папке увидел в списке резервных копий, уже хорошо -подумал я но зря. восстанавливая таким образом оно потребовало пароль.. я не включал опцию шифрования данных но при физическом переносе требует пароль.
Какой пароль*? откуда, чьерт возьми!

ВСЕ СКАЧЕНО С ВАШЕГО САЙТА, НИКТО НИЧЕГО НЕ ЛОМАЛ В НАСТРОЙКАХ, ПРАВА ДОСТУПА ВЫСТАВЛЕНЫ ПРАВИЛЬНЫЕ/

Источник

Во время восстановление через 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 не может скачать бэкап с другого сервера

Есть виртуальная машина CentOS 6.2 c BitrixEnv 4.2. С другого сервера запускаю restore.php, указываю путь к файлу бэкапа и выдает ошибку

Запрашиваю файл http://хххххххххххххх.ru/bitrix/backup/2013-12-26.04-00-02.f8d41110.tar.gz
Подключение к серверу хххххххххххххх.ru.
Не могу соединиться с ххххххххххххх.ru: [110] Connection timed out

Если заменить имя сайта на его IP, то файл качается нормально. Если ссылку вставить в браузер, то файл скачивается.

Какие именно настройки нужно поменять на машине?

Цитата
Евгения Юменова пишет: С другого сервера запускаю restore.php

Цитата
Евгения Юменова пишет: Есть виртуальная машина CentOS 6.2 c BitrixEnv 4.2

у Вас стоит локально
то такое поведение предсказуемо. хосты виртуалкибудут видны только на локальном ПК и в локальной сети (если это настроено) из интернета доступа к ней не будет (опять же, если не настроено такого). поэтому ваш браузер видит оба сайта. а удалённый сайт не видит локальный.

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

Делаем это не только из-за бэкапов, есть другой скрипт, который выдает тоже самое, а он ежедневный. Помогите.

Ранее этот же сайт стоял на другой машине с Debian и там все работало.

Цитата
Если заменить имя сайта на его IP, то файл качается нормально. Если ссылку вставить в браузер, то файл скачивается.

Не исключено, что проблема с разрешением (resolving) доменного имени. Например, DNS сервер не успевает ответить до момента таймаута. Проверить это достаточно просто: на сервере, где наблюдается проблема, напрямую привяжите домен к IP адресу в файле /etc/hosts, выполнив команду от пользователя root:

Где xxx.xxx.xxx.xxx — IP адрес удаленного хоста (сайта), domain.name — доменное имя (сайта).

После этого попробуйте снова запросить файл, используя доменное имя. Если не получится, значит причина в чем-то другом. Если получится — станет понятней как искать и решать проблему.

Источник