ошибка время работы скрипта восстановления истекло загрузите новую версию
Всем привет, такая проблема. Есть бэкап сайта, нужно его как-то восстановить.
50мб) в корень сайта
2. Туда же положил битрикосвый restore.php
3. Запускаю restore.php, жму далее, потом выбираю «Архив загружен в корневую папку сервера» и выбираю там единственный мой бэкап. Жму далее
4. Вижу ошибку:
«Доступны не все части многотомного архива.
Общее число частей: 4″
Сергей Хренасдва
Полностью с вами согласен.
Уже третий рабочий день пытаюсь разобраться как это «чудо инженерной мысли» работает.
Восстановление бэкапа это вообще какой-то бред.
На текущей системе бэкап делался
на только что развернутой чистой, Cent OS обновленной и установленой через ваш баш-скрипт.
Бэкап чистой ситемы завис на 50% после 10 минут и так и не сделался, (ничего не настраивалось ничего не менялось)
Может был какой глюк, но такое повсюду, то работает, то не работает.
Перенести бэкап с одного сервера на другой вообще ад какой-то.
Как вы представляете переносить 30 гигов, выбирая один из трех методов.
1. загрузить с облака
2. загрузить по прямой ссылке
3. загрузить с компьютера
При прямой ссылке можно только вставить одну, ну спасибо и в самом битриксе вы не рекомендуете создавать одним файлом бэкап (а по 100 мб, считайте сколько частей из 30Гб) и то если скормливать системе ссылку она ругается и уходит в редирект
что говорить, если у вас даже форум работает через пень колоду. (пока писал сообщение)
ВСЕ СКАЧЕНО С ВАШЕГО САЙТА, НИКТО НИЧЕГО НЕ ЛОМАЛ В НАСТРОЙКАХ, ПРАВА ДОСТУПА ВЫСТАВЛЕНЫ ПРАВИЛЬНЫЕ/
Во время восстановление через restore.php выадет ошибку.
Запускаю восстановление бэкапа, но после скачивания архива и во время распаковки выдает ошибку:
Can’t create file: /var/www/tesk/data/www/tesk.pro/18a5ace48a8c.html
Права на папку сайта установил в 777, я даже cделал права на файл restore.php в 777, но все равно не помогает.
Нужна срочная помощь.
места на диске хватает, вот данные хостинга
Память (ОЗУ) 47% от 1400 МБ
Люди, мне срочно нужна помощь, рабочий сайт лежит, заказчик рвет и мечет, а я даже идей ни каких не имею в каком направлении копать.
Отзовитесь кто нибудь, буду очень благодарен за любое предположение, даже самое невероятное!
C бекапом все нормально, сайт локально поднялся без проблем, но на хостинге ни чего не получается.
Цитата |
---|
Сергей Емельянов написал: Заходите по ssh, вытаскивайте БД, создайте параллельно ещё одну БД, распакуйте туда бэкап, переключите сайт на новую БД. |
Этот вариант я рассматриваю на самый крайний случай, если вообще ни чего не получится.
Can’t create file: /var/www/tesk/data/www/tesk.pro/images/sale.png
Цитата |
---|
Настройка прав на сервере хостинг-провайдера может быть индивидуальна, но прежде всего должны быть установлены права на чтение/запись из скрипта для пользователя, под которым запущен веб-сервер Apache. |
Тема конечно устарела, но поиск прислал меня сюда и навел на правильные мысли.
Так что добавлю, что подобная проблема скорей не в правах доступа как таковых, а в том, что файл создан или получил нового владельца. Причиной такого события может быть то, что какие-то скрипты выполняются из CRON’а причем от имени пользователя, отличного от того, под которым запущен Апач с Битриксом.
Если говорить и типовом случае, когда Битрикс работает под Bitrix VM с CentOS, то все файлы Битрикс имеют и должны иметь владельца/группу «bitrix», если по каким-то причинам владелец/группа поменялись, то их можно восстановить командой в SSH консоли:
Во время восстановление через restore.php выадет ошибку.
Запускаю восстановление бэкапа, но после скачивания архива и во время распаковки выдает ошибку:
Can’t create file: /var/www/tesk/data/www/tesk.pro/18a5ace48a8c.html
Права на папку сайта установил в 777, я даже cделал права на файл restore.php в 777, но все равно не помогает.
Нужна срочная помощь.
места на диске хватает, вот данные хостинга
Память (ОЗУ) 47% от 1400 МБ
Люди, мне срочно нужна помощь, рабочий сайт лежит, заказчик рвет и мечет, а я даже идей ни каких не имею в каком направлении копать.
Отзовитесь кто нибудь, буду очень благодарен за любое предположение, даже самое невероятное!
C бекапом все нормально, сайт локально поднялся без проблем, но на хостинге ни чего не получается.
Цитата |
---|
Сергей Емельянов написал: Заходите по ssh, вытаскивайте БД, создайте параллельно ещё одну БД, распакуйте туда бэкап, переключите сайт на новую БД. |
Этот вариант я рассматриваю на самый крайний случай, если вообще ни чего не получится.
Can’t create file: /var/www/tesk/data/www/tesk.pro/images/sale.png
Цитата |
---|
Настройка прав на сервере хостинг-провайдера может быть индивидуальна, но прежде всего должны быть установлены права на чтение/запись из скрипта для пользователя, под которым запущен веб-сервер Apache. |
Тема конечно устарела, но поиск прислал меня сюда и навел на правильные мысли.
Так что добавлю, что подобная проблема скорей не в правах доступа как таковых, а в том, что файл создан или получил нового владельца. Причиной такого события может быть то, что какие-то скрипты выполняются из CRON’а причем от имени пользователя, отличного от того, под которым запущен Апач с Битриксом.
Если говорить и типовом случае, когда Битрикс работает под Bitrix VM с CentOS, то все файлы Битрикс имеют и должны иметь владельца/группу «bitrix», если по каким-то причинам владелец/группа поменялись, то их можно восстановить командой в SSH консоли:
Где на сайте битрикса скачать свежий 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
Мы понимаем, что это неудобно и просим извинить за это. В самом ближайшем обновлении ошибка будет исправлена.
Но сейчас обойти проблему очень просто: надо в этот файл в начало дописать код:
файлы резервный копий имеют название
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
VMBitrix 7.3.0 в релизе
где можно установить номер порта для сайта?
в документации не нашел
Цитата |
---|
Роман Семёнов написал: а ТП уверяла что bitrix поддерживает другие порты |
хорошо если порты работают
В конфигах сайта поменять на нужные порты, и всё будет работать.
Цитата |
---|
red_eye написал: В конфигах сайта поменять на нужные порты, и всё будет работать. |
кхм, а это для кого написали?
Никакой путаницы нет. В образе версия 7.3.0 о чем на сайте написано. В релизе последняя версия пакета 7.3.4. В планах с версии 7.4.0 собирать образы на каждую следующую версию.
Цитата |
---|
Руслан Яцукевич написал: Запускаю восстановление из бэкапа. Ошибка! Время работы скрипта восстановления истекло. Загрузите новую версию. |
Подскажите, как повторить? Кидаю свой бекап и такого не вижу.
Вы про какие костыли?
PS: по пакету percona-releases фикс сделали, вышел в статусе BETA в версии 7.3.13. В релиз уйдет в 7.4.0. Образ будет новый. Но! те машины, что уже с такой проблемой, починить можно только руками увы(
Прав в том, что решение не работает в полной мере, сотрудники знают об этом и не отзывают релиз.
Выпустить обновленный релиз, в котором нет указанных мной проблем не сильно дольше (а для профи быстрее), чем писать отговорки на форуме.
В компании не выстроен процесс управления релизами vmbitrix.
Администрирование не равно поиск костылей. В былые времена, VMbitrix работал из коробки и не требовал особого администрирования, за что и был в почете.
Цитата |
---|
Денис Диденко написал: а отвечать за действия третьих лиц Битрикс точно не может |
Цитата |
---|
Денис Диденко написал: а отвечать за действия третьих лиц Битрикс точно не может |
Вы конечно извините, но это нелепая отмазка. Баги (3х лиц РНР) как то обходят, исправляют и, даже, как то получается. А тут резко «не получается, не хочется, не можется» (нужное подчеркнуть). Особенно, учитывая, что исправление проблемы довольно простое для вендора.