Windows, MSSQL, бэкапы.
алить все в один файл мне не нравится - он же будет разрастаться до неприличных размеров.Средствами MS SQL каждые пол часа бэкапишь в d:\backup\today\todaylog.bak
Средствами виндового планировщика запускаешь раз в день перенос и переименование файла в d:\backup\day\%date%_%time%_log.bak
В результате у тебя будет бекап на теущий день и бэкапы за прошлые в формате - 1 день = 1 файл.
Валить все в один файл мне не нравится - он же будет разрастаться до неприличных размеров.достаточно делать BACKUP LOG WITH INIT (обычно вместе с датабазе бакапом)
т.е. тебе надо два джоба
Job 1 - один раз в день
BACKUP DATABASE WITH INIT
BACKUP LOG WITH INIT
Job 2 - раз в 30 мин
BACKUP LOG WITH NOINIT
BACKUP LOG WITH INITТо есть, первый джоб создаст файл с бэкапом, а второй, если в нем указать WITH NOINIT, и не указывать устройство, допишет бэкап в конец последнего используемого устройства (файла)?
Job 2 - раз в 30 мин
BACKUP LOG WITH NOINIT
Включу в расписание, протестирую. Если это так, то это идеально.
Да, о перемещении файла куда-нибудь средствами не-sql агента я, конечно, тоже думал, но отказался по сразу нескольким причинам:
-лучше создавать бэкапы именно там, где они будут лежать - тогда в журнале sql сервера будут присутствовать правильные ссылки на файлы, сервер сам сможет заниматься ротацией бэкапов, и т.д.
-да и просто лишнее звено в цепочке, которую хочется сделать покороче.
эээ, не, все остальные параметры одинаковые, в том числе и устройство
INIT - это overwrite как раз
NOINIT - append
просто после database backup тебе уже не нужны старые бакапы логов, поэтому их надо перезаписать, иначе действительно, файл будет разростаться до бесконечности
т.е. пишешь всегда в два файла - один для базы, другой для лога, ну и конечно архивируешь их перед перезаписью
в итоге на каждый день у тебя по два файла - будет minimum amount of administrative effort for restoring как в тестах пишут ))
INIT - это overwrite как раз
NOINIT - append
просто после database backup тебе уже не нужны старые бакапы логов, поэтому их надо перезаписать, иначе действительно, файл будет разростаться до бесконечности
т.е. пишешь всегда в два файла - один для базы, другой для лога, ну и конечно архивируешь их перед перезаписью
в итоге на каждый день у тебя по два файла - будет minimum amount of administrative effort for restoring как в тестах пишут ))
В общем, как сделал:
в ежесуточном плане - регламенты, потом - копирование журнала транзакций в temp.trn, потом - полный бэкап в base_backup_$DATE.bak.
ежечасный - бэкап журнала транзакций в base_backup_$DATE.trn
(если кому интересно)
В чем фишка - в temp.trn идет первый после регламентного обслуживания журнала транзакций бэкап, который весит иногда сравнимо с базой.
А те бэкапы журнала транзакций, которые создаются в течении дня, складываются в один файл (так гораздо легче восстанавливаться, очень хотелось именно так), и все равно этот файл весит немного.
А все это делалось для того, чтобы можно было оперативно заливать бэкапы в облако - full бэкап вполне успевает залиться на ночь, а ежечасный - весит немного.
Я осознаю, что сознательно разрываю цепочку бэкапов журналов транзакций, но пока меня это вполне устраивает.
upd: вот только что-то мне mssql писем писать не хочет...
в ежесуточном плане - регламенты, потом - копирование журнала транзакций в temp.trn, потом - полный бэкап в base_backup_$DATE.bak.
ежечасный - бэкап журнала транзакций в base_backup_$DATE.trn
DECLARE @pathName NVARCHAR(512)
SET @pathName = 'F:\backup\base\base_backup_' + rtrim(YEAR(getdate())) + '_' + RIGHT('0' + rtrim(MONTH(getdate())),2) + '_' + RIGHT('0' + rtrim(DAY(getdate())),2) + '.trn'
BACKUP LOG [base] TO DISK = @pathName WITH NOFORMAT, NOINIT, NAME = N'base', SKIP
(если кому интересно)
В чем фишка - в temp.trn идет первый после регламентного обслуживания журнала транзакций бэкап, который весит иногда сравнимо с базой.
А те бэкапы журнала транзакций, которые создаются в течении дня, складываются в один файл (так гораздо легче восстанавливаться, очень хотелось именно так), и все равно этот файл весит немного.
А все это делалось для того, чтобы можно было оперативно заливать бэкапы в облако - full бэкап вполне успевает залиться на ночь, а ежечасный - весит немного.
Я осознаю, что сознательно разрываю цепочку бэкапов журналов транзакций, но пока меня это вполне устраивает.
Оставить комментарий
carusya
Думаю вот, как бы мне бэкапы реорганизовать.Речь о бэкапах транзакшн лога sql, которые хочу делать раз в (ну не определился пока, пусть будет 30) минут.
Вижу пути: запускать их раз в 30 минут через виндовый планировщик, регламентом средствами самого mssql, или черти-как.
Минусы виндового планировщика: ну нет у него триггера "раз в 30 минут". есть "после загрузки компьютера", есть "ежедневно", и там и там можно попросить повторять каждые 30 минут, но блин, если с заданием случится какято фигня (остановлю руками для обслуживания, хотя бы), а потом запущу опять - оно не начнет само выполняться каждые 30 минут - оно будет ждать своего триггера "после загрузки компьютера".
Минус регламента силами sql еще глупее: на первый взгляд, он позволяет либо валить ВСЕ делаемые резервные копии в один файл, либо каждую в свой файл:
Валить все в один файл мне не нравится - он же будет разрастаться до неприличных размеров.
Каждую копию в свой файл тоже не нравится - это же будет по 25 файлов за смену, а при восстановлении придется выбрать и накатить каждый.
Запуск бэкапа кастомным скриптом шедулером этого недостатка был бы лишен - там можно написать
и было бы так, как я хочу - логи за 1 день - в 1 файле. Но как гарантированно запускать этот скрипт раз в 30 минут? (а еще лучше - не весь день, а, к примеру, с 7 до 21 часа).
Третий вариант - запускать чем-то даже всерьез не рассматривал пока - глупо это как-то, да и чем пользоваться, не знаю...
Да, SQL 2008 R2, если кого-то заинтересует.