Как проверить целостность распакованных файлов, если исходный архив уже удалён

Ситуация знакома многим: архив распакован, оригинал удалён для экономии места, а через время возникает сомнение — всё ли извлеклось корректно. Прямого сравнения с эталоном уже нет, но это не значит, что проверить результат невозможно. В статье разобраны все доступные способы верификации «после факта», их применимость и ограничения.

Почему стандартная верификация не сработает и что остаётся

Классическая проверка архива — побайтовое сравнение распакованных данных с контрольными суммами, записанными внутри контейнера (CRC32 в ZIP, SHA-256 в 7z, RAR и др.) — требует наличия самого архива. Если файл удалён, этот путь закрыт. Остаются косвенные методы: внешние контрольные суммы (если они были созданы заранее), внутренние признаки целостности файлов, функциональные тесты и избыточные коды восстановления.

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

Метод 1: Внешние контрольные суммы — единственный надёжный эталон

Если до удаления архива вы (или источник распространения) создали файл с хешами — .sfv (CRC32), .md5, .sha1, .sha256 — это лучший сценарий. Хеш-функция вычисляет уникальный отпечаток содержимого каждого файла. Совпадение хеша после распаковки с эталонным значением математически гарантирует побайтовую идентичность.

• Где искать: рядом с архивом (часто в том же каталоге), в отдельном файле hashes.txt, checksums.sha256, в описании торрента, на странице загрузки, в сопроводительном .nfo или .txt.
• Как проверить: любой хеш-калькулятор (HashCheck, HashTab, 7-Zip → ПКМ → CRC SHA, certutil -hashfile в Windows, sha256sum -c в Linux).
• Важно: хеш должен считаться от распакованных файлов, а не от архива. Если эталонные хеши считались от архива — они бесполезны для проверки содержимого.

Ограничение: если хеш-файла нет и его не было создано до удаления архива — этот метод неприменим. Нельзя восстановить эталонный хеш постфактум.

Метод 2: Встроенные контрольные суммы контейнеров (CRC32, BLAKE2, SHA-256 внутри архива)

Большинство современных форматов хранят контрольную сумму каждого файла внутри самого архива. Но прочитать их без архива нельзя — метаданные удалены вместе с контейнером. Исключение: если вы извлекли не только полезную нагрузку, но и служебные файлы (например, .par2, .sfv, .md5 лежали внутри архива), их можно использовать как внешние эталонные суммы.

Практически: если архив удалён безвозвратно, встроенные CRC недоступны. Этот метод работает только при наличии копии архива или извлечённых служебных файлов.

Метод 3: Проверка через PAR2 / Recovery Records / .rev — избыточность как страховка

Если в наборе данных были файлы восстановления (.par2, .vol00+01.par2, RAR-томы с recovery record, .rev), они позволяют не только обнаружить, но и исправить повреждения без оригинального архива. Это единственный метод, дающий активную защиту постфактум.

• PAR2 (Parchive): работает на уровне файлов. Нужны сами PAR2-файлы и достаточно избыточности (обычно 5–10% от размера данных). Инструменты: MultiPar, QuickPar, par2cmdline.
• RAR Recovery Record: встроен в томы RAR. Требует наличия всех томов и достаточного процента RR (задаётся при создании). Инструмент: WinRAR → «Восстановить».
• ZIP/7z: не имеют встроенного восстановления. Защита только внешними PAR2.

Критерий применимости: файлы восстановления должны быть сохранены вместе с данными. Если вы удалили и их — метод не работает.

Метод 4: Функциональная проверка — «пробный запуск» извлечённых файлов

Самый практичный подход для пользовательских данных: открыть, запустить, прослушать, просмотреть. Если файл работает — он, скорее всего, цел. Этот метод проверяет семантическую целостность (файл выполняет свою функцию), а не побайтовую.

Тип файла	Что проверять	Инструменты / действия
Исполняемые / установщики (.exe, .msi, .apk, .deb, .rpm)	Запуск, прохождение установки, отсутствие ошибок CRC при установке	Запуск от имени администратора, проверка цифровой подписи (ПКМ → Свойства → Цифровая подпись)
Архивы внутри архива (вложенные .zip, .rar, .7z, .tar.gz)	Тест целостности вложенного архива	7-Zip / WinRAR → «Проверить» (Test) для каждого вложенного архива
Видео / аудио	Проигрывание до конца, отсутствие артефактов, заиканий, зелёных кадров	VLC, MPV, MPC-BE (перемотка по ключевым кадрам), ffmpeg -v error -i file -f null —
Образы дисков (.iso, .img, .vhd, .vmdk)	Монтирование, чтение файловой системы, проверка контрольных сумм файлов внутри	Встроенные средства ОС (монтирование), sha256sum файлов внутри образа
Документы (.pdf, .docx, .xlsx, .odt)	Открытие, прокрутка до конца, печать в файл, проверка внутренней структуры	Офисные пакеты, pdfinfo, qpdf —check
Базы данных (.sqlite, .mdb, .frm/.ibd)	Запрос к таблицам, проверка целостности (PRAGMA integrity_check)	DB Browser for SQLite, sqlite3 file.db «PRAGMA integrity_check;»
Исходный код / скрипты / конфиги	Компиляция, линтинг, запуск тестов, синтаксическая проверка	Компилятор, линтеры, CI-пайплайн

Ограничение: функциональная проверка не найдёт повреждение в неиспользуемых участках (например, в нераспакованных ресурсах установщика, в конце видеофайла, если не досмотрели, в неиспользуемых таблицах БД). Она подтверждает «работает сейчас», а не «идентичен оригиналу».

Метод 5: Структурная и статистическая проверка файловой системы

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

• Количество файлов и папок: сравнить с ожидаемыми значениями (из описания релиза, README, торрент-листинга). Команды: find /path -type f | wc -l (Linux), (Get-ChildItem -Recurse -File).Count (PowerShell).
• Суммарный размер: сравнить с заявленным. Не гарантирует правильность содержимого, но выявит грубые потери (пропущенные гигабайты).
• Пустые файлы (0 байт): их наличие там, где не должно быть — признак ошибки извлечения. Поиск: find /path -type f -size 0.
• Права доступа и атрибуты: на Unix-системах — проверка битов исполнения, владельца. На Windows — атрибуты «только чтение», «скрытый», ACL.
• Символические и жёсткие ссылки: если архив их сохранял (tar, 7z с флагом -snl), проверить корректность целей ссылок.

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

Метод 6: Криптографическая подпись и цепочка доверия

Если файлы подписаны цифровой подписью (Authenticode для .exe/.msi/.dll, GPG/PGP для релизов Linux, APK signing, RPM signatures), проверка подписи подтверждает: файл не менялся после подписания и авторство принадлежит владельцу ключа.

• Windows (Authenticode): ПКМ → Свойства → Цифровая подпись → Подробности → Просмотреть сертификат. Или signtool verify /pa /v file.exe (Windows SDK).
• Linux пакеты: rpm —checksig package.rpm, dpkg-sig —verify package.deb, apt-key verify.
• GPG/PGP: gpg —verify file.sig file (нужен отдельный файл подписи и публичный ключ автора).
• Android APK: apksigner verify —print-certs app.apk (Android SDK).

Важно: подпись проверяет целостность подписанного файла. Если архив содержал множество неподписанных файлов — подпись охватывает только конкретные исполняемые модули.

Метод 7: Сравнение с альтернативным источником (дедупликация)

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

• Побайтовое сравнение: fc /b file1 file2 (Windows), cmp file1 file2 (Linux), diff -r dir1 dir2.
• Хеш-сравнение: посчитать SHA-256 обоих наборов и сравнить списки.
• Инструменты дедупликации: dupeGuru, AllDup, fdupes, rdfind — найдут идентичные файлы, даже если имена отличаются.

Этот метод даёт 100% гарантию при полном совпадении, но требует наличия второго экземпляра данных.

Пошаговый алгоритм проверки «после факта»

1. Оцените ценность данных. Критично ли потерять/повредить эти файлы? От этого зависит глубина проверки.
2. Поищите внешние хеши. Проверьте каталог загрузки, страницу источника, торрент-файл, сопроводительные .txt/.nfo/.sfv/.md5/.sha256. Если нашли — верифицируйте ими (Метод 1). Это даёт максимальную уверенность.
3. Проверьте наличие файлов восстановления. Есть ли .par2, .rev, тома RAR с RR? Если да — запустите восстановление/проверку (Метод 3).
4. Проведите структурный аудит. Количество файлов, суммарный размер, пустые файлы, права доступа (Метод 5). Выявит грубые ошибки за секунды.
5. Проверьте цифровые подписи. Для исполняемых файлов, пакетов, драйверов (Метод 6).
6. Запустите функциональные тесты. Приоритет: вложенные архивы (Test в 7-Zip), образы дисков (монтирование), установщики (пробная установка в песочнице/VM), медиафайлы (пробное воспроизведение ключевых фрагментов).
7. При необходимости — сравните с альтернативным источником (Метод 7).
8. Документируйте результат. Сохраните лог проверки, список проверенных файлов, найденные проблемы. Примите решение: использовать, перекачать, восстановить из бэкапа.

Типичные ошибки и как их избежать

• Удаление архива до верификации. Правило: сначала проверка (Test в архиваторе), потом удаление. Тест встроенных CRC занимает минуты и экономит часы постфактум.
• Доверие только размеру/количеству файлов. Это не гарантирует правильность содержимого. Файл может иметь верный размер, но быть заполнен нулями или мусором.
• Игнорирование вложенных архивов. Внутри большого архива часто лежат другие архивы. Их нужно тестировать отдельно — внешний тест их не проверит.
• Проверка только «начала» медиафайлов. Повреждения часто в конце или в середине. Нужен полный проход (ffmpeg -v error или перемотка в плеере).
• Предположение, что «работает — значит всё ок». Для критичных данных (бэкапы, исходники, финансовые отчёты) нужна побайтовая верификация хешами.
• Отсутствие PAR2 для долгосрочного хранения. Если данные важны и хранятся месяцы/годы — создавайте PAR2 (5–10% избыточности) сразу после проверки. Это спасёт от битротта и деградации носителя.

Сценарии: что делать в типичных ситуациях

Сценарий А: Скачали игру/программу, установили, архив удалили, игра запускается

Вердикт: с высокой вероятностью всё в порядке. Установщик сам проверяет CRC своих внутренних архивов. Если установка прошла без ошибок «CRC error», «Data error», «Corrupt cabinet» — данные целы. Дополнительно: проверьте цифровую подпись основного .exe.

Сценарий Б: Распаковали большой набор фото/видео/документов (нет хешей, нет PAR2)

Действия: 1) Структурная проверка (кол-во, размер, 0-байт). 2) Выборочное открытие 10–20% файлов из разных папок. 3) Для видео — ffmpeg -v error -i file -f null — на выборке. 4) Если найдены битые — перекачивайте именно их (поиск по имени в торренте/облаке) или весь набор.

Сценарий В: Распаковали бэкап системы / образ диска / базу данных

Требование: побайтовая точность критична. Без внешних хешей или PAR2 гарантии нет. Не используйте такой бэкап для восстановления в продакшн без верификации по эталонным хешам. Если хешей нет — считайте бэкап непроверенным. Срочно создайте хеши от текущего состояния для будущих проверок.

Сценарий Г: Торрент-раздача, удалили .torrent и архив, хотим раздавать дальше

Решение: клиент торрента (qBittorrent, Transmission, Deluge) умеет «Force recheck» / «Проверить» файлы по хешам из .torrent-файла. Нужен только .torrent-файл (магнит-ссылка не содержит хешей кусков). Если .torrent потерян — скачайте его снова с трекера или экспортируйте из клиента, если раздача ещё в списке. Без .torrent верифицировать для раздачи нельзя.

Инструментарий: что держать под рукой

• 7-Zip (Windows/Linux/macOS) — тест вложенных архивов, расчёт CRC/SHA внутри GUI и CLI (7z t archive.7z, 7z h file).
• HashCheck / HashTab (Windows) — интеграция в Проводник, проверка .sfv/.md5/.sha1/.sha256.
• certutil -hashfile file SHA256 (Windows встроен), sha256sum / md5sum (Linux/macOS встроены).
• MultiPar / QuickPar (Windows) — PAR2 верификация и восстановление.
• par2cmdline (кроссплатформенный CLI для PAR2).
• ffmpeg -v error -i input -f null — — быстрая проверка декодируемости видео/аудио без вывода.
• qpdf —check file.pdf, pdfinfo file.pdf — проверка PDF.
• sqlite3 file.db «PRAGMA integrity_check;» — проверка SQLite.
• signtool (Windows SDK), apksigner (Android SDK), gpg — проверка подписей.
• rdfind, fdupes, dupeGuru — поиск дубликатов для сравнения с другим источником.

Что сделать прямо сейчас, чтобы не попасть в эту ситуацию снова

1. Никогда не удаляйте архив до прохождения «Test» в архиваторе. Это занимает 1–5 минут и проверяет все встроенные CRC.
2. Создавайте файл хешей сразу после распаковки (и проверки). Команда: sha256sum * > SHA256SUMS.txt (Linux) или 7-Zip → CRC SHA → SHA-256 → сохранить в файл. Храните этот .txt вместе с данными.
3. Для важных данных создавайте PAR2 (5–10%). par2create -r10 data.par2 /path/to/data. Это страховка от битротта, ошибок диска и случайного удаления.
4. Ведите журнал источников. Сохраняйте .torrent-файлы, URL загрузки, релиз-ноты с хешами. Это ваш эталон для будущих проверок.
5. Автоматизируйте периодическую проверку. Раз в 6–12 месяцев прогоняйте sha256sum -c SHA256SUMS.txt или par2verify data.par2 для критичных архивов.

Резюме: иерархия уверенности без оригинального архива

1. Максимум: совпадение с внешними криптографическими хешами (SHA-256, BLAKE3) из доверенного источника.
2. Высоко: успешное восстановление/проверка через PAR2 / Recovery Record с достаточной избыточностью.
3. Средне-высоко: валидная цифровая подпись исполняемых файлов / пакетов + прохождение функциональных тестов вложенных архивов и образов.
4. Средне: полная функциональная работа всех проверенных файлов (установка, воспроизведение, открытие) + чистая структурная статистика.
5. Низко: только совпадение количества файлов и суммарного размера.
6. Нет гарантии: никаких проверок не проводилось.

Если данные критичны — старайтесь попасть в уровень 1 или 2. Для бытовых медиатеки и софта часто достаточно уровня 3–4. Главное — не путать «вроде работает» с «побайтово идентично оригиналу».

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