Как это отладить? Эта проблема внезапно появилась в течение последних нескольких дней. Все резервные копии сайта повреждены.
Если резервная копия оставлена как 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).
источник
tar -cf xxx.tar ...
без сжатия, тогдаgzip xxx.tar
? Этот tarball извлекает чисто? Является лиpv
причиной проблемы? Что произойдет , если вы уронилиpv ... | ...
трубопровод и только непосредственно работатьtar -cvzf xxx.tar.gz ...
тогдаtar -xvzf xxx.tar ...
?pv
.Ответы:
Ваш файл либо обрезан, либо поврежден, поэтому
xz
не может добраться до конца данных.tar
жалуется, потому что архив останавливается посередине, что логично, такxz
как не удалось прочитать все данные.Выполните следующие команды, чтобы проверить, где проблема:
Если
cat
жалуется, то файл поврежден на диске, и операционная система обнаружила повреждение. Проверьте журналы ядра для получения дополнительной информации; обычно диск необходимо заменить на этом этапе. Если толькоxz
жалуются, то ОС не обнаружила каких-либо повреждений, но файл, тем не менее, недействителен (поврежден или усечен). В любом случае, вы не сможете восстановить этот файл. Вам нужно будет вернуть его из автономных резервных копий.источник
cat
или что-то еще сообщит, что часть файла нечитаема). Файлы могут быть усечены (например, потому что диск был заполнен во время записи).cat
иxzcat
не возвращает никаких ошибок ..Я не вижу упоминаний о том, как создаются поврежденные файлы tar?
Вы говорите, что это резервные копии с веб-сайта, но все проблемы, которые вы показываете, возникают при восстановлении / распаковке, так что именно здесь (источник) вам нужно приложить усилия для устранения неполадок.
Если файлы не могут быть распакованы после перемещения резервной копии на другой компьютер / в другое место, они должны быть либо повреждены, либо повреждены при транспортировке.
Чтобы найти источник ошибки:
pv
и без-i
)pv
и без-i
)Если проблем пока не найдено:
pv
и без-i
)Если до сих пор проблем не обнаружено, сценарий резервного копирования не создает архив так же, как вы это делали, когда делали это вручную (и, вероятно, его следует изменить, чтобы сделать то, что вы делали вручную).
Также убедитесь, что вы используете абсолютные пути всех задействованных команд. Если у вас есть плохая
$PATH
и / или$LD_LIBRARY_PATH
переменная и злоумышленник в системе, вы можете использовать троянские программы, которые могут вызвать непреднамеренные побочные эффекты.Конечно, это могут быть и несовместимые
tar
версии, если только обе системы не являются Debian. Вы можете попробовать использовать POSIX- режим с обеих сторон.источник
Вы используете флаг,
-i
который в его длинной форме--ignore-zeros
. Вот почему tar не жалуется на испорченные файлы. Итак, если вы хотите отладить ваш tar-файл, просто удалите-i
опцию, и вы получите список поврежденных файлов.Есть также 2 других способа найти поврежденные файлы в Unix (в общем). Я цитирую ответ, данный в другом вопросе.
Для справки: поиск поврежденных файлов
источник
Линия рассуждений в ответе @MattBianco - это то, что я бы методично следовал, чтобы решить эту конкретную проблему.
Нулевые блоки указывают EOF, но это зависит от коэффициента блокировки (по умолчанию это скомпилированная константа, обычно 20). Тар
--compare
|--diff
кажется, чтобы выполнить с--ignore-zeros
(-i
) неявно.Учитывая дополнительное осложнение
pv
, я подозреваю,tar -i
что вызывает проблемыxz
, глядя на tar man на фактор блокировки, который я бы предложил сначала удалить-i
Тогда, если это не поможет, заменив на:
Если вы только что прочитали это, используя гугл «tar: одинокий нулевой блок в N» , и ничего не пропускаете, попробуйте
--ignore-zeros
.источник