Windows BackupRead / BackupWrite и ACL

Question

Я пытался понять, каким должен быть правильный способ использования BackupRead и BackupWrite для резервного копирования данных на компьютере и особенно для его надежного восстановления.

Теперь я понимаю, как использовать API, и имеюбыл успешнымОднако есть одна вещь, которая беспокоит меня.Вы можете создавать резервные копии, помимо самого содержимого файла, любые альтернативные потоки данных, а также информацию о безопасности (ACL).

Теперь, если я буду хранить данные ACL для резервного копирования, а затем позже, как только данные должны быть восстановлены надругой компьютер ИЛИ недавно настроенный компьютер, что мне делать с идентификаторами безопасности, связанными с ACL?SID, скорее всего, больше не действителен для машины, и как выбрать правильного пользователя?Теперь я смотрю на это в более широком масштабе. Допустим, это компьютер с несколькими пользователями и сотнями или тысячами объектов с различными настройками. Было бы бесполезно восстанавливать данные с примененными к ним настройками безопасности.

Является ли это чем-то, если пользователь программного обеспечения желает сделать резервную копию настроек безопасности, что пользователь должен принять о себе и соответствующим образом обновить их или что?

Дополнительно BackupRead и BackupWrite предоставят мне необработанный двоичный файлданные тех элементов, которые не слишком сложны в использовании, однако, очевидно, что этот API даже не собирается решать эту проблему.

У кого-нибудь есть идеи, как приложение резервного копирования должно справляться с этой ситуацией?Что вы думаете, или какие-либо указатели на руководящие принципы для этой конкретной темы?

Большое спасибо.

Answer 1

Я думаю, вы правильно понимаете проблемы с резервным копированием и восстановлением данных.Я думаю, что правильное понимание проблемы - это половина ее решения.Я полагаю, что вы, как и большинство пользователей сайта stackoverflow, в основном разработчик программного обеспечения, а не администратор большой сети.Таким образом, вы видите проблему с другой стороны разработчика программного обеспечения, а не со стороны администратора.Администратор знает ограничения резервного копирования и восстановления списков ACL и уже использует их.

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

В большинстве случаев резервные данные имеют доменные группыSID, SID пользователей домена, известные SID или псевдонимы SID из домена BUILTIN в дескрипторах безопасности.В случае, если нужно вообще не менять SID.Если администратор внесет некоторые изменения в ACL, он может использовать различные существующие утилиты, такие как SubInACL.exe .

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

Answer 2

Я верю, что API-интерфейсы резервного копирования * в первую очередь предназначены для резервного копирования и восстановления на одном компьютере, что делает проблему SID неактуальной. Однако, учитывая сценарий, в котором вам необходимо восстановить резервную копию при новой установке, вот мои мысли о решениях.

Для таких известных идентификаторов безопасности, как «Все», «Владелец-создатель» и т. Д., На самом деле проблем не существует.

Для SID, зависящих от домена, вы можете хранить их как есть, а при восстановлении вы можете при необходимости исправить часть домена. Скорее всего, вам следует также хранить доменное имя для таких идентификаторов безопасности.

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

Большинство проблем, связанных с такими SID, можно (и, вероятно, обычно) можно будет решить автоматически. Я, конечно, был бы признателен за приложение для резервного копирования, которое было достаточно умным, чтобы выполнить восстановление, о котором я его просил, и выяснить, что «Эрик» на старой машине также должен быть «Эрик» на новой машине.

И примечание: если вы решите пойти с таким решением, помните, как раздражает начало переноса данных в одночасье, просто чтобы вернуться к тому, что 5% блокировок всплывающего окна могут быть отложены так же легко: )