Как проверить, что архив не изменился после обновления системы
После обновления Windows, macOS или Linux ноутбук может выглядеть исправным, а папка с архивом — оставаться на привычном месте. Но из этого нельзя заключать, что все документы, фотоархивы и проекты сохранились без изменений. Особенно опасно полагаться только на размер папки или дату последнего изменения: файл может поменяться, сохранив имя и приблизительный объём. Чтобы получить проверяемый ответ, нужно сравнить содержимое с состоянием, зафиксированным до обновления.
Этот материал относится к архивам, которые предполагается хранить неизменными: старым фотографиям, экспортам переписки, сканам, завершённым проектам. Если папка продолжает активно редактироваться, изменения будут ожидаемыми, и для неё потребуется версионное резервирование, а не простая проверка неизменности.
Что подготовить до установки обновлений
Сначала определите границы архива. Запишите полный путь к каталогу, выбранные подпапки и исключения. Например, в архиве фотографий могут быть оригиналы RAW, JPEG, файлы XMP с метаданными и отдельная база каталога фоторедактора. Проверять только изображения недостаточно, если для восстановления работы необходимы связанные файлы.
Проверьте, нет ли фоновых процессов, которые меняют архив: синхронизатор облака, индексатор с записью служебных файлов, фотоприложение, торрент-клиент или автоматическая переименовка. Закройте программы, которые действительно редактируют проверяемые документы, либо зафиксируйте список ожидаемых изменений. Не обязательно выключать всю систему: цель — создать воспроизводимый снимок состава и содержимого.
Перед обновлением сделайте независимую резервную копию на внешний накопитель или в другое доверенное хранилище. Список контрольных сумм не восстанавливает повреждённые файлы; он только помогает обнаружить отличие. Саму копию желательно проверить выборочным открытием файлов и на время обновления отключить от ноутбука. Не храните единственный резервный экземпляр на том же SSD, где будет обновляться система.
Что именно фиксировать в контрольном списке
Для каждого обычного файла полезно сохранить относительный путь внутри архива, размер и SHA-256. Относительный путь необходим, чтобы сопоставить материалы даже после переноса папки на другой диск. Одни только контрольные суммы не выявляют исчезновение файла, если вы не знаете, какие имена входили в исходный набор. Отдельно запишите дату формирования списка, используемый инструмент, путь к корню архива и число элементов.
Пример условного списка:
photos/2024/trip/001.jpg 14A... (пример, не реальная SHA-256)
docs/inventory.xlsx 93B... (пример, не реальная SHA-256)
Реальная SHA-256 состоит из 64 шестнадцатеричных символов; эти сокращённые значения показывают только идею. Для автоматической проверки сохраняйте полный результат утилиты без редактирования формата. Файл со списком сумм положите за пределами проверяемой папки: иначе он сам окажется частью архива, который вы пытаетесь зафиксировать.
Windows: контроль одного файла через PowerShell
Откройте PowerShell и выполните команду для выбранного файла; путь и имя подставьте свои:
Get-FileHash -LiteralPath 'D:\Archive\photos\001.jpg' -Algorithm SHA256
Результат содержит алгоритм, полный хеш и путь. Скопируйте хеш в отдельный журнал до обновления. После перезагрузки повторите эту же команду для того же файла и сравните значения. Совпадение говорит, что считанные байты совпадают с зафиксированной версией при допущении корректной работы средств проверки.
Если файлов много, не копируйте хеши вручную по одному. Сформируйте таблицу путей и значений SHA-256 с помощью сценария PowerShell либо доверенной локальной программы контроля целостности. До запуска массового сценария проверьте его на небольшом тестовом каталоге, где есть пробелы в названиях, кириллица и вложенные папки. Для Windows предпочтительно использовать -LiteralPath, когда в именах встречаются символы, которые оболочка может трактовать специально. Команды Get-FileHash и параметры описаны в Microsoft Learn.
Не храните список только в истории PowerShell: она не является надёжным архивом и может быть очищена. Сохраните отдельный файл отчёта вне исходного каталога и вторую копию рядом с вашей независимой резервной копией.
Linux: создать и проверить список SHA-256
Для небольшой выборки в каталоге с обычными именами файлов можно использовать GNU Coreutils:
cd "$HOME/Archive"
sha256sum "photos/001.jpg" "docs/report.pdf" > "$HOME/archive-before.sha256"
После обновления, находясь в том же корне архива, выполните:
sha256sum --check "$HOME/archive-before.sha256"
Утилита сообщит о совпавших файлах и ошибках. Для больших деревьев нужен корректный обход всех подпапок с учётом пробелов, переносов строки в именах и символических ссылок; не используйте наугад конструкцию с разбиением списка по пробелам. Путь к отчёту должен быть доступен после обновления и не попадать в область, которую программа автоматически перезапишет. Синтаксис sha256sum и режим --check документированы в руководстве GNU Coreutils.
Если у каталога сложные права или часть данных принадлежит другим пользователям, не запускайте массовое изменение владельцев ради выполнения проверки. Отметьте объекты, которые не удалось прочитать, и выясните, какое приложение или учётная запись должны иметь к ним доступ.
macOS: проверить контрольный файл через Terminal
На macOS для выбранного файла можно применить shasum с SHA-256:
shasum -a 256 "$HOME/Archive/photos/001.jpg"
Сохраните полный результат вне архива, после обновления выполните ту же команду и сравните хеши. Для подробностей доступна локальная справка Terminal: man shasum. Если нужно проверить весь архив, используйте инструмент, который создаёт устойчивый перечень всех файлов и затем повторно сравнивает его. Не переносите без проверки Linux-скрипт, полагающийся на дополнительные опции GNU: системные утилиты macOS могут иметь другой набор ключей.
Не путайте изменение сведений Finder, сортировки папок или даты открытия с изменением содержимого файла. Хеш не проверяет права доступа, метки Finder и все расширенные атрибуты: для них предусмотрите отдельную проверку, если такие метаданные важны для вашего архива.
Что делать после обновления
Запускайте проверку после того, как система полностью загрузилась, а вы убедились, что смотрите на прежний архив, а не на пустую папку или облачный ярлык. Используйте то же имя алгоритма и исходный список. Отдельно сопоставьте набор путей: файл может пропасть целиком, а новый — появиться, поэтому оценивать только несколько совпавших хешей недостаточно.
Разделите итоги на понятные категории. Совпали — содержимое выбранных файлов не отличается от исходного списка. Не удалось прочитать — возможны права доступа, отключённый внешний диск, онлайн-заглушка или аппаратная ошибка; не объявляйте это изменением байтов до выяснения причины. Хеш не совпал — данные действительно отличаются от контрольной версии; нужно понять, было ли это ожидаемой записью приложения. Файл отсутствует — ищите правильный путь, версии облачной синхронизации или резервную копию, не создавая новый пустой объект поверх прежнего имени.
Если нашлось расхождение, не редактируйте подозрительный файл и не запускайте массовое «исправление» прежде, чем сохраните текущую версию. Попытка переписать источник может скрыть полезные следы. Сравните проблемный объект с независимой копией, проверьте журнал синхронизатора и только затем принимайте решение о восстановлении в отдельную папку.
Почему совпадение сумм не решает все задачи
Контрольная сумма подтверждает совпадение байтов двух версий конкретного файла. Она не доказывает, что архив содержит все нужные документы, что их можно открыть подходящим приложением или что данные доступны другому члену семьи. Поэтому дополните автоматическую проверку чтением нескольких важных файлов, просмотром структуры папок и тестовым восстановлением из резервной копии.
Есть и вопрос доверия к самому списку: если злоумышленник получил право менять и файлы, и исходные хеши, простой повторный расчёт ничего не докажет. Для ценных архивов храните контрольный список отдельно, в защищённом доступом или подписанном виде. Это особенно важно, если проверка нужна не после штатного обновления, а для расследования подозрительной подмены.
Практический итог
Хороший результат выглядит так: перед обновлением создана независимая копия и исходный перечень SHA-256, после обновления проверены пути и содержимое, расхождения объяснены, а итоговый отчёт сохранён отдельно. Если до обновления списка не было, нельзя достоверно доказать неизменность относительно неизвестной прошлой версии одним новым хешем. Тогда точкой сравнения становится проверенная резервная копия или ранее сохранённый снимок.