Для целей этого вопроса BitLocker относится к разновидности BitLocker-to-go на диске с отключенным кэшированием записи.
NTFS поддерживает ведение журнала метаданных, которое, хотя и не является полностью безопасным, уменьшает некоторые типы потенциальных ошибок файловой системы.
Предполагая, что том NTFS защищен с помощью BitLocker, это снижает отказоустойчивость? Может ли сбой питания во время записи на том NTFS, защищенный с помощью BitLocker, быть более подверженным повреждению, чем на незашифрованном томе NTFS?
Попытка на примере
(Пропустите это, если это не имеет смысла, сейчас я не могу придумать более краткого объяснения.)
Это абсолютно гипотетически и касается другой системы шифрования (не BitLocker), но демонстрирует возможную точку сбоя при шифровании, и поэтому высказывание "BitLocker невидим для NTFS" не имеет значения. Однако мой вопрос не ограничивается этим примером.
Для простоты предположим, что основной размер блока устройства составляет 8 байт:
| ABCDEFGH |
Третий байт первого блока изменяется, и весь блок перезаписывается:
| ABzDEFGH |
^
Предполагая, что запись не удалась после записи третьего байта, мы в порядке, поскольку ни один из следующих байтов не изменился.
Однако предположим, что блок зашифрован:
| GTWNSDKQ |
Третий байт снова изменяется, но шифр шифрования приводит к тому, что весь остальной блок также изменяется:
| GTx8q1uz |
^^^^^^
Если запись не удалась, мы получили бы что-то вроде:
| GTx8SDKQ |
^^**** - Not all bytes were updated, entire block is now corrupted
Надеюсь, этот пример достаточно прост для понимания. Очевидно, что размер единицы выделения NTFS намного больше, чем 8 байтов, но это демонстрирует гипотетическую проблему.
Повторяющийся вопрос
В какой степени (если вообще) страдает BitLocker от сценария выше или других; что-нибудь, что вводило бы новую точку отказа? Может ли сбой питания во время записи на том NTFS, защищенный с помощью BitLocker, быть более подверженным повреждению, чем на незашифрованном томе NTFS?