Как отлаживать: tar: Одинокий нулевой блок
У меня было аналогичное требование, чтобы я работал без проблем из разных мест с динамическими IP-адресами, тем более что я использую виртуальные машины. Мое простое решение состоит в следующем:
Создайте сценарий для обновления записей хоста для каждой сущности. Например, если у меня есть хост с именем myhost.net с поддоменами app.myhost.net, я бы вызвал этот сценарий и предоставил IP-адрес, который будет записан для каждого домена и сохранен в файле хоста с именем «мой хозяин». Тот же сценарий имеет флаг для удаления или обновления одного файла хоста.
Создайте еще один сценарий для объединения этих файлов в / etc / hosts. Этот скрипт найдет все созданные вами файлы хостов и объединит их в один файл хостов в / etc / hosts.
Это отлично сработало для меня. Я работаю удаленно, и иногда мне нужно перемещаться между локациями по той или иной причине, и меня обременяет необходимость редактировать этот один файл столько раз. Вместо этого я просто запускаю ОДИН сценарий. Да, один сценарий. Первый сценарий автоматически запускает другой, чтобы выполнить слияние автоматически.
Ваш файл усечен или поврежден, поэтому xz не может добраться до конца данных.tar ругается, потому что архив останавливается посередине, что логично, поскольку xz не успел прочитать все данные.
Выполните следующие команды, чтобы проверить, в чем проблема:
cat /var/www/bak/db/2017-05-20-1200_mysql.tar.xz >/dev/null
xzcat /var/www/bak/db/2017-05-20-1200_mysql.tar.xz >/dev/null
Если cat жалуется, значит, файл на диске поврежден, и операционная система обнаружила повреждение. Проверьте журналы ядра для получения дополнительной информации; обычно в этот момент диск необходимо заменить. Если жалуется только xz, ОС не обнаружила никаких повреждений, но файл, тем не менее, недействителен (либо поврежден, либо усечен). В любом случае, вы не сможете восстановить этот файл. Вам нужно будет получить его обратно из ваших автономных резервных копий.
Вы используете флаг -i, который в своей длинной форме имеет вид --ignore-zeros.
Вот почему tar не жалуется на поврежденные файлы.
Итак, если вы хотите отладить свой tar-файл, просто удалите опцию -i, и вы получите список поврежденных файлов.
Есть также 2 других способа найти поврежденные файлы в Unix (в целом). Я цитирую ответ, данный в другом вопросе.
rsync может использоваться для копирования каталогов и способен перезапускать копию с точки, в которой она была прервана, если какая-либо ошибка приводит к прекращению работы rsync.
Используя опцию rsync
--dry-run, вы можете увидеть, что будет скопировано, ничего не копируя. Опции--statsи--progressтакже будут полезны. и--человекочитаемыйили-hлегче читать.напр.
rsync --dry-run -avh --stats --progress /path/to/src/ /path/to/destination/
Я не уверен, установлен ли rsync по умолчанию в Mac OS X, но я использовал его на Mac, поэтому я знаю, что он определенно доступен.
Для быстрой проверки возможности чтения файлов в подкаталоге вы можете использовать
grep -r XXX /path/to/directory/ > /dev/null. Регулярное выражение поиска не имеет значения, потому что вывод все равно отбрасывается.STDOUT перенаправляется на /dev/null, поэтому вы увидите только ошибки.
Единственная причина, по которой я выбрал здесь grep, заключалась в его опции рекурсии
-R.Есть много других команд, которые можно использовать вместо grep здесь и даже больше, если используется с find.
В качестве ссылки: Поиск поврежденных файлов
Я не вижу упоминания о том, как создаются поврежденные файлы tar?
Вы говорите, что это резервные копии с веб-сайта, но проблемы, которые вы показываете, связаны с восстановлением/распаковкой, так что здесь (источник) вам нужно приложить усилия для устранения неполадок.
Если файлы не могут быть распакованы после перемещения резервной копии на другую машину/в другое место, они должны быть либо созданы с ошибкой, либо повреждены при транспортировке.
Чтобы найти источник ошибки:
- вручную создайте резервную копию на веб-сервере (без
pvи без-i) - вручную проверьте резервную копию на веб-сервер (без
pvи без-i)
Если пока проблем не обнаружено:
- скопируйте резервную копию с веб-сервера
- проверьте скопированную резервную копию на целевой машине (без
pvи без-i)
Если пока проблем не обнаружено, сценарий резервного копирования не создает архив так же, как вы это делали при выполнении это вручную (и, вероятно, его следует изменить, чтобы он делал то, что вы делали вручную).
Также убедитесь, что вы используете абсолютные пути всех задействованных команд. Если у вас есть плохая переменная $PATH и/или $LD_LIBRARY_PATH и злоумышленник в системе, возможно, вы используете троянские двоичные файлы, которые могут вызвать непреднамеренные побочные эффекты.
Конечно, это могут быть и несовместимые версии tar, если только обе системы не являются Debian. Вы можете попробовать установить режим POSIX на обеих сторонах.
Логика рассуждений в ответе @MattBianco — это то, чему я методично следовал, чтобы решить эту конкретную проблему.
Обнуленные блоки обозначают EOF, но это зависит от коэффициента блокировки (по умолчанию используется скомпилированная константа, обычно 20 ). Тара --compare| --diff, кажется, выполняется с--ignore-zeros(-i)неявно.
Учитывая дополнительное усложнение pv, я подозреваю, что tar -iвызывает проблемы для xz. Глядя на tar man на фактор блокировки , я бы предложил сначала удалить-i
Затем, если это не поможет, замените на:
--read-full-records --blocking-factor=300
Если вы просто читаете это, нагуглив "tar :Одинокий нулевой блок в N" и ничего не передаете, попробуйте --ignore-zeros.