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

Если резервная копия оставлена ​​как 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).

Ваш файл либо обрезан, либо поврежден, поэтому 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?

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

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

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

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

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

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

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

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

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

Вы используете флаг, -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.

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

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