Резервное копирование БД SQL чаще

10

В настоящее время у меня есть запланированное задание, которое запускается каждую ночь в 2 часа ночи, которое вызывает SQLCMD.exe и передает его в сценарий .sql для запуска для резервного копирования (показано ниже). Мы довольно маленькая компания с растущими потребностями из-за значительного роста бизнеса. Потеря данных за 1 день на этом этапе обойдется в десятки тысяч долларов против пары сотен в прошлом году. До тех пор, пока я не смогу перенести эту платформу БД в другое решение, в котором зеркальное отображение данных происходит с большой избыточностью, такой как SQL Azure, что я могу сделать, чтобы получать более частые резервные копии? Приводит ли этот скрипт в действие принудительную отключение БД? Можно ли запустить этот скрипт с пользователями, взаимодействующими с БД?

USE CompanyCRM;
GO
BACKUP DATABASE CompanyCRM
TO DISK = 'D:\CRMBackups\CompanyCRMCRM.Bak'
   WITH FORMAT,
      MEDIANAME = 'CompanyCRM_Backup',
      NAME = 'Full Backup of CompanyCRM';
GO

Обновить

Ух ты, очевидно, гораздо более преданное сообщество DBA здесь, чем на SO. Спасибо за отзыв до сих пор. Не хватает только «как». Выше я показал команду SQL, которую я использую для ежедневного резервного копирования, но примеры инкрементного резервного копирования журнала - это MIA. Это небольшая БД, в настоящее время она работает на SQLExpress. Когда я говорю «HA» или «SQL Azure», я имею в виду архитектуру, которой мы не располагаем как малый бизнес. Этот экземпляр в настоящее время работает на нашем ТОЛЬКО сервере. Если этот сервер выходит из строя, наше время восстановления становится камнем преткновения. Вот почему SQL Azure становится привлекательным.

RSolberg
источник
отредактировал мой ответ на ваше обновление, надеюсь, это поможет

Ответы:

5

РЕДАКТИРОВАТЬ, из вашего обновления

Поскольку вы сказали, что можете потерять данные за 1 день, я бы просто перевел базы в режим ПРОСТОГО восстановления. Затем вы можете сделать ПОЛНОЕ каждое утро и / или вечер. Если вы хотите, чтобы покрыть себя в течение дня вы могли бы через дифференциальное резервное копирование базы данных, один из тех, на всякий случай. Это будет фиксировать любые изменения, сделанные после полного резервного копирования. Если я знаю временные рамки, в которые поступает много информации, я могу добавить туда резервную копию такого типа после ее завершения. Это может сэкономить время при восстановлении, поэтому им не нужно вводить дополнительные данные.

Поскольку это ваш единственный сервер, я хотел бы убедиться, что вы используете DBCC CHECKDB для баз данных. Резервные копии не приносят никакой пользы, когда вы обнаруживаете, что они повреждены (я думаю, что кто-то тоже упоминал об этом). Вы можете найти несколько сценариев, чтобы настроить запланированное задание, чтобы проверить SQL ERRORLOG на наличие сообщения DBCC для обнаружения ошибок. SQL Server не будет изначально предупреждать вас об ошибках, возвращаемых из сообщений DBCC, поэтому, если вы не проверяете каждый раз вручную скрипт, это может помочь.

Команда дифференциального резервного копирования:


USE CompanyCRM; 
GO 
BACKUP DATABASE CompanyCRM 
   TO DISK = 'D:\CRMBackups\CompanyCRMCRM_diff.Bak'    
WITH FORMAT, DIFFERENTIAL,
MEDIANAME = 'CompanyCRM_Backup',       
NAME = 'Full Backup of CompanyCRM'; 
GO 

источник
1
@Shawn: OP сказал, что «Потеря данных за 1 день в этот момент будет стоить десятки тысяч долларов против пары сотен за этот раз в прошлом году», где он сказал, что может потерять данные за 1 день ?!
Marian
8
  • Резервные копии в SQL Server не нарушают работу. Т.е. база данных остается работоспособной. Прочитайте документацию.
  • Делайте полное резервное копирование каждый день, а затем отправляйте (копируйте) резервные копии журнала (опять же, документация имеет ... документацию) более регулярно - примерно каждые 15 минут или около того.
TomTom
источник
4
Я думаю, что резервное копирование - это то, что вам не нужно, как практическое руководство, но полное чтение документации - это важно для бизнеса И это - серьезно - важно. Не готовить яйца стиль. Наймите профессионала.
TomTom
2
Жаль, что я не могу голосовать за ответы на этом сайте ...
RSolberg
1
@RSolberg: ответ TomTom действителен, наряду с другими советами, которые вы уже получили. Я хотел бы предложить, чтобы вы не ожидали, что кто-либо из респондентов покажет вам базовый синтаксис резервного копирования. Хотя я вижу, Шон был достаточно любезен, чтобы сделать это. Для разработки стратегии BACKUP недостаточно. Вам нужно соединить его со стратегией RESTORE, чтобы все было в силе, когда вам это нужно.
Marian
2
@RSolberg: прости, что разозлил тебя. Это не предназначено. Но как это сообщество не помогло? У вас есть хорошие и действительные ответы (и комментарии). Ваше собственное сообщение было таким: «Потеря данных за 1 день на этом этапе обойдется в десятки тысяч долларов против пары сотен в прошлом году». Таким образом, вам нужна надежная стратегия резервного копирования и восстановления, чтобы вы туда не попали. Надежная стратегия основана на знании основ. Которые приходят из чтения и понимания руководства. Извините, если вы поняли что-нибудь еще!
Мариан
2
Я согласен с @RSolberg, что большинство ответов здесь не показывают, «как» это сделать, но это также потому, что в вопросе не хватало некоторых деталей «что», вы не поняли Рассела. Вы должны рассказать нам немного больше о том, что вам нужно, но я согласен с вами, что сайт не должен быть о "RTFM n00b". Кроме того, как вы указали, у вас есть 10k на переполнение стека , поэтому вы наверняка понимаете пометки комментариев, которые являются грубыми или разрушительными. В будущем вы должны сделать это раньше, а не кипеть от разочарования.
Jcolebrand
6

Первое, что вам нужно сделать, это выяснить, сколько данных вы можете позволить себе потерять. До тех пор вы не будете знать, как часто делать резервную копию базы данных. Это не тот номер, который вы должны придумать. Это то, что должен решить бизнес (или генеральный директор в небольшой компании). Первый номер, с которым они собираются вернуться - 0 минут. Что может быть сделано, но это будет очень дорого. На самом деле наименьшее количество данных, для которых вы можете создавать резервные копии, составляет примерно каждые 2 минуты. Если объем данных, изменяющихся в системе, достаточно мал, вы можете делать резервные копии каждую минуту.

Для создания резервных копий журнала транзакций, что вам нужно сделать, вам нужно перевести базу данных в режим полного восстановления.

Если вы можете позволить себе потерять данные за 5 минут, вы, вероятно, захотите делать полное резервное копирование ежедневно, а резервные копии журнала транзакций - каждые 5 минут. Если вы можете потерять данные за 15 минут, вам потребуется делать полное резервное копирование и резервное копирование журнала транзакций каждые 15 минут.

Другой вариант - делать еженедельные полные резервные копии, ежедневные разностные резервные копии и резервные копии журналов транзакций каждые x минут, о чем я говорил выше.

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

Все резервные копии, которые используют базу данных BACKUP и инструкцию BACKUP LOG, выполняются в режиме онлайн и не мешают пользователям получать доступ к базе данных.

mrdenny
источник
Я на самом деле вполне могу оценить, сколько данных мы можем потерять. Малые предприятия требуют, чтобы люди носили много головных уборов, так как ИТ-директор, я склонен ежедневно принимать участие в принятии бизнес-решений.
Р.С.Лолберг
1
Это сделает обсуждение намного короче.
Мрденни
3

Допустим, у вас общий деловой сценарий с самым загруженным временем: с 9 утра до 5 вечера с понедельника по пятницу. Тогда я бы предложил: полное резервное копирование в воскресенье вечером. Разностные резервные копии в 8 часов утра, 6 часов вечера и 1 час ночи (чтобы сократить время восстановления). Регистрируйте резервные копии каждый час или в зависимости от того, что требует ваш бизнес.

В зависимости от срока хранения у вас должно быть задание автоматической очистки для удаления старых файлов резервных копий. Все это может быть создано с использованием планов обслуживания SQL. Проверьте эту ссылку для SQL 2005 .

Вы должны хранить свои резервные копии на резервных дисках (зеркальных) или использовать ленты для внешнего хранилища. Пользователи могут продолжать работать в системе, пока выполняются резервные копии.

StanleyJohns
источник
2

Я бы не делал полную резервную копию каждую ночь. Если это большая база данных, то это может занять очень много времени, не говоря уже о том, чтобы занимать много места в СМИ. Делайте полное резервное копирование каждые выходные и разностное резервное копирование каждую ночь. Затем делайте резервное копирование журнала транзакций (при условии, что ваша база данных полностью восстанавливается) каждый час или каждые полчаса, но убедитесь, что эти файлы .bak и .trn находятся на отдельном диске в случае сбоя диска.

Томас Стрингер
источник
Метки были потеряны, это не огромная база данных. В настоящее время он работает на экземпляре SQLExpress.
Р.С.ольберг
1
Десятки тысяч долларов, работающие на Express? Интересно!
Андрей Ринея
На самом деле, нет. В зависимости от того, что вы храните (без текстов, без двоичных файлов) - это 10 гигабайт данных. Вы можете запустить систему учета для большой компании - СЕРЬЕЗНО крупной компании - в 10 гигабайт. Интернет-магазин со 100 000 заказов в день может легко обойтись стороной в 10 гигабайт.
TomTom
1

Можете ли вы синхронизировать папку резервных копий в облачном хранилище ночью, чтобы получить внешнее хранилище? Поскольку я почти уверен, что это для медицинской компании, есть ли достаточно безопасные для соответствия HiPA? Или, может быть, просто супершифровать их?

Сценарий хотя бы помещает копию резервной копии в общий сетевой ресурс? Таким образом, если физическая коробка взрывается ...


источник
Да для всего вышеперечисленного. На самом деле мы выполняем резервное копирование на сетевой диск с зеркальным отображением и копируем данные из этой среды в защищенный центр обработки данных.
Р.С.ольберг