Вы когда-нибудь сталкивались с ситуацией, когда вы потеряли экземпляры и базы данных SQL Server из-за сбоя SAN? Это кошмарный сценарий, который может произойти с любым, даже в непроизводственных средах. В этой статье мы рассмотрим, как вы можете собрать информацию из доступных ресурсов, чтобы определить наилучший подход к восстановлению ваших экземпляров и баз данных SQL Server.
Важность резервного копирования
Прежде чем мы погрузимся в процесс восстановления, важно подчеркнуть важность регулярного резервного копирования всех ваших баз данных. Независимо от того, является ли это производственной или разработочной средой, ваши данные ценны и должны быть защищены. Убедитесь, что у вас есть стратегия резервного копирования, включая простой сценарий “полного резервного копирования каждую ночь”. Разработочные базы данных так же важны, как и производственные, так как они являются основой вашей производственной линии.
Сценарий
Давайте смоделируем ситуацию, в которой у нас есть экземпляр SQL Server 2017 с несколькими базами данных. Мы начнем с создания резервной копии базы данных master:
BACKUP DATABASE [master]
TO DISK = N'D:\SQLBackup\master2017.bak'
WITH
NOFORMAT,
NOINIT,
NAME = N'master-Full Database Backup',
SKIP,
NOREWIND,
NOUNLOAD,
STATS = 10;
GOЗатем мы удалим несколько старых тестовых баз данных, чтобы смоделировать изменения, которые могут происходить быстро в разработочной или тестовой среде. Это поможет нам понять, как выглядел экземпляр на момент создания резервной копии.
Определение версии SQL Server
При восстановлении базы данных master важно знать сочетание SQL Server, пакетов обновления и накопительных обновлений для установки. Чтобы определить эту информацию, мы можем использовать резервную копию базы данных master и последнюю версию SQL Server. Например, на экземпляре SQL Server 2019 мы можем выполнить следующий запрос:
USE [master];
RESTORE HEADERONLY
FROM DISK = N'D:\SQLBackup\master2017.bak';Этот запрос предоставит нам ценную информацию, включая имя экземпляра, дату резервного копирования и основные, второстепенные и сборки программного обеспечения. Имея эту информацию, мы можем обратиться к списку сборок SQL Server, чтобы определить правильную версию SQL Server и уровень исправлений для процесса восстановления.
Восстановление баз данных
Теперь, когда мы определили версию SQL Server, нам нужно определить, какие базы данных существовали на момент создания резервной копии. Эта информация поможет нам определить приоритет операции восстановления и сопоставить доступные файлы баз данных с восстановлением master. Для этого мы можем подключиться к восстановленной базе данных master с помощью Dedicated Admin Connection (DAC) и запросить системную базовую таблицу sys.sysdbreg.
Запросом sys.sysdbreg мы можем получить список баз данных, включая те, которые могут уже не существовать. Этот список также предоставляет уровень совместимости и статус каждой базы данных. Имея эту информацию, мы можем связаться с владельцами бизнеса, чтобы определить, какие базы данных необходимо восстановить, и продолжить настройку соответствующих экземпляров и подключение файлов баз данных.
Заключение
Восстановление экземпляров и баз данных SQL Server после катастрофы требует тщательного планирования и подготовки. Используя информацию, доступную из резервных копий, такую как версия SQL Server и детали баз данных, вы можете обеспечить гладкий процесс восстановления. Помните всегда иметь регулярные резервные копии, даже для разработочных баз данных, и рассмотрите внедрение продвинутых техник, таких как системы контроля версий и методы гидратации баз данных, чтобы упростить процесс восстановления.
Не дайте катастрофе застать вас врасплох. Будьте активными и готовыми, чтобы быстро вернуться к работе.