"restore.php" в итоге вылетел по тайм ауту, но думаю если подправить переменные в php то развернёт. Вопрос в том зачем делать дублирующий, да ещё и нерабочий инструмент резервирования в виде скрипта "bx_backup.sh" после которого архивы не развернуть? Либо если делаете скрипт бэкапа, то должен быть и скрипт восстановления, который с ним работает. Да, я видел инструкцию по восстановлению, но команда "tar xzvvf" не распаковывает архив, созданный этим скриптом. По итогу буду делать бэкапы средствами админки bitrix, а эту поделку оставлю на совесть разработчикам.
Продолжая свои эксперименты пришёл к следующим результатам. Архив, назовём его test1.tar.gz, сделанный неисправленным скриптом с методом "tar -cf + gzip" не может быть просмотрен командой tar -tvf с ошибкой
Код
tar: Это не похоже на tar-архив
tar: Пропускается до следующего заголовка
Так же не может развернуть скрипт "restore.php", выдавая ошибку.
Сделал архив test2.tar.gz методом "tar -czf" распаковывается как tar-ом, так и скриптом "restore.php"
Роман Семёнов написал: может разработчики не в курсе данных возможностей
Возможность сжатия средствами tar, насколько я знаю, была с незапамятных времён, уж точно раньше возникновения продукта 1c-bitrix.
Цитата
Евгений Неверов написал: гораздо быстрее сделать архив таром и потом в тихом режиме
А какая, простите, мне разница сколько делается архив, если это происходит ночью, когда сервером никто не пользуется? И не думаю что связка "tar -cf + gzip" сильно отличается по времени выполнения от "tar -czf", но дискового пространства требует в 2 раза больше.
Бэкапы делаются в ночное время, когда изменения на сайте никто и ничто не производит так что никакого рассинхрона не будет.
Я всё это к чему. Понимаю что ради меня скрипты никто переписывать не будет и найдётся куча причин НЕ делать этого. Я сам могу поменять логику бэкапа, подправив пару строк в этом скрипте. Вопрос в том не будет ли проблем при распаковке бэкапа скриптом восстановления restore.php если бэкап будет создан при помощи "tar -czf"" ? Если проблем не будет, вопрос можно будет считать закрытым.
Делаю бэкапы сайтов встроенным скриптом "/opt/webdir/bin/bx_backup.sh" и в один "прекрасный" момент получаю ошибку нехватки места для бэкапа. Заглянул в папку "/home/bitrix/backup/archive/" вижу там несжатый архив с расширением .tar. Мне стало интересно почему последний архив с таким расширением, а не сжат в tar.gz, как предыдущие. И тут я нашёл в скрипте "bx_backup.sh" следующий код.
Код
...
create_backup_archive(){
BACK_FILE=$backup_dir/www_backup_${kernel_name}_${DATE_STR}_${RAND_STR}.tar
# create tar archive
tar -cf $BACK_FILE --exclude-from=$WWW_EXCL_DIR -C $BACK_KERNEL_ROOT \
$BACK_WWW_DIRS \
$BACK_SQL_FILES 2>/dev/null
# 1 Some files differ
# 2 Fatal error. This means that some fatal, unrecoverable error occurred.
[[ $? -eq 2 ]] && \
error "Cannot create tar archive=$BACK_FILE"
gzip $BACK_FILE
# delete sql files; we have added them to archive
for sql_file in $BACK_SQL_FILES; do
rm -f $sql_file
log_to_file "Delete sql file=$sql_file"
done
}
...
Судя по логике сначала делается большой архив .tar, а потом он же сжимается. При этом место для такого преобразования нужно как минимум в 2 раза больше.
Объясните мне, зачем делать сначала "tar -cf ...", а потом отдельно "gzip $BACK_FILE" ? Почему не сделать сразу "tar -czf ..." и получить за одну команду тот же самый сжатый архив, ещё и место в процессе создания сэкономить?