Восстановление зашифрованных SQL-бэкапов после потери сервера

Целая резервная копия может оказаться бесполезной на новом сервере. Если закрытый ключ нужного сертификата существовал только на потерянном экземпляре, одного копирования файла недостаточно. План восстановления должен включать криптографические материалы и проверенный способ использования на другой машине.

Определить фактическую защиту

Различайте явное шифрование резервной копии и Transparent Data Encryption. Первое использует настроенный шифратор бэкапа. TDE защищает базу через ключ шифрования, чей защитник нужен при переносе или восстановлении. Цепочка может зависеть от обоих механизмов.

При сертификатной защите инвентаризируйте сертификаты master и связывайте отпечатки с копиями. Запрос является начальной проверкой, а не доказательством необходимости каждого сертификата для любого файла.

USE master;
SELECT name, thumbprint, expiry_date,
       pvt_key_encryption_type_desc
FROM sys.certificates
WHERE name NOT LIKE '##%'
ORDER BY name;

Сопоставляйте шифратор по реальным метаданным backup или restore. Понятное имя сертификата может различаться между серверами; совпадать должна криптографическая идентичность. Для асимметричного ключа или внешнего провайдера требуется его документированный путь восстановления, а не приведенная схема файлов.

Не считайте, что копия пользовательской базы содержит все для запуска собственной расшифровки. Новый экземпляр должен получить соответствующую защиту и доступ к закрытому ключу до восстановления.

Экспортировать сертификат вместе с закрытым ключом

Шаблон использует существующий сертификат BackupRecoveryDemo. Замените имя, пути и секрет. Каталог должен существовать и быть доступным службе SQL Server. Команда не создает шифратор и не меняет задания резервного копирования.

USE master;
BACKUP CERTIFICATE [BackupRecoveryDemo]
TO FILE = 'D:\KeyExport\BackupRecoveryDemo.cer'
WITH PRIVATE KEY
(
    FILE = 'D:\KeyExport\BackupRecoveryDemo.pvk',
    ENCRYPTION BY PASSWORD = 'REPLACE_WITH_A_UNIQUE_SECRET'
);

Файла .cer недостаточно, когда восстановлению нужен закрытый ключ. Сохраняйте зашифрованный файл ключа и пароль экспорта через контролируемые независимые каналы восстановления. Единственный пароль внутри базы, защищенной тем же отсутствующим ключом, создает циклическую зависимость.

Импорт выполняется в master нового экземпляра. Он предполагает существующий главный ключ базы, доступный уполномоченному оператору. Если его нет, подготовьте это условие явно, не заменяя вслепую уже существующий ключ.

USE master;
CREATE CERTIFICATE [BackupRecoveryDemo]
FROM FILE = 'D:\KeyImport\BackupRecoveryDemo.cer'
WITH PRIVATE KEY
(
    FILE = 'D:\KeyImport\BackupRecoveryDemo.pvk',
    DECRYPTION BY PASSWORD = 'REPLACE_WITH_A_UNIQUE_SECRET'
);

Пароль экспорта расшифровывает файл закрытого ключа при импорте. Это не пароль SQL-входа и не обязательно пароль главного ключа назначения. Разделите роли секретов в инструкции.

После импорта проверьте отпечаток и доступность закрытого ключа. Удалите временные рабочие копии по процедуре, сохранив долговременные материалы восстановления. Настоящие ключи и пароли не должны попадать в задачи, исходный код и общие протоколы.

Проверить независимый путь восстановления

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

Зафиксируйте файлы, отпечатки, получение секретов, права оператора, длительность и достигнутую точку. RESTORE VERIFYONLY дает полезные сведения о копии, но не заменяет завершенное восстановление работающей базы.

Ротация не отменяет зависимость старых сохраненных бэкапов. Храните прежние защитники, пока они нужны хотя бы одной необходимой цепочке. Новая полная копия с новым сертификатом не переписывает старые файлы и уже сохраненные журналы.

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

Техническая документация: Microsoft Learn: BACKUP CERTIFICATE · Microsoft Learn: Backup encryption · Microsoft Learn: Moving a TDE database.