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

Question

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

• ASP.net 3.5 работает на виртуальном веб-сервере Windows 2003
• SQL Server Standard, размещающий базу данных
• Текущий размер базы данных 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 Backup , и он автоматически сожмет и зашифрует резервную копию базы данных для вас. Я использовал это широко и большой поклонник.

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

Answer 3

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

http://www.jungledisk.com/

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

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

Answer 4

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

Answer 5

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