В настоящее время я заменяю кого-то, кто отвечал за резервное копирование более 250 серверов на разных платформах, пока мы не наймем замену. У меня главный вопрос:
Если мы используем программное обеспечение резервного копирования, такое как Symantec backup exec, правильно ли оно выполняет резервное копирование для MSSQL Server?
Я слушал Подкаст Stack Overflow, и я слышал, что они говорили о том, что вы не можете просто создавать резервные копии файлов данных SQL, но вам также нужен журнал транзакций? Итак, если мы просто сделаем резервную копию всей машины, сможем ли мы ее правильно восстановить, поскольку мы будем делать резервную копию файла данных и журнала?
Спасибо!
Вам нужно проверить блог Брента Озара на сервере sql. Он источник великих знаний. При этом резервное копирование SQL-сервера может быть очень простым или действительно сложным в зависимости от того, насколько свежими должны быть данные. Если вы можете справиться с потерей данных за день, тогда простое резервное копирование сервера Jane SQL отлично подойдет. Если вам нужно убедиться, что у вас есть гораздо более свежий файл данных, тогда отправка журнала может быть вашим следующим лучшим выбором.
Найдите дружелюбного администратора базы данных для аудита и убедитесь, что вы действительно получаете хорошие резервные копии.
Есть два способа резервного копирования баз данных. Один из них - сделать дамп базы данных (я не dba, поэтому я не уверен в механизме создания дампа) в текстовый файл, а затем записать этот файл на ленту. Второй - использовать агент, который знает об используемой вами СУБД. Оба эти метода предоставят вам все необходимое для восстановления БД в рабочее состояние.
Вы можете использовать backup exec, но вам нужно будет убедиться, что агент MSSQL установлен в этих системах. Поскольку у вас более 250 серверов, я предполагаю, что у вас есть хотя бы одна база данных в штате - я бы спросил их, как в настоящее время выполняется резервное копирование серверов SQL. Они должны знать некоторые основы, по крайней мере, достаточно, чтобы вы начали. Они будут знать, например, использовал ли ваш предшественник агент или создавал резервные копии текстовых дампов.
Если вы используете Backup Exec с опцией агента SQL, он правильно выполняет резервное копирование баз данных, используя SQL API для выполнения резервного копирования. Я думаю, что проблемы с резервными копиями SQL, упомянутые в подкасте, были связаны с автономным резервным копированием (остановите SQL-сервер, затем сделайте резервную копию файлов). Обратите внимание, что с помощью Backup Exec вам необходимо делать резервные копии журналов транзакций, а также полные резервные копии, чтобы предотвратить рост журналов транзакций (если ваши базы данных находятся в режиме полного восстановления). Посмотри на http://www.backupexecfaq.com/articles/concepts/backing-up-microsoft-sql-server.html для получения более подробной информации.
Вот сценарий, который я использую:
ОБЪЯВИТЬ @DBName varchar (255)
ОБЪЯВИТЬ @DATABASES_Fetch int
ОБЪЯВЛЕНИЕ КУРСОРА DATABASES_CURSOR ДЛЯ select DATABASE_NAME = db_name (s_mf.database_id) from sys.master_files s_mf where - ONLINE s_mf.state = 0
-- Only look at databases to which we have access and has_dbaccess(db_name(s_mf.database_id))= 1
-- Not master, tempdb or model and db_name(s_mf.database_id) not in ('Master','tempdb','model') group by s_mf.database_id order by 1ОТКРЫТЬ DATABASES_CURSOR
ВЫБРАТЬ ДАЛЕЕ ИЗ DATABASES_CURSOR В @DBName
WHILE @@ FETCH_STATUS = 0 НАЧАТЬ объявить @DBFileName varchar (256)
установить @DBFileName = datename (dw, getdate ()) + '-' + replace (replace (@DBName, ':', ''),' \ ','') +' .BAK 'exec ('BACKUP DATABASE [' + @DBName + '] TO DISK =N '' $ systemdrive $: \whereFun \ '+ @DBFileName +' '' WITH NOFORMAT, INIT, NAME = N '' '+ @DBName +' -Full Database Backup '', SKIP, NOREWIND, NOUNLOAD, STATS = 100 ')
FETCH NEXT FROM DATABASES_CURSOR INTO @DBName ENDЗАКРЫТЬ DATABASES_CURSOR DEALLOCATE DATABASES_CURSOR
Все, что вам нужно сделать здесь, это восстановить файл .BAK. Нет необходимости в резервный исполнитель