В настоящее время мы делаем резервные копии наших баз данных MSSQL 2000 и 2005, используя программное обеспечение для копирования файлов на ленту каждую ночь. Размеры базы данных 14-16 ГБ и 500 МБ.
Поскольку SQL-сервер может выполнять резервное копирование базы данных в файл, не лучше ли запланировать SQL-сервер для создания файла резервной копии и последующего резервного копирования этих файлов на ленту? Также, если мы будем использовать этот метод, можно ли каким-то образом создать журнал транзакций, которые были завершены с момента последней резервной копии, чтобы мы могли воссоздать базу данных и применить дополнительные транзакции?
Примечание. Моя самая большая ошибка с SQL Server (все редакции) - это резервное копирование журналов транзакций.
Каждые 30 минут мы выполняем полное резервное копирование нашей базы данных SQL и журналов транзакций на диск (на другом сервере, в другом SAN) для файлов с отметками даты (довольно простой сценарий SQL и SSIS).
Наш сценарий также создает сценарий «restore.sql» для восстановления последней полной резервной копии и всех журналов транзакций до этой даты.
Затем мы архивируем файлы старше 2 дней, удаляем все, что старше 30 дней (но сохраняем резервные копии на конец месяца в архиве). Мы копируем этот диск за пределы площадки (нам повезло, что между крупными сайтами 200 миль и между ними большое WAN-соединение).
Затем мы делаем резервную копию на ленту. (Пояс, подтяжки и другие подтяжки! В основном по политическим причинам)
Мы запускаем множество баз данных SQL Server, и коммерческие инструменты либо слишком дороги, либо просто не дают нам окупаемости. Но я бы рекомендовал RedGate SQLBackup для небольших установок.
На самом деле нет причин НЕ использовать встроенные функции резервного копирования SQL Server. Это здорово, понимает журналы транзакций и предоставляет большую часть необходимых функций. (Сторонние решения для резервного копирования SQL Server великолепны, потому что они работают с API-интерфейсами, предоставленными Microsoft, и обычно обеспечивают поддержку шифрования и сжатия, а сжатие не только экономит дисковое пространство, но обычно сокращает время резервного копирования и восстановления.)
Так что да ... Я бы рекомендовал делать резервные копии с помощью SQL Server.
И обязательно делайте РЕГУЛЯРНОЕ резервное копирование журнала транзакций. (Я бы рекомендовал делать их каждые 15 минут или реже - регулярные резервные копии файлов журнала помогают сохранить ваш файл журнала компактным / средним. 1 и по какой-то причине конечные пользователи всегда недовольны, когда сервер выходит из строя, и им приходится повторять всю свою работу за последние x часов с момента последнего файла журнала или полного / дифференциального резервного копирования.) Затем для целей избыточности используйте robocopy, syncback, репликация файловой системы или что-то еще, чтобы переместить копии этих резервных копий в другое место для защиты от сбоев оборудования / дисков или пожаров в центре обработки данных и т. д.
Не стесняйтесь смотреть эти два бесплатных видео для получения дополнительной информации и идей:
http://www.sqlservervideos.com/video/backup-options
http://www.sqlservervideos.com/video/sqlbackup-best-practices/
[1] [Журнал SQL Server: повышение производительности хранилища]3
Вы имеете в виду, что в настоящее время выполняете резервное копирование файлов MDF и LDF базы данных на ленту? Я думаю, что это может быть нормально, если база данных отключена, пока вы это делаете (т.е. база данных отключена или служба SQL отключена), но если вы попытаетесь сделать это, пока база данных используется, вы, вероятно, получите резервные копии, которые не работают, потому что файлы будут изменены во время копирования.
По моему опыту, создание полной резервной копии SQL и запись ее на ленту гораздо более распространены.
Кроме того, отвечая на ваш второй вопрос, SQL Server поддерживает резервное копирование журнала транзакций. Документация MSDN на Модель полного восстановления было бы хорошим местом, чтобы начать читать.
Как вы видели из ответов, большинство людей сначала делают резервную копию на диск, а затем на ленту. Что я часто видел (и рекомендовал), так это немедленное резервное копирование на диск, который находится на самом сервере (это может быть хранилище, подключенное к SAN, ключ в том, что резервная копия не записывается по сети). Как только это немедленное резервное копирование будет выполнено, оно будет скопировано на центральный сервер резервного копирования. Вы сразу же сохраняете копию того, что нужно восстановить локально. На этом сервере резервного копирования вы храните резервные копии на несколько дней. Таким образом, если вам действительно нужно вернуться к предыдущему дню или двум, вы не запрашиваете ленту. И, конечно же, вы делаете резервную копию этого центрального сервера резервного копирования на ленту. Так что это покрывает вашу способность восстанавливаться.
Что касается типов резервного копирования, которые вам следует делать, если вы хотите восстановить все транзакции и иметь возможность выполнять то, что мы называем восстановлением на момент времени, вам необходимо убедиться, что для баз данных установлена модель восстановления полного восстановления, и вы Вы захотите делать полные резервные копии вместе с резервными копиями журнала транзакций. Вы можете чередовать разностные резервные копии, чтобы уменьшить количество восстанавливаемых файлов. Все это описано в онлайн-книгах и даст лучшее описание, чем любой из нас может дать в сообщении на форуме.
Что касается сторонних продуктов, таких как LiteSpeed и Red Gate's SQL Backup, они раньше были быстрее, чем собственное резервное копирование. Это потому, что они используют API, которого нет в SQL Server. Так было в SQL Server 2000, но я не уверен, так ли это до сих пор. Однако они выполняют шифрование и сжатие, поэтому их стоит рассмотреть, учитывая размер ваших БД.
Сценарий резервного копирования на диск прост и работает очень быстро:
osql -S [ip_of_server] -Q "РЕЗЕРВНАЯ БАЗА ДАННЫХ [имя_базы_данных] НА ДИСК = 'C: \ Backups \ Backup.bak' "
Не работает резервное копирование в другое место по сети (в любом случае, это не очень хорошая идея) с помощью пути UNC. В любом случае проще делать локальные резервные копии и хранить их в зашифрованном виде.
Жесткий диск дешев и надежен. Некоторое время назад мы избавились от наших лент и никогда не оглядывались назад.
Мне больше нравятся эти инструкции: http://www.sqldbatips.com/showarticle.asp?ID=27