Часто возникает задача восстановить базу по цепочке бэкапов на резервном/тестовом сервере, на котором непосредственный бэкап базы не проводился, отсутствуют записи в msdb, но есть сами бэкапы, снятые с продуктивного сервера. Вариант с восстановлением копии базы msdb может не подойти если должны существовать разные наборы джобов для основного сервера и того, на котором мы планируем восстановление. Если файлов с бэкапами немного, то восстановить логический порядок следования файлов нетрудно, особенно если бэкапы принадлежат логшиппингу. В этом случае все тривиально - в имени файла хранятся и время, и дата (стоит только помнить, что время в именах файлов хранится в UTC). Но что делать, если в бэкапах нет структуры или файлов очень много, и организовать их простым способом не представляется возможным или как можно просто определить начиная с какого файла логшипинга начинать донакатку ? Если вы занимались этим вопросом, то возможно вы сталкивались с подобной ошибкой
Msg 4305, Level 16, State 1, Line 1
The log in this backup set begins at LSN 30643000001846100001, which is too recent to apply to the database. An earlier log backup that includes LSN 30643000001845500001 can be restored.
или
The log in this backup set terminates at LSN 9386000024284900001, which is too early to apply to the database. A more recent log backup that includes LSN 9417000002731000001 can be restored.
В этой статье я расскажу как с минимумом ручной работы правильно выстроить цепочку восстановления и постараться избежать подобных ошибок. Трюк заключается в наполнении репозитория восстановления и использовании логики построения цепочки восстановлений Management Studio.
1) Первоначально в базе резервного/тестового сервера необходимо сформировать метаданные о бэкапах.
Наполнять репозиторий мы будем
RESTORE VERIFYONLY FROM DISK = 'Имя бэкапа' WITH LOADHISTORY
аналог известной команды ORACLE
RMAN> CATALOG START WITH…
Эта команда, считывая бэкап с диска, проводит минимально необходимую проверку корректности образа, и в случае успеха формирует в msdb резервного сервера записи об этом образе.
И скрипт по загрузке истории о бэкапах из определенной папки будет выглядеть так:
(его можно дополнить логикой для обработки вложенных директорий)
declare @Path nvarchar(255)
declare @Name nvarchar(255)
select @Path = N'\\ServerName\D$\LogShipingDir\DevDB\'
IF OBJECT_ID('tempdb..#filetmp') IS NOT NULL DROP TABLE #filetmp ;
create table #filetmp (Name nvarchar(255) NOT NULL, depth int NOT NULL, IsFile bit NULL )
insert #filetmp
EXECUTE master.dbo.xp_dirtree @Path, 1, 1
DECLARE @filename varchar(200)
DECLARE @SQL nvarchar(300)
DECLARE FileList_Cursor CURSOR FAST_FORWARD FOR
select name from #filetmp where IsFile=1 and name like '%DevDB%'
OPEN FileList_Cursor;
FETCH NEXT FROM FileList_Cursor
INTO @filename;
WHILE @@FETCH_STATUS = 0
BEGIN
set @SQL=@Path+@filename;
print @SQL;
RESTORE VERIFYONLY FROM DISK = @SQL WITH LOADHISTORY
FETCH NEXT FROM FileList_Cursor
INTO @filename;
END;
CLOSE FileList_Cursor;
DEALLOCATE FileList_Cursor;
! Осторожно: скрипт будет выполняться довольно долго (время обработки одного файла сопоставимо с временем восстановления бэкапа из этого файла)
Скрипт заполнит системные таблицы информацией о бэкапах. Такое же добавление в репозиторий происходит при обычном восстановлении из бэкапов. Это подходит в случае использования систем бэкапирования с нестандартными способами восстановления для занесения сведений в репозиторий восстановления.
1.а) В противном случае, когда бэкап производится альтернативными средствами нам так же необходимо загрузить данные о совершенных бэкапах. К примеру, восстановление в Veritas NetBackup происходит через интерфейс
На этом этапе важно восставить базу с параметром NORECOVERY если мы планируем восстанавливать дальше цепочку бэкапов
В результате восстановления в репозитории, в качестве устройства, на котором лежит бэкап будет VDI-устройство и достучаться к нему со стороны SQL сервера будет невозможно, но эта запись нам необходима как отправная точка для цепочки восстановлений
2) После заполнения репозитория восстановления msdb можно начать само восстановление.
В Management Studio открываем окно восстановления, выбираем базу, для которой мы заполняли репозиторий восстановления. Интерфейс выполнит попытку построить цепочку восстановлений для одной инкарнации базы - на основе цепочки LSN в загруженных метаданных. Информация о бэкапах для построения списка должна быть как можно более полной и содержать всю цепочку.
Если цепочка восстановлений не построилась, восстановление невозможно по следующим причинам:
- у вас бэкапы от разных инкарнаций базы, или
- отсутствует полный бэкап для начала цепочки восстановления.
неполная цепочка может быть вызвана отсутствием какого либо файла, либо ошибкой в образе.
Указав все необходимые параметры сохраним скрипт на восстановление и удалим шаги, которые мы уже проделывали, восстанавливая из нестандартного источника (например Veritas Netbackup).