Когда побилась только база mysql нет необходимости распаковывать и обрабатывать все файлы, включая ядро.



Добавить возможность восстановления только базы данных.

Для резервных копий в облаке выделяется не так много места. При этом сжатие производится старым неэффективным методом - с помощью gz.  Этому есть альтернатива - xz, он жмет примерно в два раза лучше, может работать с несколькими ядрами процессора (что уменьшит время создания резервных копий в несколько раз). У себя на сервере мне пришлось переделать скрипт резервного копирования виртуального окружения Битрикс.

Я предлагаю в настройках регулярного резервного копирования добавить настройки:
- выбор архиватора;
- степень сжатия;
- включения многопоточности и выбора количества ядер для сжатия;
- и добавить возможность делать резервные копии только по рабочим дням (зачем мне забивать место копиями, в которых ни чего не изменилось).
- добавить в скрипт restore.php возможности по распаковке таких архивов.

Смысл в том, чтобы при распаковке бэкапа выводилась более точная информация - например, какой файл обрататывается, и чтобы периодически эта информация обновлялась (хотя бы раз в 5-10 секунд). А то при распаковке больших архивов, а точнее - сайтов с большой папкой upload, распаковка очень долго висит на одном значении в процентах и непонятно - идет ли распаковка, или скрипт завис вообще

Иногда при восстановлении возникает много одинаковых ошибок, и нажимать "пропустить" 100500 раз немного утомительно. Поэтому неплохо бы рядом с кнопкой "пропустить" иметь флажок "приметь ко всем подобным ошибкам"

Здравствуйте!

Был ООчень впечатлен тем, что на хостинге restore.php неможет выкачивать бэкапы с сайтов https (ssl), даже если в url загрузки указываешь явно https://mysite.ru/bitrix/backup/xxxxxx.tar.gz  

Функция удаленной загрузки фала не учитывает флаг загрузки через https! Выплёвывает лишь php_network_getaddresses error

Приходится выкачивать в ручную через ssh или вырубать https! Очень обидная "свинка" в таких важных вещах, особенно если речь идет о бэкапе размеров в 55 Gb... и прочие закачки дают ощутимую разницу по времени в сравнении с прямой заливкой!

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

Для примера - прошло криво обновление, а второй раз оно ведь не доступно.

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

Или наоборот известно точно, что они изменяли ядро, но нужно это все перезаписать поверх, чтоб не было в ядре изменений (конечно сайт может слететь при таком исходе , но нам например нужен чистый битрикс).

Еще ситуация в последней 11 версии - Монитор качества при проверке на всех наших проектах показывает, что файлы модулей были изменены, хотя там ничего не трогали.
Значит либо обновление прошло криво, либо что-то еще.
Но факт на лицо - файлы не соответствуют эталону.
Обновили бы поверх и проверка прошла успешно.

Да и тех.поддержке Битрикса было бы удобнее - при некоторых обращениях не просить доступ и лазить по сайту в поисках "кривого" файла, а просто посоветовать "обновить ядро поверх".

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

Естественно для безопасности эта функция должна быть доступна только для активных лицензий и для систем у которых стоят все стабильные обновления.

Хотя может быть и бред это все .

Хотелось бы в резервном копировании иметь возможность быстрого автоматического восстановления сайта из резервной копии. Т.е. что бы Битрикс сам себя удалял (и файлы и базу) и после этого восстанавливался из выбранной резервной копии.
Также хотелось бы иметь настройку в продукте, позволяющую автоматически создавать резервные копии сайта перед обновлением продукта или установкой какого-либо решения.