Стратегия резервного копирования SQL Server 2005

Question

Я управляю веб-приложением для клиента со следующими спецификациями:

• ASP.net 3.5 запуск на виртуальном веб-сервере Windows 2003
• Стандартный сервер SQL Server, на котором размещается база данных
• Текущий размер базы данных 6 ГБ, со скоростью роста 1 ГБ в месяц
• Одна-единственная таблица отвечает за 98% размера, содержит наиболее важные данные для клиента
• Журнал не ведется для этой большой таблицы, в этой таблице выполняются только выборки
• Для резервного копирования доступно 50 Гб места на FTP

Учитывая этот сценарий, какова была бы наилучшая стратегия для резервного копирования SQL и какой инструмент лучше всего подходит для этой задачи (включая коммерческие приложения, клиент может оплатить лицензионный сбор)?

Answer 1

Вот стратегия, которую мы используем для CodePlex.com:

• Все серверы SQL выполняются с одноранговым сервером, использующим зеркальное отображение SQL
• Еженедельное полное резервное копирование (хранится на отдельном диске от баз данных)
• Ежедневное дифференциальное резервное копирование (хранится на отдельном от баз данных диске)
• Резервное копирование журнала транзакций каждые 5 минут (хранится на отдельном диске от баз данных)
• Ежедневное резервное копирование на магнитную ленту
• Еженедельные резервные копии на магнитной ленте, сделанные за пределами сайта

Тоже очень важно протестируйте свои резервные копии! Исследования показали, что более 30% непроверенных процедур резервного копирования имеют недостатки.Вот наша стратегия тестирования резервного копирования:

• Каждые 30 минут проверяйте наличие полной резервной копии файла (используя запланированную задачу)
• Каждые 30 минут проверяйте существование дифференциального файла резервной копии (используя запланированную задачу)
• Каждые 30 минут проверяйте наличие файла резервной копии журнала транзакций (используя запланированную задачу).
• Каждые 30 минут проверяйте, настроено ли зеркальное отображение базы данных (с помощью запланированной задачи)
• Каждый день выполняйте тестовое восстановление полной + дифференциальной резервной копии и сообщайте о количестве строк таблицы (используя запланированную задачу).
• Раз в месяц выполняйте тестовое восстановление самой последней резервной копии на магнитной ленте и проверяйте данные

Answer 2

Это зависит от того, насколько важны данные.Однако вот как бы я это сделал.1.Выполняйте полное резервное копирование каждый день.2.Запускайте дифференциальное резервное копирование каждые 4 часа.3.Выполняйте резервное копирование журнала транзакций каждые 15 минут 4.Сохраните копию на сайте и удалите копию с сайта, как только будет выполнено резервное копирование.

База данных не слишком велика, и это легко выполнимо.

Используйте сторонний инструмент, такой как Резервное копирование Redgate SQL и это автоматически сжмет и зашифрует резервную копию базы данных для вас.Я широко использовал его и являюсь большим поклонником.

Кроме того, если у вас есть другой доступный сайт, а данные очень важны, вы можете подумать о настройке доставки журналов.

Answer 3

Это VPC?Можете ли вы устанавливать приложения?

http://www.jungledisk.com/

Это то, что мы используем - создаем задание sql, которое создает резервную копию каждый день, затем используем эту службу для отправки копии обратно в службу Amazons S3.Если нет, возможно, у вас могло бы быть локальное приложение, которое извлекает резервную копию на компьютер, а затем отправляет ее / w S3 webservice, или все еще использует Jungledisk.

Это очень важно!Если ваше приложение выходит из строя, это причиняет боль!Также убедитесь, что вы сделали резервную копию вашего развернутого приложения и хранящихся в нем ресурсов...т. е.загруженный контент в каталог вашего хранилища приложений.

Answer 4

Я должен был ввести свой ответ на ваш вопрос, но я понял, что где-то есть гораздо больше ресурсов, таких как эта статья в SQLServerCentral.com.Вы также можете найти множество "Рекомендаций по резервному копированию". как этот.

Answer 5

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