gifts2017

Скрипт удобного восстановления базы MSSQL при дифференциальном резервировании

Опубликовал Ivon (Ivon) в раздел Администрирование - Архивирование (backup)

Если у Вас база на MSSQL и Вы пользуетесь разностными бекапами, то, скорее всего, столкнулись с тем, что поднять базу/копию базы из имеющихся резервных файлов  не столь удобно, как того хотелось бы.
В этой статье приведен скрипт по теме.

Для начала немного истории.

Так сложилось, что в моей компании резервированием баз 1С, которые у нас лежат на MSSQL, занимаюсь лично я. Вначале, пока база еще не так сильно разрослась, все было просто: каждую ночь выгружался dt-файл. Этот путь не понравился по 3-м причинам: долго восстанавливается, при бекапе в базе не должно быть пользователей, на диске временного каталога должно быть место, расное файлу бекапа.

Время шло, база росла, было решено делать бекап базы MSSQL. Но банный файл оказался гораздо больше файла dt. Пришлось засесть за интернет и узнать как реализовать и потом реализовать на практике разностный бекап. Но так как у нас есть команда программистов, то для каждого программиста выделили еще и по паре тестовых баз.

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


--Здесь ничего не трогаем
declare @SQLString nvarchar(4000), @TableName nvarchar(16)
declare @t table (fname NVARCHAR(50))
DECLARE @counter INT, @backupfile NVARCHAR(50)
SET @counter = 0

---------------------------------------------------------------------------
-- Здесь изменяем имя базы

set @TableName = N'Ins_3_3'
-- Здесь вставляем необходимое количество бекапов.

-- Вначале полный, потом все разностные
INSERT INTO @t (fname) VALUES ('2011-01-16_ins.bak')
INSERT INTO @t (fname) VALUES ('2011-01-17_ins_diff.bak')
INSERT INTO @t (fname) VALUES ('2011-01-18_ins_diff.bak')

---------------------------------------------------------------------------
--Далее ничего не трогаем

DECLARE bkf CURSOR LOCAL FAST_FORWARD FOR SELECT * FROM @t;

OPEN bkf;
FETCH bkf INTO @backupfile;
WHILE @@FETCH_STATUS=0
BEGIN
IF @counter = 0
BEGIN
set @SQLString = N'restore Database ' + @TableName + '
FROM DISK = N''N:\Backup1C\' + @backupfile + '''
with NORECOVERY,
move ''Ins81'' to N''F:\SQLBases\Data\' + @TableName + '.mdf'',
move ''Ins81_log'' to N''F:\SQLBases\Data\' + @TableName + '_Log.ldf'',
STATS = 5'
END
ELSE
BEGIN
set @SQLString = N'restore Database ' + @TableName + '
FROM DISK = N''N:\Backup1C\' + @backupfile + '''
with NORECOVERY'
END
exec sp_executesql @SQLString
set @counter = @counter + 1
FETCH bkf INTO @backupfile;
END;
CLOSE bkf;
DEALLOCATE bkf;
set @SQLString = N'restore Database ' + @TableName + '
with RECOVERY'
exec sp_executesql @SQLString


Надеюсь, скрипт будет полезным.

Новая база будет создаваться по пути F:\SQLBases\Data\. Исправьте путь согласно своему серверу.

Бекапы у меня лежать в N:\Backup1C\. Естественно этот путь нужно тоже поменять.

Если что-то не понятно - спрашиваем.

См. также

Подписаться Добавить вознаграждение

Комментарии

1. Ийон Тихий (cool.vlad4) 20.01.11 13:05
Для пользователей было бы не плохо написать обработку по формированию этого скрипта...сделать это несложно, чтобы вручную не ковырятся в скрипте.
2. Ivon (Ivon) 23.01.11 15:35
(1). Тут и так сделано максимально удобно.
3. Ийон Тихий (cool.vlad4) 23.01.11 23:25
(2) В чем же максимальная удобность, когда надо вручную менять пути и имя базы? Раз уж это ресурс для 1С, то можно сделать обработку для этого, где вводится эта информация и создается ваш скрипт, либо сделать для этого скрипт vbs, можно на powershell - но это был совет, если не хотите не делайте. Благо скрипт не сложный и можно сделать ручками.
4. Ivon (Ivon) 24.01.11 10:00
(3). Согласен, что обработку сделать не сложно. Скрипт сам по себе сложнее.
5. Валерий Дубовой (Valerich) 26.01.11 16:33
Гм... странный подход....
Переменные объявил всякие разные, а основные, которые напрашиваются сами собой нет.

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

Но тут, очевидно, об удобстве использования никто не задумывался - "Мы не ищем легких путей...(С)"
Famza; bserge; +2 Ответить
6. Ivon (Ivon) 10.10.13 11:34
Ну вот...
Дал, разжевал, а им все плохо. Вот до чего люди ленивы стали...
7. Наталья (bahcha8) 31.01.14 16:20
Спасибо, за скрипт. Кому не нравится - пусть поменяют пути на переменные, это не сложно. Восстанавливать разностные копии действительно не очень удобно. Но вот мы делаем два бэкапа полных - днем и ночью, а днем до и осле обеда разностные. И восстанавливать из разностных приходится крайне редка. Чаще всего достаточно дневной или ночной копии. Если не делать долго (например два дня) полный бэкам - размер разностных не отличается от полного.
8. Ivon (Ivon) 31.01.14 16:52
(7) bahcha8, Мы делаем в воскресенье полный, в остальные дни разностный. Можно так же не возиться с бекапами, а настроить репликацию БД на другой сервер. У меня такое было настроено, пока резервный сервер не забрали под разработку, репликации сваливались с одного сервера на другой раз в 15 минут. Таким образом у меня всегда была копия базы с разницей не более 15 минут.
9. Елена Ситникова (lesenoklenok) 14.02.14 10:45
10. Сергей (strange2007) 05.09.16 21:18
(8) Ivon, пардон, что не по теме. Просто вопрос: восстанавливать из такого бакапа пробовали? В смысле платформа 1С такую репликацию воспринимает нормально? Ведь транзакция СУБД <> транзакции 1С. Мы и с репликациями и с этими супер бакапами возились, которые каждые 10 минут работали, один фиг то одно отвалится, то другое, а порой база вообще рассыпалась.
11. Ivon (Ivon) 06.09.16 10:38
(10) strange2007, Да, у меня все отлично работало. Полный бэкап делался в ночь с субботы на воскресенье, в остальные дни делался разностный бэкап. Рабочий сервер у нас не ложился ни разу, но бэкапы использовались активно, чтобы обновить тестовые базы у разработчиков. Все восстановления из бэкапов были успешные. Репликация работала не очень, время от времени что-то отваливалось и приходилось запускать ее заново, хотя первые пол годика реплики через каждые 15 минут без проблем ходили с рабочего на стэндбай. В итоге через 2 года решили репликацию отключить, оставить только резервирование.
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа