В конце июня 2026 года в Windows 11 начали постепенно раскатывать новую функцию: точки восстановления к определённому моменту времени (point in time restore, PITR). Старт дали предварительным обновлением KB5095093, а массовая доставка произошла в сентябре с выходом KB5124008. И уже на следующий день от Piter Pen в чат прилетел вопрос с картинкой:
Из старого интерфейса точек как бы и нет (ибо использованное пространство 0%), но точка таки есть, и даёт возможность на неё откатиться. В новых настройках наоборот — использовано 1,5 гб, но точек нет.
Я разберу этот скриншот, а потом и свой, но сначала база.
[+] Сегодня в программе
- Моё сравнение типов точек и официальная документация
- UI: гадание по скриншоту
- Какие точки восстановления включены в зарезервированное пространство
- Документация Microsoft
- Точки восстановления
- Зарезервированное пространство
- Практический смысл резервирования точек
- Создание точек PITR вручную и по своему расписанию
- Заключение
Моё сравнение типов точек и официальная документация
Когда PITR впервые появилась в инсайдерской сборке, я проводил сравнение классических и новых точек восстановления.
Тогда же Microsoft опубликовала документацию, которую расширила летом 2026 года, готовясь к выпуску в стабильную сборку. Главное дополнение я тоже сегодня разберу.
UI: гадание по скриншоту
Вернёмся к скриншоту с вопросом.
Классические окна слева — это точки восстановления System Restore (SR), а справа — новые точки PITR.
В параметрах каждого типа точек приведённые значения текущего и максимального использования относятся не к данному типу, а ко всем теневым копиям сразу! Эти же сведения выдает команда
vssadmin list shadowstorage.
Это неочевидно, но сразу многое проясняет! Справа моментальные снимки отсутствуют, потому что в данном случае ещё не прошло и суток с момента появления фичи в системе. А 1.5 GB заняты классической точкой восстановления!
Путаницу привнёс второй вид точек. Хотя не исключаю, что в параметрах защиты системы подобные нестыковки могли видеть владельцы программ для резервного копирования, опирающихся на теневые копии. Сейчас неясность в UI можно было разрулить, показывая наряду с текущей картиной потребление только конкретным типом точек. В Microsoft об этом не подумали или решили не усложнять.
Однако двум другим странностям у меня нет объяснения:
- в настройках защиты системы занято 0 байт при живой точке восстановления
- максимальное использование у классики 9.54 GB, а у PITR — 8 GB
У меня такого не наблюдалось, и на скриншоте из моей системы вы увидите нормальную картину. Значение текущего использования может слегка не совпадать, потому что в разных окнах отличается число знаков после запятой. Процент максимального использования тоже может быть неодинаковый, поскольку у PITR в ползунке шаг 0.4% процента. Но это всё объяснимые погрешности.
Так или иначе, для точной оценки суммарного пространства, выделенного для теневых копий и задействованного ими, следует обращаться к первоисточнику: vssadmin list shadowstorage. Отчет команды выглядит примерно так:
Shadow Copy Storage association
For volume: (C:)\\?\Volume{832c4a5c-87a4-4c7f-ba02-fe7c183f6e97}\
Shadow Copy Storage volume: (C:)\\?\Volume{832c4a5c-87a4-4c7f-ba02-fe7c183f6e97}\
Used Shadow Copy Storage space: 2.95 GB (2%)
Allocated Shadow Copy Storage space: 3.31 GB (2%)
Maximum Shadow Copy Storage space: 6.30 GB (5%)
Теперь давайте рассмотрим отдельные точки восстановления.
Какие точки восстановления включены в зарезервированное пространство
Когда в 2019 году в Windows появилось зарезервированное пространство, информация о нем была отрывочная, а документация отсутствовала вовсе. Поэтому я опубликовал в блоге FAQ | Зарезервированное пространство, собрав там все известные мне сведения. Спустя год я добавил в материал информацию о появившихся ключах DISM и командлетах PowerShell, и больше не возвращался к этой теме.
Документация Microsoft
В документации PITR мое внимание привлекли сведения о связи новых точек с зарезервированным пространством. Это добавили перед выпуском фичи в стабильную сборку. Например, такой абзац (привожу их автоперевод с моими лёгкими правками).
Точки восстановления включаются в зарезервированное системой хранилище. Зарезервированное хранилище используется только в том случае, если на устройстве мало свободного места на диске. Если требуется место, точки восстановления вытесняются из зарезервированного хранилища и остаются в системе, если для них достаточно свободного места. Если свободного места недостаточно, точки восстановления удаляются, начиная с самой старой.
Подчёркнуто мной, и тут непонятно, где именно требуется место. Видимо, в зарезервированном хранилище. Но не суть.
В документе также появилось сравнение PITR и SR по ряду параметров, включая нагрузку на дисковое пространство. Здесь я оставлю на память скриншот на английском языке.
Из выделенной строки следует, что в зарезервированное хранилище включаются только новые точки PITR. Что же касается пониженного влияния на дисковое пространство, то здесь есть мелкая подмена понятий. Конечно, с точки зрения разработчиков, они не забирают дополнительное пространство, раз оно уже зарезервировано. Но изначально-то резерв образуется за счет свободного места на диске.
Я верю документации Microsoft. Но также люблю проверять заявления компании :) Давайте посмотрим, действительно ли точки восстановления отражаются в зарезервированном пространстве и какие именно: только PITR или также SR.
Точки восстановления
Это скриншот из моей системы. Здесь наряду с графическим интерфейсом я вывел набор сведений из командной строки.
У меня две теневые копии: верхняя — точка SR, нижняя — PITR. Это просматривается не только по датам создания в графическом интерфейсе, но и по свойству Type в выводе vssadmin.
Точки восстановления представлены в NTFS цельными файлами. Оба типа точек хранятся в корне папки System Volume Information с именами вида {GUID}{GUID}. Это видно по списку файлов (команда выполняется от имени SYSTEM)
dir "c:\System Volume Information\" -Force -File | where name -match '}{' | select name,length,creationtime
Name Length CreationTime
---- ------ ------------
{2ceb3bbc-ac68-11f1-b845-3c77e6ed0d46}{3808876b-c176-4e48-b7ae-04046e6cc752} 2762833920 9/9/2026 7:19:27 PM
{2ceb5962-ac68-11f1-b845-3c77e6ed0d46}{3808876b-c176-4e48-b7ae-04046e6cc752} 3221225472 9/10/2026 2:01:57 PM
Сведения также отражены в отчете утилиты diskusage, хотя она почему-то показывает путь относительно корня диска.
diskusage /systemFile:10 /humanReadable
----------------Top 10 System Files---------------
SizeOnDisk File path
3,221,225,472 ( 3.0 GB) C:\{2ceb5962-ac68-11f1-b845-3c77e6ed0d46}{3808876b-c176-4e48-b7ae-04046e6cc752}
2,762,833,920 ( 2.6 GB) C:\{2ceb3bbc-ac68-11f1-b845-3c77e6ed0d46}{3808876b-c176-4e48-b7ae-04046e6cc752}
...
Размеры файлов плюс-минус совпадают. Но надо учитывать, что с течением временем объём может меняться в обе стороны, и весьма существенно. Это происходит в связи с изменениями в файлах операционной системы, поскольку точки содержит дифференциальную информацию относительно живого тома. Измененные секторы сохраняются в теневых копиях, чтобы снимок продолжал соответствовать старому состоянию. Этот механизм называется copy-on-write, и он уже всплывал в блоге.
Зарезервированное пространство
Объем данных в зарезервированном пространстве раньше можно было посмотреть в Параметрах, но осенью 2026 года в Windows 11 я этого раздела не нашел. Утилита diskusage тоже наврала.
Истинную картину показала утилита fsutil, однако не сразу после создания точек!
Видимо, системе требуется какое-то время, чтобы отразить точки восстановления в зарезервированном пространстве.
fsutil storagereserve query C: Reserve ID: 1 Flags: 0x00000001 Space Guarantee: 0xa0000000 (2560 MB) Space Used: 0x164ad8000 (5706 MB) Reserve ID: 2 Flags: 0x000000a0 Space Guarantee: 0x60000000 (1536 MB) Space Used: 0xd5396000 (3411 MB) Reserve ID: 3 Flags: 0x00000001 Space Guarantee: 0x0 (0 MB) Space Used: 0x0 (0 MB)
Здесь любопытно, что в зонах 1 и 2 используемое место превышает зарезервированное. Объем первой зоны 5.7 GB, и это очень близко к суммарному объёму точек восстановления. Но мы можем выяснить наверняка!
Имена файлов с точками восстановления должны находиться в списке файлов зон зарезервированного пространства. Содержимое каждой зоны легко вывести в отдельный текстовый файл.
1..3 | ForEach-Object { fsutil storagereserve findbyID C: $_ > "c:\temp\id$_.txt" }
У меня список файлов в зоне 1 уложился всего в 3 kb. Зона 2 содержит все остальные файлы, а их сводка потянула уже на 22 MB. Содержимое зоны 1 целиком:
********* File 0x001b000000019396 *********
File reference number : 0x001b000000019396
File attributes : 0x00000026: Hidden | System | Archive
File entry flags : 0x00000000
Link (ParentID: Name) : 0x000200000000b201: DOS Name : {2CEB3~1
Link (ParentID: Name) : 0x000200000000b201: NTFS Name : \System Volume Information\{2ceb3bbc-ac68-11f1-b845-3c77e6ed0d46}{3808876b-c176-4e48-b7ae-04046e6cc752}
Creation Time : 9/9/2026 16:19:27
Last Access Time : 9/10/2026 11:01:58
Last Write Time : 9/10/2026 11:01:58
Change Time : 9/10/2026 11:01:58
LastUsn : 19,508,781,056
OwnerId : 0
SecurityId : 2063
StorageReserveId : 1
Stream : 0x010 ::$STANDARD_INFORMATION
Attributes : 0x00000000: *NONE*
Flags : 0x0000000c: Resident | No clusters allocated
Size : 72
Allocated Size : 72
Stream : 0x030 ::$FILE_NAME
Attributes : 0x00000000: *NONE*
Flags : 0x0000000c: Resident | No clusters allocated
Size : 82
Allocated Size : 88
Stream : 0x030 ::$FILE_NAME
Attributes : 0x00000000: *NONE*
Flags : 0x0000000c: Resident | No clusters allocated
Size : 218
Allocated Size : 224
Stream : 0x080 ::$DATA
Attributes : 0x00000000: *NONE*
Flags : 0x00000012: Pinned | Has Parsed Information
Size : 2,762,833,920 (2.6 GB)
Allocated Size : 2,762,833,920 (2.6 GB)
Vdl : 0 (0.0 KB)
Extents : 13 Extents
********* File 0x003e000000031517 *********
File reference number : 0x003e000000031517
File attributes : 0x00000026: Hidden | System | Archive
File entry flags : 0x00000000
Link (ParentID: Name) : 0x000200000000b201: DOS Name : {2CEB5~1
Link (ParentID: Name) : 0x000200000000b201: NTFS Name : \System Volume Information\{2ceb5962-ac68-11f1-b845-3c77e6ed0d46}{3808876b-c176-4e48-b7ae-04046e6cc752}
Creation Time : 9/10/2026 11:01:57
Last Access Time : 9/11/2026 6:01:59
Last Write Time : 9/11/2026 6:01:59
Change Time : 9/11/2026 6:01:59
LastUsn : 19,526,384,456
OwnerId : 0
SecurityId : 2063
StorageReserveId : 1
Stream : 0x010 ::$STANDARD_INFORMATION
Attributes : 0x00000000: *NONE*
Flags : 0x0000000c: Resident | No clusters allocated
Size : 72
Allocated Size : 72
Stream : 0x030 ::$FILE_NAME
Attributes : 0x00000000: *NONE*
Flags : 0x0000000c: Resident | No clusters allocated
Size : 82
Allocated Size : 88
Stream : 0x030 ::$FILE_NAME
Attributes : 0x00000000: *NONE*
Flags : 0x0000000c: Resident | No clusters allocated
Size : 218
Allocated Size : 224
Stream : 0x080 ::$DATA
Attributes : 0x00000000: *NONE*
Flags : 0x00000012: Pinned | Has Parsed Information
Size : 3,221,225,472 (3.0 GB)
Allocated Size : 3,221,225,472 (3.0 GB)
Vdl : 0 (0.0 KB)
Extents : 13 Extents
Для начала обратите внимание на значение атрибутов Creation Time и Last Write Time у файлов теневых копий. Создание второй точки совпало с последней записью в первую. Это — механизм copy-on-write в действии, а PITR и System Restore слаженно работают клиентами VSS. Но вернемся к резервированию.
В зоне 1 содержится всего два файла: как раз с точками восстановления! Первая точка классическая, а вторая – PITR, поэтому можно говорить о том, что в зарезервированное пространство включают оба типа точек восстановления. Вопреки написанному в документации Microsoft. Но есть нюанс ©
Наряду со своими системами я изучал отчеты участников чата @winsiders. В итоге сложилась однозначная картина: в Windows 10 и в Windows 11 без функции PITR классические точки не попадают в зарезервированное хранилище. Например, ниже две точки System Restore занимают 5.2 GB, но в резерве лишь 487 MB временных файлов.
diskusage /systemFile:2 /humanReadable
----------------Top 2 System Files---------------
SizeOnDisk File path
3,870,658,560 ( 3.6 GB) C:\{f7ddad43-96ef-11f1-bb8c-00155d019f0d}{3808876b-c176-4e48-b7ae-04046e6cc752}
1,677,721,600 ( 1.6 GB) C:\{c2ac86ad-ae89-11f1-bb8e-00155d019f0d}{3808876b-c176-4e48-b7ae-04046e6cc752}
fsutil storagereserve query C:
Reserve ID: 1
Flags: 0x00000001
Space Guarantee: 0x153d6e000 (5437 MB)
Space Used: 0x0 (0 MB)
Reserve ID: 2
Flags: 0x000000a0
Space Guarantee: 0x60000000 (1536 MB)
Space Used: 0x1e711000 (487 MB)
Reserve ID: 3
Flags: 0x00000001
Space Guarantee: 0x0 (0 MB)
Space Used: 0x0 (0 MB)
Разработчики по-своему правы: пока нет PITR, точки System Restore не вносятся в зарезервированное пространство.
Однако, когда фича доставлена, причём даже если точки PITR отключены, теневые копии начинают размещаться в зарезервированном хранилище. И соответственно, туда попадают уже оба типа точек!
Таким образом, формулировка в документации PITR технически неверная. Понятно, что хотели подчеркнуть преимущество новой технологии. Но при этом вновь не погнушались подменой понятий.
И ещё один любопытный нюанс. В 2019 году я писал, что Microsoft не раскрывает назначение резервных зон, а со слов разработчиков — не привязывает их к конкретным операциям обслуживания. И действительно, я ранее не находил паттернов. Однако теперь во всех отчетах наблюдается чёткое разделение: в одной зоне только теневые копии, а в остальных — разные временные файлы.
Практический смысл резервирования точек
Здесь все вполне очевидно. Но я специально отрядил под этот тезис отдельный блок статьи – для любителей отключать всякие ненужные нововведения Windows.
Когда точка восстановления находится в зарезервированном пространстве, выше вероятность, что она будет доступна в критический момент
Создание точек PITR вручную и по своему расписанию
По задумке разработчиков точки должны создаваться только автоматически. При этом управление частотой и длительностью хранения активно в графическом интерфейсе лишь у корпоративных изданий. Однако есть простой обходной путь.
Точки создаются от имени SYSTEM с помощью запланированного задания PITRTask в разделе \Microsoft\Windows\Setup.
У задания два триггера: при запуске системы и ежедневно в определённое время. Но есть нюанс © В условиях прописано дожидаться бездействия системы в течение двух минут. Другими словами, если вы запустите задание вручную, всё равно придётся ждать бездействия.
Вы можете дополнить исходное задание своим.
- Щёлкните задание правой кнопкой мыши и экспортируйте в XML.
- Аналогично импортируйте — с другим именем, PITRTaskMod.
- В новом задании удалите триггеры и создайте новые для настройки своего расписания, затем снимите условие бездействия.
Ручной запуск своего задания:
Start-ScheduledTask -TaskName "\Microsoft\Windows\Setup\PITRTaskMod"
Наконец, хранение точек можно продлить до 7 дней, настроив поведение в реестре. В разделе HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup\Recovery\PITR\Settings sоздайте параметр DWORD с именем MaxTimespan_GPO и укажите десятичное значение в минутах в диапазоне от 1440 до 10080.
Заключение
Развитие резервного копирования Windows давно идёт ни шатко, ни валко. Однако Microsoft серьёзно вкладывается в механизмы восстановления при сбоях: Quick Machine Recovery, Point in Time Restore, Cloud Rebuild. Эти технологии появились в последние пару лет.
Средств восстановления набралось так много, что компания даже опубликовала гайд для ИТ-специалистов по выбору подходящего инструмента в зависимости от типа сбоя.
Так или иначе, откат к точке восстановления много лет остаётся самым простым и дешёвым средством вернуть систему к жизни после внезапных неполадок. SR мне нравится тем, что срок жизни точек ограничен лишь объёмом выделенного для теневых копий пространства. На трёх днях PITR далеко не уедешь. Зато тут полный откат, вместе с файлами пользователя.
Если у вас полно свободного места на диске, логично задействовать оба типа точек.
В условиях ограниченного пространства многое зависит от вашей стратегии резервного копирования, а в её отсутствие — от ценности локальных пользовательских файлов. Например, у меня все личные файлы продублированы. Поэтому ценность их присутствия в PITR невелика, зато важнее растянуть временной диапазон отката системы посредством точек SR.
