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

В настоящее время у меня есть запланированное задание, которое запускается каждую ночь в 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 становится привлекательным.

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

Поскольку вы сказали, что можете потерять данные за 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 

• Резервные копии в SQL Server не нарушают работу. Т.е. база данных остается работоспособной. Прочитайте документацию.
• Делайте полное резервное копирование каждый день, а затем отправляйте (копируйте) резервные копии журнала (опять же, документация имеет ... документацию) более регулярно - примерно каждые 15 минут или около того.

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

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

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

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

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

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

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

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

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

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

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

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