Как отлаживать: tar: одинокий нулевой блок

8

Как это отладить? Эта проблема внезапно появилась в течение последних нескольких дней. Все резервные копии сайта повреждены.

Если резервная копия оставлена ​​как tar, проблем нет, но как только tar сжимается как, gzили xzя не могу их распаковать.

Там много свободного диска

Local disk space    2.68 TB total / 2.26 TB free / 432.46 GB used

ошибка

tar: Skipping to next header[===============================>                                                    ] 39% ETA 0:01:14
tar: A lone zero block at 2291466===============================>                                                ] 44% ETA 0:01:13
tar: Exiting with failure status due to previous errors
 878MiB 0:00:58 [15.1MiB/s] [===================================>                                                ] 44%

И почему это говорит Skipping to next header? Он никогда не делал этого раньше. Что-то ужасно не так с некоторыми файлами.

В каталогах около 15k файлов pdf, jpg или png.

команда

pv $backup_file | tar -izxf - -C $import_dir

Там должны быть некоторые данные, которые повреждают сжатие.

Я также попытался проверить состояние жесткого диска, выполнив это:

# getting the drives
lsblk -dpno name

smartctl -H /dev/sda
smartctl -H /dev/sdb

На обоих дисках я получаю это:

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

Как я могу узнать, какие файлы повреждают tar.gz? Я просто хочу их удалить.

Обновить

Теперь скопировал все файлы на другой сервер, и у меня точно такая же проблема. Я могу распаковать все и извлечь его без проблем, но как только я захочу сжать файлы, я не могу их распаковать (gz / xz).

clarkk
источник
Заполнялась ли файловая система во время резервного копирования? Любые журналы из резервной копии?
Джефф Шаллер
Есть ли контрольные суммы файлов или какие-либо файлы на диске резервного копирования? Баран ошибок?
Xen2050
4
Можете ли вы показать нам полные команды tar (+ сжатие), которые создали .tar.gz? а как они называются? И в показанной вами команде extractino добавьте v, чтобы отобразить, какие файлы удалось извлечь, это поможет вам точно определить те файлы, которые также приводят к ошибкам
Оливье Дюлак
1
Что произойдет, если вы запустите tar -cf xxx.tar ... без сжатия, тогда gzip xxx.tar? Этот tarball извлекает чисто? Является ли pvпричиной проблемы? Что произойдет , если вы уронили pv ... | ...трубопровод и только непосредственно работать tar -cvzf xxx.tar.gz ...тогда tar -xvzf xxx.tar ...?
Эндрю Хенле
1
Каков базовый тип файловой системы? Каковы версия и размер O / S и сумма двоичных файлов md5? Попробуйте вызвать двоичные файлы с абсолютным путем и без него pv.
MattBianco

Ответы:

7

Ваш файл либо обрезан, либо поврежден, поэтому 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жалуются, то ОС не обнаружила каких-либо повреждений, но файл, тем не менее, недействителен (поврежден или усечен). В любом случае, вы не сможете восстановить этот файл. Вам нужно будет вернуть его из автономных резервных копий.

Жиль "ТАК - перестань быть злым"
источник
Обновил мой вопрос .. Если я проверяю несжатые tar-файлы, я не получаю ошибок, но как только я сжимаю их как gz или xz, я не могу их распаковать
clarkk
1
@clarkk Затем файлы были повреждены до того, как были сохранены или хранятся (но необнаруженные ошибки - это очень маловероятно - ошибки хранения catили что-то еще сообщит, что часть файла нечитаема). Файлы могут быть усечены (например, потому что диск был заполнен во время записи).
Жиль "ТАК - перестань быть злым"
Если файлы были повреждены до того, как они были сохранены в архиве. Как я могу обнаружить поврежденные файлы?
Кларк
Две команды с catи xzcatне возвращает никаких ошибок ..
clarkk
@clarkk Это не так? Это было в вашем первоначальном вопросе. Проблема может быть в сбое ОЗУ на вашем компьютере. Сделайте тест памяти , и ничего от вашей машины не писать , если вы можете избежать этого.
Жиль "ТАК - перестань быть злым"
1

Я не вижу упоминаний о том, как создаются поврежденные файлы tar?

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

Если файлы не могут быть распакованы после перемещения резервной копии на другой компьютер / в другое место, они должны быть либо повреждены, либо повреждены при транспортировке.

Чтобы найти источник ошибки:

  • вручную создать резервную копию на веб-сервере (без pvи без -i)
  • вручную проверить резервную копию на веб-сервере (без pvи без -i)

Если проблем пока не найдено:

  • скопировать резервную копию с веб-сервера
  • протестировать скопированную резервную копию на целевой машине (без pvи без -i)

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

Также убедитесь, что вы используете абсолютные пути всех задействованных команд. Если у вас есть плохая $PATHи / или $LD_LIBRARY_PATHпеременная и злоумышленник в системе, вы можете использовать троянские программы, которые могут вызвать непреднамеренные побочные эффекты.

Конечно, это могут быть и несовместимые tarверсии, если только обе системы не являются Debian. Вы можете попробовать использовать POSIX- режим с обеих сторон.

MattBianco
источник
0

Вы используете флаг, -iкоторый в его длинной форме --ignore-zeros. Вот почему tar не жалуется на испорченные файлы. Итак, если вы хотите отладить ваш tar-файл, просто удалите -iопцию, и вы получите список поврежденных файлов.

Есть также 2 других способа найти поврежденные файлы в Unix (в общем). Я цитирую ответ, данный в другом вопросе.

rsync может использоваться для копирования каталогов и может перезапустить копию с того места, на котором она была прервана, если какая-либо ошибка приведет к смерти rsync.

Используя --dry-runопцию rsync, вы можете увидеть, что будет скопировано, фактически ничего не копируя. В --statsи --progressварианты также будут полезны. и --human-readableили -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.

Для справки: поиск поврежденных файлов

tmow
источник
0

Линия рассуждений в ответе @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.

earcam
источник