[sondz7]

Забавно, вчера 26.11 обнаружил, что точек восстановления нет вовсе. Причём, я их не удалял, ОС не перезагружал и дефрагментацию не производил. »

это не подтверждается моим опытом (в т.ч. наблюдением за подопечными ОС) »

[Vadikan]

sondz7, я же сказал

Надо диагностировать и анализировать. »

Вы свою проблему проанализировали и заявили

продержались точки- 3 дня, потом установка официальной macrium reflect free и их больше нет ни одной, »

На основании этой информации (а другой нет) я считаю вашу проблему исчерпанной - причина в стороннем ПО. И в данном случае это неудивительно, потому что Macrium использует VSS для создания резервных копий. В зависимости от сценариев бэкапа, он может "выдавливать" точки восстановления из выделенного VSS пространства. ОС не отдает никакого приоритета хранению своих точек, тут все провайдеры равны.

Именно это и является основным направлением диагностики

А как она должна поступать, когда стороннее ПО сносит точку? Наверное, молча терпеть... Поэтому вам нужно исключить сторонние факторы - удалить стороннее защитное ПО, программы для резервного копирования, очистки и т.д. »

Что характерно, в каждом ответе вам мне приходится повторять сказанное ранее. Вы тратите мое время впустую. И не надо меня троллить, это чревато.

[Andrey_Vladimirovich]

Удивительно, но я немного продвинулся в решении этой проблемы, хотя не понятно, что с этим делать. Дело в том, что Win10 показывает один занимаемый объём точками восстановления, а в реальности он в разы выше. Например, сейчас «Защита системы» сообщает, что занято 472,22 МБт, при этом FAR Manager (я его запустил с системными правами) показывает, что объём двух файлов (на данный момент их всего два) 2 684 420 096 байт, т.е. 2,5 ГБт. Удаляю точки — оба файла пропали и «Защита системы» сообщает, что занято 0 байт. Для сравнения, в Win7 на одном из старых ноутбуков ситуация иная. Защита системы сообщает о 32,12 ГБт, а объём 23-х файлов 35 386 028 032 байт, т.е. 32,9 ГБт.

[Vadikan]

Win10 показывает один занимаемый объём точками восстановления, а в реальности он в разы выше. Например, сейчас «Защита системы» сообщает, что занято 472,22 МБт, при этом FAR Manager (я его запустил с системными правами) показывает, что объём двух файлов (на данный момент их всего два) 2 684 420 096 байт »

Нам не видно, что вы смотрите и видите в FAR. Поэтому ваши выводы невозможно проверить. Впрочем, смысла в этом тоже нет. Есть fsutil, она не ошибается.

[sondz7]

а в реальности он в разы выше »

учитывается еще это http://images.vfl.ru/ii/1606563902/2...a/32469649.png

[Andrey_Vladimirovich]

Нам не видно, что вы смотрите и видите в FAR. Поэтому ваши выводы невозможно проверить. »

Вы шутите? Если вам нужны подтверждения, так и скажите, к чему намёки?
Насчёт FSUtil, я так и не понял, как ей воспользоваться в данном случае? По вашей ссылке вы запускали команду "fsutil volume allocationreport d:" и она показывала занимаемый объём в папке SVI, у меня так не получается. Других команд FSUtil способных показать это я не нашёл. Ну и потом, нам же нужен не весь объём этой папки, а только объём точек восстановления.
Я как-то упустил, что всё что нам нужно в данном случае, это команда "VSSAdmin.exe List ShadowStorage", которую и привёл sondz7 в скриншоте. Вот результат её работы на моей Win10 (создана только одна точка вручную):

Скрытый текст

Код:

C:\WINDOWS\system32>VSSAdmin.exe List ShadowStorage
vssadmin 1.1 - Программа командной строки для администрирования службы теневого копирования томов
(C) Корпорация Майкрософт (Microsoft Corportion), 2001-2013.

Сопоставление хранилища теневой копии
   Для тома: (D:)\\?\Volume{6fbcaae9-0000-0000-0000-100000000000}\
   Том хранилища теневой копии: (D:)\\?\Volume{6fbcaae9-0000-0000-0000-100000000000}\
   Использованный объем хранилища теневой копии: 0 байт (0%)
   Выделенный объем хранилища теневой копии: 0 байт (0%)
   Максимальный объем хранилища теневой копии: 74,5 ГБ (8%)

Сопоставление хранилища теневой копии
   Для тома: (C:)\\?\Volume{6008bdd5-0000-0000-0000-501f00000000}\
   Том хранилища теневой копии: (C:)\\?\Volume{6008bdd5-0000-0000-0000-501f00000000}\
   Использованный объем хранилища теневой копии: 500 МБ (0%)
   Выделенный объем хранилища теневой копии: 2,47 ГБ (1%)
   Максимальный объем хранилища теневой копии: 49,8 ГБ (21%)


C:\WINDOWS\system32>

учитывается еще это »

Спасибо за подсказку, я уже когда-то обращал на это внимание, но забыл.

Вопрос. С чем может быть связано, что использованный объем хранилища теневой копии в разы меньше, чем выделенный объем хранилища теневой копии и нормально ли это?

Обновление. В Win 7 такая же ситуация при создании первой точки. Эксперимент на виртуальной машине:

Скрытый текст

Код:

C:\Windows\system32>VSSAdmin.exe List ShadowStorage
VSSADMIN 1.1 - Утилита теневого копирования тома
(C) Корпорация Майкрософт, 2001-2005.

Сопоставление хранилища теневой копии
   Для тома: (C:)\\?\Volume{442050fa-6c48-11e6-8795-806e6f6e6963}\
   Том хранилища теневой копии: (C:)\\?\Volume{442050fa-6c48-11e6-8795-806e6f6e6963}\
   Использованный объем хранилища теневой копии: 72.078 MB (0%)
   Выделенный объем хранилища теневой копии: 2.281 GB (1%)
   Максимальный объем хранилища теневой копии: 45.703 GB (30%)


C:\Windows\system32>

[Andrey_Vladimirovich]

Vadikan
К вопросу о том, создаются точки восстановления при установке\обновлении "Visual C++ Redistributable Package" и "Acrobat Reader DC" или нет. Вот скриншоты с Win7 x64 Pro:

Скрытый текст

[Vadikan]

Вы шутите? Если вам нужны подтверждения, так и скажите, к чему намёки? »

Нет, не шучу

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

Насчёт FSUtil, я так и не понял, как ей воспользоваться в данном случае? По вашей ссылке вы запускали команду "fsutil volume allocationreport d:" и она показывала занимаемый объём в папке SVI, у меня так не получается. »

В примере не системный диск, поменяйте букву на c: и все получится.

К вопросу о том, создаются точки восстановления при установке\обновлении "Visual C++ Redistributable Package" и "Acrobat Reader DC" или нет. Вот скриншоты с Win7 x64 Pro: »

Я проверил VC++ 2015 - 2019 на 20H1 и сделал вывод, что установщик или API проверяет наличие недавних точек восстановления. В частности:
1. Защита включена, 5% диска, 24-часовой лимит на создание снят, создана точка вручную.
2. Через 10 минут запущен установщик VC++
Результат: новой точки не создано
3. Защита выключена, VC++ удален
4. Защита включена, запущен установщик VC++.
Результат: новая точка создана

[Andrey_Vladimirovich]

Если вы делаете заявление, логично подтвердить его чем-то кроме самого заявления. »

Но ведь это не всегда нужно. А если кому-то нужно, можно попросить дополнить сообщение.

В примере не системный диск, поменяйте букву на c: и все получится. »

Естественно, я в этой команде использовал буку "С". Впрочем, действительно, я ошибся (сам не понимаю, куда я смотрел в прошлый раз?), есть там информация о папке SVI. Но ведь она общая, а нам интересно какой объём занимают только фалы точек восстановления.

Я проверил VC++ 2015 - 2019 на 20H1 и сделал вывод, что установщик проверяет наличие недавних точек восстановления. »

Так это ничего не даёт. Очевидно, что если до установки/обновления ПО была сделана "пустая" ТВ, то и делать ничего не нужно. Попробуйте в первом варианте последовательно установить пакеты обоих разрядностей и получите иной результат.

Можете ответить на вопрос заданный выше. С чем может быть связано, что использованный объём хранилища теневой копии в разы меньше, чем выделенный объем хранилища теневой копии и нормально ли это?

А у меня ещё сюрприз. Оказалось, что архив предыдущей версии Win10 удалён, раньше такого не было и я его удалял "вручную" через очистку диска. И есть подозрение, что это совпало с удалением всех точек восстановления.

[Vadikan]

Так это ничего не даёт. Очевидно »

Очевидно, дальше без меня. Гуд лак.