Проверка хэша диска и его копии

Какой объект нужно хэшировать

Хэш-функция последовательно обрабатывает байты и выдаёт строку фиксированной длины. Для проверки целостности обычно используют SHA-256 или SHA-512. Если два значения, рассчитанные одним алгоритмом, полностью совпали, соответствующие наборы байтов с чрезвычайно высокой вероятностью одинаковы. Изменение имени файла не влияет на результат, а изменение хотя бы одного байта почти наверняка создаёт другую строку.

Сначала точно определите объект. Файл backup.img, физический SSD, один раздел этого SSD и папка с извлечёнными файлами — четыре разных набора данных. Их контрольные суммы не обязаны совпадать. Даже если образ был записан на накопитель без ошибок, хэш всего устройства может отличаться из-за иной ёмкости, таблицы разделов, выравнивания или записанных после запуска служебных данных.

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

Контрольная сумма не показывает исправность диска. Накопитель может стабильно прочитать текущие данные и получить правильный SHA-256, но иметь растущее число ошибок SMART. И наоборот, новый пустой диск не имеет эталонного хэша для сравнения. Вопрос как проверить новый жесткий диск решается осмотром SMART, тестом поверхности и пробной записью с чтением, а не одной контрольной суммой.

Проверка образа и его копии в Windows

В Windows 10 и Windows 11 встроенная команда PowerShell Get-FileHash работает с файлами. Откройте Терминал и вычислите SHA-256 исходного образа:

```text

Get-FileHash -Algorithm SHA256 "D:\Images\backup.img"

```

После копирования выполните ту же команду для файла на другом накопителе:

```text

Get-FileHash -Algorithm SHA256 "E:\Archive\backup.img"

```

Сравнивайте всю строку Hash. Алгоритм в обеих командах должен быть одинаковым. Регистр букв в шестнадцатеричной записи не важен, но пропуск хотя бы одного символа недопустим. Размеры файлов также должны совпадать, хотя одинаковый размер сам по себе не подтверждает одинаковое содержимое.

Автоматизировать сравнение можно без ручного просмотра длинных строк:

```text

$a = (Get-FileHash -Algorithm SHA256 "D:\Images\backup.img").Hash

$b = (Get-FileHash -Algorithm SHA256 "E:\Archive\backup.img").Hash

$a -eq $b

```

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

Альтернативная встроенная команда выглядит так:

```text

certutil -hashfile "E:\Archive\backup.img" SHA256

```

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

Get-FileHash предназначен для файлов, а не для безопасной работы с физическими устройствами вида PhysicalDrive. Для всего диска в Windows лучше применять проверенную программу создания образов с функцией верификации или профессиональный форензик-инструмент. Он должен открывать источник только для чтения, фиксировать размер и считать хэш по тому же потоку данных, который записывается в образ.

Хэш физического диска в Linux и macOS

В Linux блочное устройство можно последовательно прочитать командой sha256sum, но сначала необходимо безошибочно определить его имя через lsblk, размер и модель. Пример чтения всего устройства:

```text

sudo sha256sum /dev/sdX

```

sdX — условное обозначение, его нельзя копировать буквально. Команда хэширования только читает выбранное устройство, однако ошибка в соседней команде клонирования способна уничтожить данные. Для важного источника загрузитесь с отдельного носителя, отключите автоматическое монтирование и по возможности используйте аппаратную защиту от записи.

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

В macOS устройства видны через diskutil list. Для последовательного чтения может использоваться сырой путь /dev/rdiskN, но номер нужно определить по модели и объёму. Встроенная команда SHA-256 для файла образа безопаснее и проще:

```text

shasum -a 256 "/Volumes/Archive/backup.img"

```

Прямая работа с устройством требует прав администратора и понимания структуры дисков. Если цель — подтвердить копию, не усложняйте процедуру: вычислите сумму исходного файла и файла назначения. Это даёт проверяемый результат на любой операционной системе, поскольку SHA-256 зависит от байтов, а не от имени тома.

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

Почему суммы диска и образа различаются

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

Форматирование меняет служебные структуры. Монтирование записываемой файловой системы тоже может обновить журнал, счётчик подключений или время. После загрузки клонированной системы Windows изменяет реестр, журналы событий и временные файлы. Поэтому сравнение всего диска нужно выполнять до первого запуска копии и при неизменяемом источнике.

Накопители разной ёмкости имеют разное число секторов. Если небольшой диск клонирован в начало более крупного, данные разделов могут совпадать, но хэш всего большого устройства включает дополнительное пространство. Сравнивайте область одинаковой длины профессиональным инструментом либо хэшируйте созданный файл образа до и после передачи.

Некоторые программы резервного копирования сжимают данные, пропускают свободные блоки и сохраняют метаданные в собственном контейнере. Такой файл нельзя сравнивать с физическим диском простым SHA-256. Используйте встроенную проверку архива программы, а для контроля переноса самого контейнера дополнительно сравните его файловый хэш.

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

Как построить надёжную процедуру проверки

До копирования запишите имя объекта, точный размер, алгоритм и исходный SHA-256. Сохраните результат отдельно от проверяемого носителя, например в журнале задания. Если эталон находится только рядом с копией на том же повреждённом диске, при отказе могут потеряться и данные, и возможность их проверить.

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

Не используйте MD5 или SHA-1 для доказательства защиты от намеренной подмены: у этих алгоритмов известны коллизии. Они могут обнаруживать случайные ошибки в старом процессе, если другого эталона нет. Для нового журнала выберите SHA-256. Сам хэш также нужно получать по доверенному каналу, когда вы сравниваете скачанный файл с публикацией автора.

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

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

FAQ