TL;DR
Проблема решилась пересохранением настроек в админке на странице «Регулярное резервное копирование»
В админке стало периодически появляться сообщение вида:
По ссылке видны записи в логе:
Событие: Ошибка автоматического создания резервной копии
URL: /bitrix/tools/backup.php
Описание: [10] Secret key is incorrect
Проблема была в том, что настройки регулярного резервного копирования в облако были заданы до перевода сайта на HTTPS
И адрес в настройке «Метод запуска» = «через облачный сервис «1С-Битрикс»» был когда-то задан с указанием протокола HTTP
В итоге когда облачный сервис обращался к сайту пытаясь начать резервное копирование, используя устаревшую конфигурацию с HTTP,
передаваемые им параметры авторизации (‘Secret key’) терялись из-за того, что был настроен редирект в .htaccess с http на https
Проблема решилась пересохранением настроек
Ошибка выключенного регулярного резервного копирования
Ошибка выключенного регулярного резервного копирования
05.10.2015
В моей практике возникла похожая проблема рассмотренная ранее. Но тут у сайта, срок активности техподдержки и обновлений закончился, но регулярное резервное копирование работало без проблем. Буквально недавно выскочила ошибка «Ошибка автоматического создания резервной копии -Backup is disabled». На хостинге проверили PHP модуль Mcrypt подключен. При попытке выключить регулярное копирование выдает: Ошибка получения настроек от сервера (код: LICENSE_NOT_FOUND).
Проверяем настройки PHP, для сайта разработанного в кодировке utf-8:
mbstring.func_overload=2
mbstring.internal_encoding=utf-8
Как и предполагалось окончание активности лицензионного ключа влияет на эту проблему. Так как заказчик не захотел продлевать лицензию, придется выходить из ситуации другим способом.
В этом случае регулярное резервное копирование не будет работать через облачный сервис.
Нужно настраивать через прямой запуск скрипта /bitrix/modules/main/tools/backup.php на стороне хостера и добавить скрипт на cron.
Самое интересное, что мне нужно было просто выключить регулярное резервное копирование. Это должно делаться в независимости от активности лицензии. Почему нельзя выключить его без всяких велосипедов?
У клиента не должно возникать проблем с выключением регулярного копирования, независимо от того есть у него продление лицензии, или нет. С моей точки зрения это недоработка или продукта, или лицензирования. В лицензировании должно быть добавлено исключение позволяющее корректно выключить регулярное копирование при отсутствии продления активной лицензии.
Вопрос риторический, ответа на него конечно не последовало.
После создания сценария cron и его выполнения в назначенное мною время все, сработало. Резервное копирование выполнилось. После этого заходим в настройки и отключаем Автоматический запуск резервного копирования. Изменения сохранены. Автоматический запуск резервного копирования выключен.
Вид сценария для хостинга nic.ru:
Настройка сценария для хостинга nic.ru:
Ещё статьи:
12.05.2023
Битрикс убрал тип поля «Привязка к карте Яндекс»
В новых обновлениях Битрикс убрал тип поля «Привязка к карте Яндекс».
ID: 455
18.01.2023
Нюансы перехода битрикс на РНР 8.0
С февраля битрикс прекращает поддерживать РНР 7.4 и в битрикс сегменте сайтов начался переход на РНР 8 для получения обновлений.
Но без нюансов и ошибок…
ID: 431
10.01.2023
БУС окончательно всё?
Появилась информация от битрикс, что грубо говоря поддержка по отраслевому медицинскому решению от битрикс будет до 1 февраля 2024 года, а что потом б…
ID: 426
Новые статьи в блоге:
Возврат к списку
При создании резервной копии через стандартную возможность Битрикса файлы создаются. Копирую на локаль, запускаю restore.php и на каком то шаге получаю archive is corrupted. Нажимаю «пропустить», дохожу до перехода на сайт и получаю отсутствующий в корне index.php и практически пустую папку bitrix (только db_conf и папка backup). Что сделать, чтобы создавалась нормальная резервная копия? Ну или в какую сторону копать? Место на сервере есть.
-
Вопрос заданболее трёх лет назад
-
3380 просмотров
Ошибка резервного копирования 1С-Битрикс
ID статьи: 193
, создана 10 янв 2017
При создании резервной копии выдается ошибка:
Ошибка
Закончилось свободное место или нет прав на сервере на создание резервной копии
При этом на сервере достаточно свободного места и проверка прав доступа не находит ошибок.
Решение
В файле /bitrix/modules/main/classes/general/backup.php
замените строку:
$data = file_get_contents($file);
на
$data = "x1fx8bx08x00x00x00x00x00x00x03x00x00x00xffxffx03x00x00x00x00x00x00x00x00x00";
Появилась задача: «Разобраться с резервным копированием».
Сайт находится на shared хостинге spaceweb.
Что такое shared хостинг и с чем его едят?
Это самый дешевый вид хостинга для размещения простых вебсайтов. Загружаем по FTP исходные коды своего сайта и получаем доступ к общей СУБД MySQL. Никаких дополнительных функций обычно не предоставляется. Настройки сервера и ПО, наличие приложений и поддерживаемых языков программирования пользователь не контролирует. Один из недостатков – невозможность контролирования неполадок без обращения в техническую поддержку.
Альтернативой этому будут VPS (Virtual Private Server) и VDS (Virtual Dedicated Server). Это виртуальный выделенный сервер. Несколько виртуальных серверов работают на одной физической машине, но при этом пользователю выделяется гарантированное количество ресурсов, таких как объем постоянной и оперативной памяти, а также фиксированное количество ядер процессора. В этом случае пользователь имеет много возможностей по настройке и мониторингу, но он при этом должен обладать знаниями по настройке, либо нанимать сисадмина (мы, кстати, такое делаем).
Также есть Dedicated server (выделенный сервер, DS, дедик, dedic) – это целый компьютер – физическое устройство целиком от блока питания до сетевой карты. Пользователь является полноправным владельцем всей железяки и может делать с ней всё, что заблагорассудится.
Что-то пошло не так (ведь у нас же shared хостинг)
Напомню, что у нас, на сайте одного из клиентов возникла ошибка при создании резервной копии стандартными средствами CMS 1С-Битркис.
Автоматическое резервное копирование не может нормально завершиться и процесс переходит в состояние UNKNOWN буквально через 15-20 секунд.
А во время ручного резервного копирования с экрана просто пропадал индикатор прогресса — ни уведомлений об ошибках, ни об успешном завершении процесса, вообще ничего.
На shared хостинге sweb логи посмотреть невозможно, а за разъяснением причин приходится звонить или писать в ТП. Тут нет никаких претензий, трубку снимают быстро, на вопросы отвечают хорошо.
Специалист рассказывает, что после запуска процесса было превышение допустимой нагрузки и выполнение было прервано без суда и следствия. То есть, если какой-то процесс использует более 10% процессора более тридцати секунд, то он принудительно останавливается. Так же нас уверили, что пространство выделяется не динамически, и не должно быть проблем, связанных с свободным местом на сервере.
В 1С-Битрикс есть только 3 параметра, позволяющие ограничивать нагрузку на CPU:
- Отключить компрессию архива
- Длительность шага
- Интервал
С компрессией всё, вроде, очевидно: нет сжатия – нет нагрузки на процессор, но это не решало задачу. Длительность шага и интервал регулируют соотношение работы и простоя процессора при выполнении задачи. Настройка по умолчанию предлагает процессу 20 секунд работать, напрягая CPU, потом на 1 секунду приостанавливать всевозможную деятельность, чтоб процессор мог отдохнуть. Вроде всё вписывается, однако результат отрицательный – по-прежнему процесс переходит в UNKNOWN. А это означает, что он вдруг перестал отвечать и, скорее всего, перестал делать свою основную работу.
Поступило предложение «поиграться с формой квадрата» и, тем самым, попробовать подобрать рабочие настройки империческим путем, потому что каких-либо рекомендаций не существует.
Понятное дело, что можно было бы сразу выставить что-нибудь в духе 1/10, но при этом процесс резервного копирования занимал бы неприлично много времени.
Результат стал положительным только при настройке 5/5 секунд и менее, что, наверное, можно считать оптимальными настройками для корректной работы бэкапов 1С-Битрикс на shared-хостингах.
Выяснилось, что у сервера есть еще одно ограничение, которое техподдержка «недоговорила» — при нагрузке более 50% время не должно превышать 10 секунд! Вот почему стандартный вариант 20/1 не работал. Справедливости ради, надо добавить, что резервное копирование, скорее всего, не совсем честно соблюдает установленные ограничения на потребление ресурсов, и нагрузка может быть несколько выше предполагаемой. Да и сервер, скорее всего, измеряет ее с какой-то погрешностью, и вряд ли он «ошибается» не в свою пользу. Поэтому варианты формата 9/1 тоже не заработали. 1 секунда оказалось слабой передышкой.
Техподдержка предлагала еще одно решение: По запросу они могли выключить систему отслеживания нагрузки на 30 минут, но это точно не для случаев автоматического резервного копирования – перед созданием каждой резервной копией же они не будут это делать :). Но можно проверить, что причина именно в превышении лимитов нагрузки, выполнив ручное резервное копирование при отключенной системе контроля нагрузки.
Вместо заключения
На сегодняшний день разница в стоимости shared хостинга и VDS/VPS не столь велика, и при совершении выбора стоит хорошо задуматься, нужна ли за столь малые деньги столь многая скорбь?
Есть вопросы? Записывайтесь на консультацию – 8 800 201-07-68.
Она бесплатная и ни к чему вас не обязывает
-
June 12 2009, 16:33
- IT
- Cancel
Битрикс: резервное копирование проходит с ошибкой?
С недавних пор у пользователей невыделенных хостингов часто появляется следующая проблема:
при создании резервной копии сайта на Битрикс, архив создается, но он содержит ошибки.
Почему это происходит?
Хостеры, стремясь увеличить скорость работы сайтов своих клиентов и побуждая их использовать оптимизированные скрипты, вводят ограничения на использование системных ресурсов сервера.
Другими словами, если Вы запускаете процесс, который сильно нагружает процессор или использует много памяти, он автоматически убивается.
Для архивации стандартными средствами (tar -czf или zip -r)это означает создание «битого» архива, поскольку архиватор не успевает создать полный архив до момента своего «убийства».
Битрикс использует tar для создания резервной копии, поэтому так же страдает от этой проблемы.
Что делать?
- Попробовать «архивацию по шагам» с шагом 10-15 секунд (принципиально должно помочь, но мне не помогало ни разу);
- воспользоваться командной строкой для архивации всех файлов директории сайта — с помощью SSH ввести команду tar -czf имя_архива путь_к_директории или zip -r имя_архива путь_к_директории;
- создать неархивированную резервную копию и потом ее заархивировать:
а) tar -cf имя_архива путь_к_директории
б) gzip имя_архива.