How to verify a tar.gz archive before extraction

Архив имеет ожидаемый размер и открывается в файловом менеджере. Это полезный признак, но перед восстановлением стоит проверить его точнее. У файла tar.gz есть как минимум два уровня: сжатый поток gzip и структура архива tar внутри. Их проверка решает разные задачи.

Команда проверяет целостность сжатого потока без извлечения содержимого в каталог. Обычно успешная проверка не печатает развёрнутый отчёт; для сценария важен код завершения. Ошибка должна сохраняться в результате, а не теряться из-за следующей команды.

Большой архив будет прочитан целиком. Учитывайте дисковую нагрузку и не запускайте множество проверок одновременно на томе, который уже испытывает проблемы.

Для списка объектов tar:

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

2 октября 2026 года мы проверили команды в изолированном Linux-окружении с GNU tar 1.35 и GNU gzip 1.12. Учебный архив good.tar.gz содержал site/index.html и db.sql; SQL-файл был текстовым образцом, а не копией рабочей базы. Другие варианты создали из этих же тестовых данных. Рабочие сайты и резервные копии клиентов не использовались; извлечение файлов не выполнялось.

Для корректного учебного архива список выглядел так:

У обрезанного файла gzip сообщил:

При чтении того же файла tar сначала напечатал оба имени, а затем завершился с кодом 2 и сообщениями:

Короткий текст в gzip дал особенно полезный контрпример: в этой версии GNU tar команда завершилась без ошибки и ничего не перечислила. Поэтому критерий предварительной проверки — успешные команды плюс ожидаемый состав. Даже эти условия ещё не подтверждают пригодность восстановления.

В обычном интерактивном Bash сохраните код сразу после проверяемой команды. В примере ниже список и ошибки записываются в отдельные файлы текущего каталога; выберите свободные имена, чтобы не затереть предыдущий отчёт.

В этом GNU tar параметр --force-local трактует двоеточие в имени файла как часть локального пути. Ненулевой результат или неожиданный список требуют разбора до распаковки. Если проверка включена в сценарий с set -e, используйте явную обработку неудачи через if: простой сценарий может завершиться до присваивания переменной.

Предположим, архив целый, но внутри только файлы сайта без базы данных. Для статического проекта этого может хватить, а для интернет-магазина — нет. Нужно знать, какие компоненты входят в принятую схему резервирования и как они согласованы по времени.

Посмотрите на неожиданные абсолютные пути, переходы к родительским каталогам и символические ссылки. Недоверенный архив не следует извлекать с повышенными правами в рабочую директорию. Проверка списка не делает его содержимое безопасным для исполнения.

Успех проверки gzip и чтения tar не гарантирует бизнес-целостность базы данных, пригодность конфигурации или возможность запустить приложение. Даже полный список ожидаемых файлов не подтверждает, что резервная копия была сделана в согласованном состоянии.

Отдельно нужна проверка восстановления в изолированном окружении. Там оценивают запуск приложения и контрольные данные, не отправляя реальные письма и не обращаясь к боевым платёжным сервисам. В этой инструкции восстановление не выполняется.

Запишите имя архива, время его создания, размер, результат проверки gzip и результат чтения структуры tar. Если существует доверенная контрольная сумма, добавьте её сравнение отдельным пунктом. Не называйте архив проверенным восстановлением, если вы только прочитали список.

При ошибке сохраните исходный файл и сообщение, затем проверьте источник и процесс передачи. Не распаковывайте повреждённый архив поверх действующего сайта в надежде, что «основные файлы целые». Цель предварительного контроля — выявить проблему до того, как восстановление начнёт менять рабочие данные.

An archive has the expected size and opens in a file manager. This is a useful sign, but you should verify it more thoroughly before restoration. A tar.gz file has at least two levels: the gzip compressed stream and the tar archive structure inside. Verifying each level solves different tasks.

The command verifies the integrity of the compressed stream without extracting the contents to a directory. Usually, a successful check does not print a detailed report; for a script, the exit code is what matters. An error must be preserved in the result, not lost due to the next command.

A large archive will be read in its entirety. Consider disk load and do not run multiple checks simultaneously on a volume that is already experiencing issues.

For the list of objects in tar:

If the list is too large, first clarify the backup composition based on its description. Skipping output through a program that terminates after the first few lines can interrupt archive reading before the end. Such viewing must not be presented as a full verification of the entire contents.

On October 2, 2026, we tested the commands in an isolated Linux environment with GNU tar 1.35 and GNU gzip 1.12. The sample archive good.tar.gz contained site/index.html and db.sql; the SQL file was a text sample, not a copy of a working database. Other variants were created from the same test data. No live customer websites or backups were used, and no file extraction was performed.

For a correct sample archive, the list looked like this:

The truncated gzip file reported:

When reading the same file, tar first printed both names, then exited with code 2 and the following messages:

The short text in gzip provided a particularly useful counterexample: in this version, GNU tar completed without error and listed nothing. Therefore, the preliminary check criterion is successful commands plus the expected composition. Even these conditions do not yet confirm recovery suitability.

In a standard interactive Bash session, save the exit code immediately after the command being checked. In the example below, the file list and errors are written to separate files in the current directory; choose unused names to avoid overwriting previous reports.

In this GNU tar version, the --force-local parameter treats a colon in the filename as part of the local path. A non-zero result or an unexpected file list requires parsing before extraction. If the check is included in a script with set -e, use explicit error handling via if: a simple script may terminate before the variable is assigned.

Assume the archive is intact but contains only website files without a database. This may suffice for a static project, but not for an online store. You need to know which components are included in the accepted backup scheme and how they are synchronized in time.

Look for unexpected absolute paths, parent directory transitions, and symbolic links. Do not extract an untrusted archive with elevated privileges into the working directory. Checking the file list does not make its contents safe to execute.

Success of gzip verification and tar reading does not guarantee database business integrity, configuration suitability, or the ability to run the application. Even a complete list of expected files does not confirm that the backup was created in a consistent state.

Separate verification of restoration in an isolated environment is required. There, application startup and control data are evaluated without sending real emails or contacting live payment services. This instruction does not perform restoration.

Record the archive name, its creation time, size, gzip verification result, and tar structure reading result. If a trusted checksum exists, add its comparison as a separate item. Do not label an archive as a verified restoration if you have only read the file list.

On error, save the original file and the message, then check the source and transfer process. Do not unpack a corrupted archive over a live site hoping that "core files are intact." The purpose of preliminary control is to identify the issue before restoration begins modifying live data.