Тонкая настройка ежедневного резервного копирования базы данных 1С средствами SQL ver. 2014 (SP3) - 12.0.6024.0 (X64)
Хочу вам предложить небольшой пример, как можно реализовать резервное копирование 1С-ых баз данных средствами SQL. Данный материал не претендует на пулитцеровскую премию. Но возможно кому-то будет интересно узнать, что-то новенькое.
Данный материал для резервного копирования только одной базы данных. А именно, если у вас 20-ть баз, то вам придется создавать 20-ть планов обслуживания для каждой базы индивидуально.
(Слава разработчикам SQL, они разрешили копировать блоки из одного плана в другой, вам остается только произвести небольшую настройку для каждого скопированного блока - некоторые настройки блоков сбрасываются и выставляются значением по умолчанию и остаются неактивными)
Добрый день! Статья интересная, но считаю, что ставить зависимость всего плана от успешной проверки целостности бд неправильно. Рискуете остаться вообще без бэкапа.
(1) Зачем нам бекап, который уже не совсем корректный?
Вы эту ошибку можете обработать спустя неделю, если штат людей не позволяет сразу обработать сообщения, либо они у вас не настроены.
А так, на мой взгляд, лучше иметь нормальную копию, чем битую, и при этом вы потом не выясните, битая она или нет, если будете восстанавливаться. :)
(3) Да любопытно, но мне нужен был полный бекап (хотя бы раз в месяц) с экономным бекапированием на каждый день.
Можно заморочиться и побекапить журнал транзакций, но не вижу в этим необходимости в нашем случаи.
А так, все это "баловство" лишь ориентировано на ознакомление с возможностью планировщика SQL.
Если честно, я в нем разочарован.
- мне не удалось свести оформление переменных к одному блоку, т.е. я к примеру вызвал бы инструкцию SQL № 1 и назначил бы там нужные параметры и значения. А дальше просто бы подставлял бы переменным нужные значения.
- Интерфейс планировщика может больше, чем сам способен обработать планировщик, т.е. вы не может разместить один блок "Резервное копирование" и из разных ответвлений выполнить его. SQL планировщик ваш блок проигнорирует, и даже не заругается на вас.
- Не до конца понял, зачем вообще там нужны (в планировщике) глобальные переменные, ибо описания, как ими пользоваться я так и не нашел на просторах сети. (печально)
- Очень разочаровался в работе с диском, оказывается SQL запрещает писать через запросы, и что бы это обойти приходится отключать безопасность.
- Нельзя настроить планировщик так, что бы к примеру в интервале у вас удалялись только определенные копии бекапа, а одна в периоде оставалась.
(4) Чтобы не писать все эти мегатонны кода в планировщике, есть такая штука, как stored procedures
Ну и рекомендую посмотреть в https://ola.hallengren.com/sql-server-backup.html там скорее всего всё, что только можно придумать, уже сделано :)
A. Back up all user databases, using checksums and compression; verify the backup; and delete old backup files
EXECUTE dbo.DatabaseBackup
@Databases = 'USER_DATABASES',
@Directory = 'C:\Backup',
@BackupType = 'FULL',
@Verify = 'Y',
@Compress = 'Y',
@CheckSum = 'Y',
@CleanupTime = 24
B. Back up all user databases to a network share, and verify the backup
EXECUTE dbo.DatabaseBackup
@Databases = 'USER_DATABASES',
@Directory = '\\Server1\Backup',
@BackupType = 'FULL',
@Verify = 'Y'
(13) Вы наверное не прониклись моей задачей.
Мне не нужен полный бекап на каждый день.
У меня есть базы, которые "АРХИВНЫЕ" (почти), народ в них не работает.
Но их бекапят, и бекап раз в год, желательно делать.
А все последующее время, у меня должны делаться "МИНИ бекапчики" (разносные, промежуточные- назовите их как хочется),
(14) Да я и не настаиваю на применении скриптов от Оле, но посмотреть, как делают настоящие DBA, всё же рекомендую.
Я на собственном опыте убедился, что лучше всю логику бэкапов (да и вообще всех регламентов) реализовывать на T-SQL, и не рисовать хитрых схем в планах обслуживания. Особенно это чувствуешь, когда приходится переезжать на другой сервер, и вот тогда настаёт беда бедовая... Особенно учитывая, что от версии к версии всё ощутимо меняется, и каждый раз изобретать эти схемы заново - это такое себе занятие.
И ещё полезно завести какие-нибудь таблички, где будут храниться все нужные результаты работ по бэкапу, типа, где что лежит, когда был последний успешный полный бэкап, всякие размеры, и т.п. Обычно их в msdb создают.
(11) И вот собственно, чтобы этого не делать, и стоит вынести весь код в sp-шку (или несколько sp-шек), и в джобах вызывать их с нужными параметрами. Таким образом, вместо кучи кода в каждом джобе будет всего несколько строчек вида exec dbo.sp_backub(...)
(4) Внимание вопрос - зачем вам схема FULL, если в итоге вы журнал не бекапите, а просто обрезаете его? Удивлён, что в комментариях никто этого не спросил.
(32) Затем, что обрезание его делается, при ПОЛНОМ бекапировании РАЗ в ГОД, МЕСЯЦ, Неделю... Вы бы хоть обратили внимание на детали :)
Баз много, вариантов тоже, прописывать еще и индивидуальную структуру для каждого плана (а их ~20), я не очень рад.
Хоть где то должно быть однообразие...
(33) Вопрос не "когда", а "зачем". Это два разных вопроса. Добавьте ОДИН план обслуживания, который будет запускаться раз в полчаса, бекапить ВСЕ журналы и сразу их удалять. Это если кто-то там у вас упарывается по полной схеме восстановления. Этот вопрос мусолят уже не первый год - и тут, и на сторонних ресурсах. Каждый год появляется человек, в статье которого присутствует - "...и делаем truncate журнала", что порождает очередную волну спича на несколько страниц. Усвойте уже, что вариантов два - "Схема FULL и бекап журналов", либо "Схема SIMPLE и никаких восстановлений вне точек бекапов полных и разностных, но зато без бекапов журналов".
Полное бекапирование не имеет НИКАКОГО отношения к схеме восстановления.
(34) Предположите, что я не Администратор БД, Нет Тот, кто следит за базами, бекапами и вообще человек далекий от железа.
Каждая настройка в этой статье это всего лишь знакомство с планом обслуживания за 8-часов, используя гугл. (без вопросов на форумах)
Я решил, что кому-то будет любопытно ознакомится со скриптами, запросами, о том, что не все в планах обслуживания так радужно, как кажется.
ДА, можно просто взять и все написать одним блоком, Скриптом, без ваших блоков, и схем.
...Я просто программист, мне не трудно, но мне любопытно было сделать именно так, как видели в статье....
(Если вы приводите свою схемы, поделись с людьми скриптами...)
...По поводу Журнала, кто вам сказал, что мне не нужны часовые копии?...
...Я просто до этого еще не добрался...
...Будет время доберусь, а нет, то нет...
...Как я писал, ходить по своим граблям удел каждого, и грабли у каждого свои... :)
(36) Я не против! Статья хорошая. Некоторые моменты мне были очень интересно - с удовольствием переделаю свой план. И не только мне, судя по 23 звёздочкам.
По-поводу журнала - делайте с необходимым промежутком. Нужны часовые - делайте часовые. Нужны минутные - делайте минутные. И храните всё это, пока это требуется. Я просто обратил ваше внимание на ненужность шага, связанного с переводом баз в simple режим и обратно лишь для того, чтобы обрезать журнал.
(33) скрипт бекапирования ОДИН. В нём определяется необходимость полного или разностного бекапа. Баз можно добавлять любое количество - хоть 20, хоть 200.
(35) При использовании одного плана состоящего из нескольких блоков, где выбирается 20-ть баз... Происходит следующее...
1. Ваш блок , каждый блок в плане, будет обрабатывать ВСЕ 20-ть баз.
2. Он не перейдет в следующий блок, пока не наиграется с БАЗАМИ!!!!...
3. Карл, если одна база в ауте, то все базы пойдут по этому маршруту, и бекапов вы не увидите вовсе.
4. Вы теряете прелесть от параллельного резервирования, когда Сервер загружается по самые уши бекапированием :)
(37) Мне показалось, что вы как раз сетовали на то, что хотели сделать один универсальный план. Делайте по плану на базу, если всё-таки вопрос не в этом.
Про один блок я писал, так как на скрине у вас два блока бекапирования.
(40) Таки и сделал, Структура плана Одна. И состоит из одного количества блоков. С одинаковой структурой.
Просто блоки настроены по разному. (это только пример, возможность посмотреть, как у соседа настроено, сделать может так же, а возможно лучше)
(0) в пункте 6 можно сделать без предварительного определения id базы:
use <база>;
DECLARE @DB_ID int;
SET @DB_ID = DB_ID();
DBCC FLUSHPROCINDB(@DB_ID)
Спасибо за статью. Жаль, что для каждой базы отдельный план надо копировать
зы: То чувство, когда в твоём плане обслуживания только резервная копия и очистка старых
Оповещение надо делать не только при сбое, если у вас не запустится задание и ничего не выполнится, вы об этом ничего не узнаете. Нужно выполнять оповещение после каждого успешного выполнения и если оповещения нет, то нужно выяснять причины.
(17) при чем тут почта? А вообще так и работаем да, без разницы что там происходит, выполняется задание , не выполняется, почта не пришла не я виноват, спрашивайте вон у того чувака
(18) При том, что когда у вас по работе около 300 писем прилетает за сутки, вы среди мусора, нечего не разберете.
Да и место у почтовика не резиновое...
...в общем на баловался я с сообщениями, и получать все сообщения, это БРЕД... некому ваши успешные бекапы ненужны :)
(18) Если начнут разбирать, у меня будет аргумент, что почтовая программа не работает, из-за того, что учетка была заблокирована и сообщения от SQL сервера не поступали.
Есть вариант, что у организации ограниченное пространство для почтового ящика.
Вы батенько, почту будете всегда очищать от спама?
Вам вот кроме как читать мертвую почту про успешные бекапы, нечем заняться? :)
(21) Есть такая проблема. В идеале хотелось бы видеть какую-то табличку со светофором по списку бэкапов. Но как ее сделать пока нет ни малейшего понятия.
(22) Если только хранить такие данные отдельно в какой либо БД, которую ты добавишь.
А уже в какой либо програмулинке её выводить во всей красе, хоть в 1С ;)
(27) Вот посмотрел бы я на ваши весла из граблей, когда для бекапов, вместо 100 терабай, вам дадут 15, и вертись как хочешь... со словами "не в чем себе не отказывай" :)
(28) а в чём проблема почитать инструкцию к скриптам от Ola Hallengren и настроить так чтобы влезать в объём? В любом варианте используются одинаковые команды и возможности SQL Server. Там есть всё необходимое, включая удаление старых бэкапов.
P.S.: за регламентное сжатие журнала транзакции и неанглийский интерфейс в приличном обществе пинают в живот.
(29) Интерфейс нормальный, перевод действительно бредовый, но какой есть.
Не в Ola Hallengren дело... мужик он толковый, но мне нужен мой мопед, с моими правилами. И его самокат мне не подходит :)
А то что журнал режу, таки он в моем случае рудиментарное творение, у нас свободный мир, вы готовы кушать кактус и удалять бекапы ежедневно, из-за нехватки места.
Я предпочитаю выстроить максимально автоматизированное архивирование, хотя бы на пару лет. ;)
declare @datenow datetime = getdate()
declare @DayOfMonth int
declare @DayOfWeek int
declare @FullType bit
declare @FullName varchar(1000)
declare @Name varchar(500)
declare @backupSetId as int
set @Name = CAST(YEAR(getdate()) as varchar) +
RIGHT('0' + cast(MONTH(getdate()) as varchar), 2)+
RIGHT('0' + cast(DAY(getdate()) as varchar), 2)+
RIGHT('0' + cast(datepart(HOUR, getdate()) as varchar), 2) +
RIGHT('0' + cast(datepart(MINUTE, getdate()) as varchar), 2) +
RIGHT('0' + cast(datepart(SECOND, getdate()) as varchar), 2)
set @DayOfMonth = datepart(day, @datenow)
set @DayOfWeek = DATEPART(weekday, @datenow)
if @DayOfMonth = 1 or @DayOfWeek = 1
begin
set @Name = N'MainBaseOfAllUniverse_backup_FULL_' + @Name
set @FullName = @FullPath + @Name + N'.bak'
BACKUP DATABASE [MainBaseOfAllUniverse] TO DISK = @FullName WITH NOFORMAT, NOINIT, NAME = @Name, SKIP, REWIND, NOUNLOAD, COMPRESSION, STATS = 10
end
else
begin
set @Name = N'MainBaseOfAllUniverse_backup_FULL_' + @Name
set @FullName = @FullPath + @Name + N'.bak'
BACKUP DATABASE [MainBaseOfAllUniverse] TO DISK = @FullName WITH DIFFERENTIAL, NOFORMAT, NOINIT, NAME = @Name, SKIP, REWIND, NOUNLOAD, COMPRESSION, STATS = 10
end
Показать
Примерно так. Фулл бекап на первый день месяца или недели, дифференциальный - в остальные
(44) По хорошему, лучше вообще все в один блок написать, SQL это позволяет :)
Что бы не загромождать скрипт, можно часть вытащить в глобальные функции.
(43) И ещё вот с этим -
sel ect @backupSetId = position fr om msdb..backupset where database_name=N'Базюка' and backup_set_id=(select max(backup_set_id) fr om msdb..backupset wh ere database_name=N'Базюка' )
if @backupSetId is null
begin
raiserror(... и дальше генерация сирен, мигалок и солдат с собаками
(48) Куда мимо? Не нравится? Чем? Что, тупо просто? Запросы сложные? (Рекомендую изучить SQL запросы)
Это рабочий вариант, как сделал я.
Может кому пригодится, может кто решит, модифицировать.
Может кто посмотрит и купит нормальное ПО (дорогое) и будет делать бекапы через него.
Статья ничем не обязывает и не говорит, что это эталон и другие дураки. НЕТ, статья о том, что можно так, но всегда есть лучше. Я предлагаю выбор.
А вы что предлагаете, прочесть ваш пост и что дальше? Вы не дали ни ссылки, не рекомендаций, что типо у вас лучше. Ни решения, ни ответа, ни совета. :)
Перенос данных КА 1.1 => КА 2 / УТ 11 (перенос документов, начальных остатков и справочной информации из "1С:Комплексная автоматизация", ред.1.1 в "1С:Комплексная автоматизация", ред. 2.х)
Перенос данных КА 1.1 => КА 2 / УТ 11 (перенос документов, начальных остатков и справочной информации из "1С:Комплексная автоматизация", ред.1.1 в "1С:Комплексная автоматизация", ред. 2.х)