Как создать резервную копию сертификата файловой системы

Проверяем состояние процесса первоначального шифрования базы

SELECT
db.name,
db.is_encrypted,
dm.encryption_state,
dm.percent_complete,
dm.key_algorithm
FROM sys.databases db JOIN sys.dm_database_encryption_keys dm
ON db.database_id = dm.database_id WHERE db.name = 'MyDatabaseName'

«горячее» сохранение файлов

Большинство резервных копий современных баз данных выполняется путём копирования файлов базы данных без остановки базы. Здесь видны несколько проблем:

Для того, чтобы резервная копия получилась согласованной, у каждой СУБД существует команда, которая сообщает, что начат процесс резервного копирования. Синтаксически эта команда может выглядеть по-разному:

Несмотря на синтаксические различия, процесс подготовки к резервному копированию выглядит одинаково.

Вот как выглядит подготовка к резервному копированию в СУБД с изменяемыми дисковыми структурами, т. е. во всех традиционных дисковых реляционных системах:

1. Запоминается момент начала резервного копирования; резервная копия должна будет содержать журналы базы данных начиная с этого момента.
2. Выполняется контрольная точка, то есть все изменения, которые произошли в страницах данных до запомненного момента, сбрасываются на диск. Это гарантирует, что журналы до момента начала резервного копирования при восстановлении не потребуются.
3. Включается особый режим журналирования: если страница данных изменилась в первый раз после загрузки с диска, то вместо того, чтобы записывать в журнал изменения страницы, база запишет туда страницу целиком. При выполнении подготовительной процедуры все страницы вытесняются на диск, и поэтому при первом изменении блок всегда будет записан в журнал целиком. Но если в процессе резервного копирования страница снова будет вытеснена на диск, то следующее её изменение также приведёт к появлению в журнале полной копии страницы. Это гарантирует, что если вдруг при копировании файла с данными страница получится некорректной, применение журнала сделает его корректной вновь.
4. Блокируется изменение заголовков файлов данных, то есть той его части, изменения которой не отражаются в журналах. Это гарантирует, что заголовок будет скопирован корректно, а потом к файлу данных корректно будут применены журналы.

После того, как все перечисленные выше процедуры выполнены, можно копировать файлы данных средствами операционной системы – cp, rsync и другими. Включение режима резервного копирования снижает производительность базы данных: во-первых, увеличивается объём журналов, а во-вторых, если вдруг в режиме резервного копирования произойдёт сбой, восстановление будет более продолжительным, т. к. заголовки файлов данных не обновляются.

Чем быстрее резервное копирование закончится, тем лучше для базы данных, поэтому здесь уместно применение таких средств как снимок (snapshot) файловой системы или разрыв зеркала (BCV) в дисковом массиве. Одни СУБД (Oracle, PostgreSQL) оставляют администратору возможность самостоятельно выбрать способ копирования, другие (Microsoft SQL Server) предоставляют интерфейс для интеграции собственных утилит резервного копирования с механизмами файловых систем или СХД.

По окончании резервного копирования нужно перевести базу данных обратно в обычное состояние. В Oracle это делается командой ALTER DATABASE/TABLESPACE END BACKUP, в PostgreSQL – вызовом функции pg_stop_backup(), а в других базах – внутренними подпрограммами соответствующих команд или внешних сервисов.

Вот как выглядит временнáя диаграмма процесса резервного копирования:

С базами данных, использующими неизменяемые структуры данных (снимки памяти, LSM-деревья) ситуация проще. Подготовка к резервному копированию состоит из следующих шагов:

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

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

«холодное» сохранение файлов бд

Очевидная идея – остановить базу данных и скопировать все её файлы. Такая резервная копия называется «холодной». Способ крайне надёжный и простой, но у него есть два очевидных недостатка:

Если же «холодное» резервное копирование вас устраивает, нужно помнить что

• «холодная» копия иногда должна включать в себя и журналы. Методы определения журналов, которые должны попасть в «холодную» копию, индивидуальны для каждой СУБД. Например, в Oracle необходимо скопировать так называемые online redo, то есть фиксированное количество журнальных файлов в специальном каталоге, причём даже тогда, когда база остановлена корректно. В PostgreSQL нужно сохранить все журналы начиная с журнала, содержащего последнюю контрольную точку, информация о которой содержится в управляющем файле.
• каталог базы данных может содержать достаточно большие файлы временных табличных пространств, которые не обязательно включать в резервную копию. Кстати, это замечание верно и для «горячего» резервного копирования.

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

USE master
GO 
OPEN MASTER KEY DECRYPTION BY PASSWORD = '123QWEasd';
GO
RESTORE DATABASE MyDatabaseName FROM  DISK = N'd:tempMyDatabaseNameBackup.bak' 
WITH  FILE = 1, NOUNLOAD,  REPLACE,  STATS = 5;

Восстановление на точку

Резервная копия позволяет восстановить состояние базы данных на момент, когда завершилась команда возврата из режима резервного копирования. Однако авария, после которой потребуется восстановление, может произойти в любой момент. Задача восстановления состояния БД на произвольный момент называется «восстановлением на точку» (point-in-time recovery).

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

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

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

Восстановления database master key и сертификата

Эти шаги выполняютсяна сервере, где зашифрованная база данных будет восстановлена из резервной копии.

USE master;
GO  
RESTORE MASTER KEY   
    FROM FILE = 'd:tempMyServerName_DbMasterKey'   
    DECRYPTION BY PASSWORD = '123QWEasd2' --password to decrypt backup
    ENCRYPTION BY PASSWORD = '123QWEasd'; --password to encrypt restored Master Key in the current database.
GO  

USE master; 
GO 
OPEN MASTER KEY DECRYPTION BY PASSWORD = '123QWEasd';
GO
CREATE CERTIFICATE MyServerName_SqlTdeMasterKeyCert
FROM FILE = 'd:tempMyServerName_SqlTdeMasterKeyCert.cer'     
WITH PRIVATE KEY (FILE = 'd:tempMyServerName_SqlTdeMasterKey.pvk', 
DECRYPTION BY PASSWORD = '123QWEasd3')

Вручную сохранить в надежном месте секретные ключи или qr-коды

Одноразовые коды в приложении-аутентификаторе создаются на основе секретного ключа. Его генерирует сервис, когда вы включаете аутентификацию с помощью приложения. Этот ключ представляет собой случайное сочетание 16 символов, и он же закодирован в QR-коде, который сервис предлагает вам отсканировать.

В принципе, секретный ключ можно даже выучить наизусть, но проще всего будет сохранить его в каком-нибудь надежном месте. Например, для этого подойдут защищенные заметки в менеджере паролей. Альтернативный вариант представления того же секретного ключа, QR-код, можно сохранить в виде изображения и также поместить в защищенное хранилище Kaspersky Password Manager, но уже в виде картинки.

Если вам когда-нибудь понадобится восстановить аутентификатор, вы просто отсканируете приложением QR-код или введете вручную 16 символов секретного ключа.

Выгрузка данных

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

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

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

Тем не менее, у выгрузки есть и достоинства:

Таким образом, выгрузка используется в основном для таких задач как резервирование небольших таблиц (например, справочников) или распространение наборов данных с очередным релизом приложения.

Самым же распространённым методом резервного копирования баз данных является копирование файлов базы.

Запускаем процесс шифрования базы

USE MyDatabaseName;  
GO  
ALTER DATABASE MyDatabaseName SET ENCRYPTION ON;  
GO

Инкрементальное резервное копирование

Чтобы ускорить восстановление на точку, хотелось бы иметь возможность выполнять резервное копирование как можно чаще, но при этом не занимать лишнего места на дисках и не нагружать базу задачами резервного копирования.

Решение задачи – инкрементальное резервное копирование, то есть копирование только тех страниц данных, которые изменились с момента предыдущего резервного копирования.Инкрементальное резервное копирование имеет смысл только для СУБД, использующих изменяемые структуры данных.

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

К сожалению, единой терминологии не существует, и разные производители используют разные термины:

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

Наличие кумулятивной копии ускоряет процесс восстановления. Так, например, для восстановления состояния базы на точку между T3 и T4 необходимо восстановить две инкрементальных копии, а для восстановления на точку после T4 – только одну.

Очевидно, что объём одной кумулятивной копии меньше, чем объём нескольких дифференциальных копий, потому что некоторые страницы изменились по несколько раз, и каждая инкрементальная копия содержит свою версию страницы.

Есть три способа создания инкрементальной копии:

1. создание полной копии и вычисление разницы с предыдущей полной копией;
2. разбор журналов, создание списка изменённых страниц и резервирование страниц, включённых в список;
3. запрос изменённых страниц в базе данных.

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

Задачу экономии дискового пространства при таком подходе лучше переложить на специальные компоненты со встроенными механизмами дедупликации. Это могут быть как специальные СХД (EMC DataDomain, HPE StorageWorks VLS, вся линейка NetApp), так и программные продукты (ZFS, Veritas NetBackup PureFile, Windows Server Data Deduplication).

Использовать облачную синхронизацию приложения-аутентифкатора

Большинство популярных приложений-аутентификаторов — за исключением Google Authenticator — предлагает возможность хранения секретных ключей в облаке и автоматической синхронизации аутентификаторов на разных устройствах. Однако в этом методе есть минус: в приложении-аутентификаторе придется завести учетную запись, а для этого обычно требуется поделиться с его создателями номером телефона или адресом электронной почты.

В случае Microsoft Authenticator можно воспользоваться учетной записью Microsoft, если она у вас есть (если нет — придется завести). Кроме того, следует иметь в виду один нюанс: Microsoft Authenticator для iOS сохраняет резервную копию в iCloud, а версия для Android — в какое-то другое не уточняемое создателями облако.

Поэтому бэкапы получаются несовместимы: если вы пользовались айфоном, но решили перейти на Android (или наоборот), то восстановить бэкап Microsoft Authenticator не получится. Придется заново заводить токены для всех аккаунтов в новой версии приложения.

Как создать резервную копию сертификата файловой системы

Резервное копирования database master key и сертификата (с закрытым ключом)

Шаги ниже используются для бэкапа Database Master Key и сертификата, чтобы потом при необходимости восстановить их перед тем, как восстанавливать зашифрованную базу данных из бэкапа.

USE master;   
GO  
OPEN MASTER KEY DECRYPTION BY PASSWORD = '123QWEasd';   

BACKUP MASTER KEY TO FILE = 'd:tempMyServerName_DbMasterKey'   
    ENCRYPTION BY PASSWORD = '123QWEasd2';
GO

USE master; 
GO 
BACKUP CERTIFICATE MyServerName_SqlTdeMasterKeyCert
TO FILE = 'd:tempMyServerName_SqlTdeMasterKeyCert.cer'
WITH PRIVATE KEY
(FILE = 'd:tempMyServerName_SqlTdeMasterKey.pvk',
ENCRYPTION BY PASSWORD = '123QWEasd3')

Создаем database master key в базе [master]

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

USE master;  
GO  
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '123QWEasd';
GO

Создаем ключ шифрования database encryption key (dek) в базе данных

USE MyDatabaseName;
GO  
CREATE DATABASE ENCRYPTION KEY WITH ALGORITHM = AES_128  
ENCRYPTION BY SERVER CERTIFICATE MyServerName_SqlTdeMasterKeyCert;  
GO  

Создаем сертификат, которым будет зашифрован ключ шифрования базы данных: database encryption key (dek)

Этот сертификат будет использован для шифрации DEK, который будет расположен в шифруемой базе и которым база будет зашифрована

USE master;  
GO  
CREATE CERTIFICATE MyServerName_SqlTdeMasterKeyCert WITH SUBJECT = 'MyServerName_SqlTdeMasterKeyCert';  
GO

Траблшутинг при включении tde

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

DBCC TRACEON(5004)
GO
DBCC TRACEOFF(5004)
GO
ALTER DATABASE MyDatabaseName
SET ENCRYPTION ON

Установить приложение-аутентификатор сразу на несколько устройств

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

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

• Установить аутентификатор на несколько устройств сразу можно разными способами:
• Одновременно сканировать QR-коды (или вводить секретные ключи) двумя смартфонами.
• Отсканировать ранее сохраненные коды вторым устройством.
• Воспользоваться облачной синхронизацией в большинстве приложений (кроме Google Authenticator).
• Экспортировать токены из Google Authenticator на одном смартфоне и импортировать на втором.

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

Шифрование резервных копий в sql server 2021

Экспортировать сертификат и ключ полученный через win-acme | блог сисадмина

Экспортировать уже заведенные в аутентификаторе токены

По какой-то совершенно непонятной причине функция экспорта и импорта уже заведенных в приложение токенов есть только в одном аутентификаторе из всех, которые мы проверили, — это Google Authenticator.

Вероятно, разработчики других приложений считают, что их облачная синхронизация эту функцию успешно заменяет. Отчасти это так. Но облако никак не поможет тем, кто уже пользуется Google Authenticator и хотел бы попробовать альтернативу, быстренько перенеся уже имеющиеся токены в новое приложение. Почему-то создатели альтернативных аутентификаторов совершенно не пытаются упростить жизнь таким «перебежчикам».

Так или иначе, в Google Authenticator сохранять токены очень легко и удобно: достаточно нажать на три точки в верхней части экрана, выбрать «Экспорт аккаунтов» и отметить нужные учетные записи. После этого на экране появится огромный QR-код, в котором содержатся все выбранные токены сразу. Остается просто сделать скриншот и сохранить картинку в защищенном хранилищеменеджера паролей.