В случае удаления важного файла при отсутствии бэкапа можно было рассчитывать на извлечение файла из теневой копии. Точка восстановления была предпоследней надеждой — перед использованием специальных программ или обращением в сервис.
Однако фишка перестала нормально работать в клиентских ОС с какого-то момента, что я освещал в канале Telegram. Сегодня последний эпизод сериала.
[+] Сегодня в программе
В предыдущих сериях
Ранее вышло три эпизода. Это без учета приквела 2009 года про защиту и восстановление системы, где не раз обновлялся раздел про автоматизацию создания точек.
E01 — Как восстановить удаленные файлы и папки из теневых копий в Windows
Статья в блоге, претерпевшая немало фоновых изменений по мере эволюции Windows 8 → 8.1 → 10:
- История вопроса, в том числе исчезновение вкладки «Предыдущие версии» в Windows 8 и ее бесполезное (в нашем контексте) возвращение в Windows 10
- Способы извлечения файлов из теневых копий в Windows 7 и новее
E02 — Проблема с извлечением файлов из теневых копий точек восстановления
Пост в канале Telegram с описанием проблемы.
E03 — Создание рабочих теневых копий с помощью командной строки и планировщика
Пост в канале Telegram с обходным путем (wmic).
E04 — Ответ разработчиков
Во второй серии я занес баг в центр отзывов и даже провел небольшую кампанию в Твиттере по набору голосов. Кстати, мне там указали, что проблема проявлялась еще в Windows 8, что не удивило в свете истории вопроса. Свыше 100 человек проголосовали за баг, но я не особо рассчитывал на ответ и давно думать забыл про это.
Но однажды я просматривал свои старые отзывы и случайно заметил, что тремя месяцами ранее мне ответил сотрудник Microsoft по имени Christian A. Причем написал он просто в комментарии, а не через систему ответов Feedback Hub. Поэтому никаких уведомлений об этом я получить не мог.
Я точно не знаю, является ли этот человек разработчиком. Но его ответ вполне технический, причем написан простым языком. Дальше мой вольный перевод курсивом с комментариями.
Это ожидаемое поведение. Пользовательские файлы не входят в теневые копии, которые создаются механизмом защиты системы. Назначение защиты системы в откате системы и приложений в случае, когда они повреждены установкой ПО. Иначе при восстановлении из точки более свежие файлы затирались бы старыми. Используйте обычный бэкап для сохранения пользовательских файлов.
Здесь вполне здравое объяснение приправлено технически неточным утверждением. Очевидно же, что пользовательские файлы входили и входят в теневую копию, созданную механизмом защиты системы. Да, эти файлы никогда не восстанавливались при откате к точке, чтобы не перезаписывать новые данные. Но наш вопрос и не про штатный откат.
Пожалуй, стоило указать на UI для придания багу веса. Но тогда я счел, что от такого легко отмахиваются или даже исправляют — подумаешь, три слова из строки удалить.
Однако описанное поведение распространяется не только на пользовательские файлы. Системные файлы тоже подвержены! Казалось бы, их восстановление никому не нужно. Однако извлечение бэкапа реестра из теневой копии помогало в случае, когда система не загружается, а откат к точке восстановления не работает.
Кстати, мы не занимаем место файлами, заполненными нулями :-)
Это заявление тоже неверное. Некоторые файлы забиты нулями не полностью, а частично (об этом даже в заголовке баг-репорта написано). Поэтому место на диске они все-таки занимают. Для простоты представьте, что оригинал файла уже удален, но в теневой копии остался файл с ошметками данных. У него есть размер.
Теневая копия использует часть диска в качестве "дифференциальной области". Если файл изменяется после создания теневой копии, старые данные записываются в эту область перед записью новых данных в файл. Когда вы считываете файл из теневой копии, мы сначала читаем данные на "онлайн" томе, потом смотрим на разницу.
Здесь разработчик простыми словами описывает метод copy-on-write (спасибо, Артем). Однако это не объясняет, почему файл в теневой копии забивается нулями, если он не менялся после создания теневой копии.
Например, вы создали текстовый файл, он попал в теневую копию целиком, а потом вы удалили его, не внося никаких изменений. Вполне можно ожидать извлечение файла целым из теневой копии. Как это и работало в прошлом для точек восстановления. И продолжает работать в случае с теневыми копиями, созданными другими способами (API или wmic).
The End
Я закинул свои встречные вопросы в ответный комментарий, но разработчик уже вряд ли их увидит. Так или иначе, мы получили ответ, причем вполне ожидаемый. Как я писал во второй серии, исходя из графического интерфейса, извлечение файлов из теневых копий не поддерживается в клиентских Windows с 2012 года. Поэтому даже если там что-то сломалось, вникать в это никто уже не будет.
Больше не рассчитывайте извлечь целые файлы из теневых копий точек восстановления в клиентских ОС.
This behavior is by design ©
Netod
Помнится кейс когда теневая копия спасала после шифровальщика..
Vadim Sterkin
Да, хороший кейс был :) Но он еще работает, просто не из коробки (E03).
strafer
Эх, вот бы это был опенсорс и можно было бы патчик навалять и пулреквест сделать. Мечты, мечты…