Резервные копии являются одним из ключей к успешному плану аварийного восстановления. Каждый механизм базы данных имеет свои собственные команды и процедуры резервного копирования, и Microsoft SQL Server не является исключением. SQL Server имеет возможности для полного и разностного резервного копирования, а также процесса резервного копирования для журналов транзакций. Эти процедуры можно использовать в сочетании, чтобы обеспечить ограниченное время простоя в случае сбоя вашей базы данных или критического, неисправимого сбоя.
Полные и дифференциальные резервные копии
Перед созданием резервной копии важно знать различные типы. Существует три типа: полный , дифференциальный и инкрементный. SQL Server поддерживает полное и разностное резервное копирование, но некоторые администраторы неправильно называют разностное резервное копирование «инкрементным». Однако между ними есть четкое различие, и оно влияет на то, как базы данных видят данные резервных копий.
В дополнение к различным типам резервных копий также важно понимать, что резервные копии данных отделены от резервных копий журналов. Данные — это содержимое, хранящееся в базе данных. Журналы — это файлы, которые хранят записи каждой транзакции, выполняемой на сервере. Журналы содержат множество точек данных, включая запросы, выполняемые на сервере, изменения настроек, административные изменения, такие как обновления учетной записи пользователя и события безопасности. Администраторы используют данные аудита для криминалистической экспертизы в случаях утечки данных, но транзакции важны для аварийного восстановления.
Вам также может понравиться: Почему вашему бизнесу требуется резервное копирование базы данных
Полные резервные копии легко объяснить. Эти файлы содержат полный снимок всех данных, содержащихся в базе данных. Полные резервные копии включают в себя структуру таблиц, представлений, триггеров и любых других объектов, настроенных в базе данных. Для всех типов резервного копирования сначала требуется полное резервное копирование, поэтому независимо от выбранной вами процедуры, вы начинаете с этого типа.
Разностные резервные копии делают моментальный снимок всех данных, измененных после первоначального полного резервного копирования. Каждая дифференциальная резервная копия в SQL Server добавляется в исходный файл полной резервной копии. Эти файлы могут становиться достаточно большими, потому что с каждым днем все больше данных изменяется и добавляется в базу данных. Разностные резервные копии являются накопительными от первоначальной полной резервной копии. Большим организациям рекомендуется определять объем данных, который меняется каждую неделю, и делать дополнительные полные резервные копии, чтобы избежать очень больших различий.
Последний тип резервного копирования в мире баз данных является инкрементным. Хотя SQL Server не поддерживает их, вы можете столкнуться с ними в других средах баз данных. Инкрементные резервные копии делают снимок данных, измененных с момента последнего инкрементного копирования. Если инкрементной резервной копии не существует, создается моментальный снимок изменений данных из полной резервной копии. Файлы инкрементных резервных копий намного меньше, поскольку их можно использовать каждые несколько минут для больших серверов баз данных, а изменения данных в течение этих нескольких минут сохраняются.
В средах SQL Server обычно делают полное резервное копирование в начале недели, а затем каждый день делают разность. Этот процесс зависит от размера организации и объема данных, который меняется каждый день. Критические базы данных с большим трафиком могут делать резервные копии каждые 10-15 минут, но базы данных с небольшим трафиком могут нуждаться только в ночных резервных копиях.
Создание полной резервной копии данных и журналов
SQL Server имеет несколько вариантов для полного резервного копирования. Вы можете сжать и зашифровать их. Вы можете указать SQL Server перезаписать старые резервные копии и просто оставить новые на своем носителе. Вы можете указать носитель, на котором вы хотите сохранить резервную копию. Администраторы используют сетевые ресурсы для хранения данных, но эта опция требует большой емкости хранилища. Оптический диск — это еще один вариант, который экономит место в сети и позволяет избежать снижения производительности во время процедур резервного копирования. Однако резервные копии недоступны по сравнению с файлами, хранящимися в сетевых ресурсах, таких как сетевое хранилище (NAS).
Ниже приведен пример оператора резервного копирования SQL Server MSSQL:
MS SQL
xxxxxxxxxx
1
BACKUP DATABASE Store
2
TO DISK = 'D:019-03-11.bak'
3
WITH CHECKSUM;
4
GO
Приведенный выше оператор берет полную резервную копию базы данных «Store» и сохраняет ее на диск. Имя резервной копии — дата. Использование даты в именах резервных копий позволяет администраторам баз данных идентифицировать самую последнюю в серьезных файлах резервных копий.
checksumВариант обеспечивает обнаружение ошибок ввода / вывода. Для каждой созданной резервной копии SQL Server создает checksum значение и записывает его в заголовок резервной копии. checksumПересчитывается , когда резервная копия затем считывается в память. Если значения не совпадают, SQL Server определяет, что резервная копия повреждена. Этот вариант резервного копирования является отличным способом избежать хранения поврежденных резервных копий, которые могут привести к неудачному восстановлению во время аварии.
Безопасность резервных копий важна, потому что они содержат все активы данных. Они также могут занимать огромные объемы пространства для хранения данных, когда они увеличиваются до нескольких сотен гигабайт. Следующая инструкция MSSQL сжимает и шифрует резервную копию:
MS SQL
xxxxxxxxxx
1
BACKUP DATABASE Store
2
TO DISK = 'D:019-03-11.bak'
3
WITH
4
COMPRESSION,
5
ENCRYPTION
6
(
7
ALGORITHM = AES_256,
8
SERVER CERTIFICATE = StoreBackupCert
9
),
10
STATS = 10
11
GO
Чтобы использовать шифрование, вам также необходим сертификат, который используется в операторе резервного копирования. Сертификат, указанный в приведенном выше заявлении StoreBackupCert, и 256-битное шифрование AES. compressionВариант будет сжимать резервные копии , чтобы уменьшить объем пространства , необходимый. stats Опция будет отображать процент завершения на основе этого числа. В приведенном выше заявлении процентный интервал равен 10, поэтому SQL Server будет предоставлять полное обновление для каждых 10% выполненных операций.
Для небольших баз данных процесс резервного копирования очень быстрый. Для больших баз данных администраторы должны выполнять резервное копирование в непиковые часы, поскольку это займет несколько минут и потребует ресурсы как базы данных, так и сервера. Если резервные копии копируются на сетевой диск, это может привести к заметному снижению производительности.
Создание резервной копии для журналов транзакций
Когда вы запускаете предыдущие операторы, резервные копии данных, но не журналы транзакций. База данных синхронизирует транзакции с журналами каждые несколько секунд. В случае сбоя в вашей базе данных может быть запущена транзакция, которая не может быть завершена. Эти транзакции следует откатить и отбросить. Резервное копирование журнала транзакций приведет вашу базу данных к точке восстановления во время сбоя и откат транзакций, которые не были завершены, чтобы избежать повреждения данных.
Оператор MSSQL для резервного копирования журналов аналогичен данным. Пример показан ниже:
MS SQL
xxxxxxxxxx
1
BACKUP LOG Store
2
3
TO DISK = ' D:019-03-11_LOG.bak';
В приведенном выше restore утверждении оператор создает резервные копии журналов в том же месте, что и резервные копии данных, но для имени файла присваивается суффикс «_LOG», чтобы отличать его от данных. Этот суффикс файла облегчает администраторам идентификацию резервных копий данных из журналов. Дата также используется в файле, чтобы указать, когда была сделана резервная копия.
Что дальше?
После того, как вы сделали резервную копию ваших данных и журналов, важно хранить их в надежном месте. Большинство администраторов автоматизируют резервное копирование и сохраняют стоимость нескольких недель, прежде чем архивировать или удалять старые. У вас всегда должно быть не менее двух недель резервных копий, чтобы избежать проблем, если самая последняя повреждена.
Храните данные в безопасности и в безопасном месте. Если вы копируете копии на оптический диск, резервное копирование за пределы площадки снижает риск, если организация пострадает от наводнения или пожара. Облачные резервные копии также являются опцией, и они доступны, если вам нужны резервные копии за пределами сайта. Ваши резервные копии должны быть доступны, но в то же время защищены от атак и бедствий, чтобы соответствовать передовым стандартам для плана аварийного восстановления.
Дальнейшее чтение
Почему ваш бизнес нуждается в резервном копировании базы данных
Резервное копирование базы данных: разговор с экспертом
Как восстановить базу данных SQL Server без резервного копирования