Наша процедура резервного копирования следующая: полное резервное копирование в полночь, разностное резервное копирование каждые 8 часов и резервное копирование журнала транзакций каждые 5 минут. Планы обслуживания содержат все в порядке и порядке.
Для восстановления на определенный момент времени (скажем, вчера в 14:05). При восстановлении с помощью SQL Server Management Studio 2012 мы щелкаем правой кнопкой мыши базу данных, в которую хотим восстановить> Задачи> Восстановить> База данных. Затем мы восстанавливаем полную резервную копию без восстановления (и перезаписываем существующие данные). Это оставляет базу данных в состоянии «Восстановление ...». Затем мы переходим> Задачи> Восстановить> Файлы и файловые группы. Выберите ближайшую резервную копию (полдень). Восстанавливать без восстановления.
Теперь о журналах транзакций - Задачи> Восстановить> Журнал транзакций. В этом диалоговом окне мы выбираем «Из файла или ленты» и щелкаем кнопку, чтобы выбрать файлы. Добавьте и выберите 5-минутные журналы транзакций с 12:00 до 14:05 (из них 25). Когда мы нажимаем «ОК» в диалоговом окне ... SSMS аварийно завершает работу и выдает следующую ошибку:
Исключение при выполнении инструкции или пакета Transact-SQL. (Microsoft.SqlServer.ConnectionInfo)
Носитель, загруженный в «C: ... \ backup_2012_12_22_120500_4174134.trn», отформатирован для поддержки 1 семейства носителей, но ожидается 25 семейств носителей в соответствии со спецификацией устройства резервного копирования. RESTORE HEADERONLY аварийно завершает работу. (Microsoft SQL Server, ошибка: 3231)
Для получения справки щелкните: http://go.microsoft.com/fwlink?ProdName=Microsoft%20SQL%20Server&ProdVer=11.00.2218&EvtSrc=MSSQLServer&EvtID=3231&LinkId=20476
Насколько я помню, это точная процедура, которую мы использовали в SQL Server 2008 и 2005, поэтому я не могу понять, почему это не работает. Это что-то особенное для 2012 года? Это ошибка? Я не смог найти никакой информации об этом в Интернете. Мы вообще не используем ленточное резервное копирование, и большая часть того, что я читал о семействах носителей, относится к ленточным резервным копиям.
Устранение неполадок: выбор каждого журнала транзакций (по одному) по очереди и восстановление. Однако это может легко занять 15+ минут с таким большим количеством журналов транзакций.
Я не пробовал, но думаю, если бы мы написали простой старый TSQL в виде:
RESTORE DATABASE [OurDB] FILE = N'db_dat' FROM DISK = N'C:\...\diff\backup_2012_12_23_085000_4627006.bak' WITH FILE = 1, NORECOVERY, NOUNLOAD, STATS = 10
И запускал это для каждого журнала xaction - он должен работать. Я могу написать PowerShell или что-то в этом роде для восстановления базы данных ... но разве "Management Studio" не сможет с этим справиться? Этот ответ, кажется, указывает на «Нет». https://dba.stackexchange.com/questions/1021/how-to-restore-multiple-backups ... однако графический интерфейс намекает на возможность многократного восстановления "Укажите источник и местоположение журнала транзакций. резервные копии"- не говоря уже о том, что это позволяет вам в первую очередь выбирать несколько файлов.
Я нашел способ решить эту проблему
Из Management Studio:
Удачи.
Когда вы чередуете свои резервные копии, семейство носителей содержит более одного файла. Итак, если вы вызываете резервную копию так:
backup log [OurDb] to file = 'c:\file1', file='c:\file2'
В моем примере резервная копия была бы разделена на два файла (то есть половина резервной копии ушла бы в файл1, а половина - в файл2), и оба файла потребуются для восстановления. Чтобы узнать, какие файлы необходимы, взгляните на backupmediafamily в msdb. Следующий запрос должен вас туда доставить:
select family_sequence_number, physical_device_name
from backupmediafamily
where media_family_id = (
select media_family_id
from backupmediafamily
where physical_device_name = N'C:\...\diff\backup_2012_12_23_085000_4627006.bak'
)
Затем, чтобы восстановить, вам нужно будет сделать что-то вроде этого для каждого семейства носителей, которое вы хотите восстановить:
restore database [OurDb] from file = ''c:\file1', file='c:\file2', ... with norecovery
Наконец, когда вы достигли того момента, когда хотите, наконец, перевести базу данных в оперативный режим (т.е. вы закончили восстановление файлов журнала), вы делаете:
restore database [OurDb] with recovery