В текущей среде клиентское приложение было развернуто на одном конечном устройстве, например. ноутбук. Клиентское приложение записывает и извлекает информацию, которая необходима для соблюдения нормативных требований и соответствия нормативным требованиям, и на сегодняшний день резервное копирование данных отсутствует.
Поскольку данные считаются важными для нормативной отчетности и отчетности о соответствии, изучаются варианты резервного копирования и архивирования.
Какие существуют варианты резервного копирования, архивирования и восстановления клиентской базы данных?
Окружающая среда
Требования
Я предполагаю, что ваш бюджет ограничен (потому что это всегда так, не так ли?).
Направляйтесь к Сайт Олы Халленгрен и возьмите копию его раствора для обслуживания. Запустите сценарий после того, как вы настроили основы:
SET @BackupDirectory = N'C:\Backup' -- Specify the backup root directory.
SET @CleanupTime = NULL -- Time in hours, after which backup files are deleted. If no time is specified, then no backup files are deleted.
Поскольку вы используете выпуск Express, у вас не будет агента SQL, который позволяет вам планировать задачи, поэтому используйте планировщик задач Windows для настройки резервного копирования. Поскольку ваш RPO составляет 15 минут, я бы рекомендовал 1 полный день (например, в полночь) и резервное копирование журнала каждые 5 минут. Убедитесь, что ваши базы данных находятся в FULL.
Типичная работа будет выглядеть так:
sqlcmd -E -S MYSERVER\MYINSTANCE -d master -Q "EXECUTE dbo.DatabaseBackup @Databases = 'ALL_DATABASES', @Directory = N'F:\SQLBackup', @BackupType = 'FULL'" -b
(планируйте это каждый день)
sqlcmd -E -S MYSERVER\MYINSTANCE -d master -Q "EXECUTE dbo.DatabaseBackup @Databases = 'ALL_DATABASES', @Directory = N'F:\SQLBackup', @BackupType = 'LOG'" -b
(планируйте это каждые 5 минут)
Пока вы используете это решение, изучите другие возможности обновления статистики и обслуживания индексов, ...
При восстановлении восстановите ПОЛНУЮ и все последующие резервные копии журнала по порядку. Не забудьте восстановить с помощью NORECOVERY пока вы не примените последний файл журнала. Поскольку файлов может быть много, вы можете попробовать написать сценарий для этого. Смотри сюда для получения дополнительной информации об этом.
Теперь самое сложное. Если машина умирает, вы все равно не получите свою RPO, поэтому вам нужно получить резервные копии с машины (и, возможно, даже в место, которое географически далеко). Здесь есть масса вариантов.
Обычно я просто создаю резервную копию в другом центре обработки данных / машине с помощью инструмента резервного копирования, который используется в среде для резервного копирования плоских файлов. Если его нет, возможно, вы захотите получить учетную запись Amazon Web Services и переместить ее на S3. Если вы беспокоитесь о безопасности, вы можете зашифровать свои резервные копии с помощью таких приложений, как Arq.
Итак, финал: RTO. Это может быть сложно, в зависимости от того, как вы на это смотрите. Есть ли у вас команда, которая может развернуть новый SQL Server при необходимости и восстановить резервные копии (из AWS)? Есть ли система ротации по вызову? ты собираешься брать трубку 24/7?
Если вы хотите автоматизировать это, все станет намного сложнее, и вам обязательно потребуются дополнительные серверы. Поскольку вы находитесь в 2008 году, вы можете настроить доставку журналов. Это функция SQL Server, которую можно бесплатно использовать во всех возможных версиях. Он делает копию файлов журнала и восстанавливает их на вторичном сервере sql. Я могу уточнить, если хотите.
Пожалуйста, не забудьте тест ваш решение и следите за тем, чтобы резервные копии выполнялись правильно! Ничто так не отстой, как необходимость выполнять восстановление и замечать, что резервная копия не запускалась в течение 5 дней. Если это должно быть дешево, отправка результатов по почте работает, но это очень быстро устаревает. Может быть, загляните в систему мониторинга вроде Icinga если проблема в деньгах.
PSA: Я не участвую ни в одном из предлагаемых мной решений, это просто то, что я обычно делаю, когда сталкиваюсь с этой проблемой.
Я думаю, вы объединяете высокую доступность с резервным копированием. Это разные вещи. Группы доступности AlwaysOn не связаны с резервным копированием базы данных SQL. Вам также не нужно делать резервную копию базы данных на ферме SQL (чем бы вы ни считали ферму SQL). Вы можете просто создать сценарий резервного копирования базы данных через интервалы, соответствующие вашему RPO на клиентском компьютере, на котором установлен SQL Server Express.
В версии MSSQL Express отсутствует агент SQL Server. Вы можете использовать комбинацию OSQL Утилита (утилита командной строки) и планировщик Windows для выполнения t-sql BACKUP DATABASE заявление. Вы можете сделать резервную копию во внешнее хранилище (если это позволяет учетная запись процесса mssql). Вы можете использовать ПОЛНЫЙ режим восстановления и комбинацию BACKUP DATABASE / BACKUP LOG иметь вид непрерывного резервного копирования (т.е. резервное копирование журнала каждые 15 минут). Не забываем о системных базах данных (master, model, msdb).
Вы также можете использовать Dropbox (или аналогичный) в качестве внешнего хранилища. Фактически папка dropbox является локальной, поэтому у вас не будет проблем с доступом к сетевым папкам (учетная запись mssql Windows может ее ограничить). MSSQL 2008 R2 может сжимать данные при резервном копировании (не уверен, может ли экспресс-версия).