Вместо того, чтобы придерживаться нашей обычной системы Backup Exec & LTO Tape, которую мы использовали для производственных серверов в прошлом, я ищу альтернативы нашему новому серверу SQL 2005, который будет запущен примерно через 2 месяца.
Какое программное обеспечение и оборудование вы используете для резервного копирования одного SQL-сервера? Этот сервер будет использовать умеренную нагрузку в обычные рабочие часы и практически не использовать в нерабочее время. Я ожидаю, что у меня будет не более 500 ГБ данных, для которых необходимо регулярно выполнять резервное копирование. В прошлом мы делали полные SQL-запросы и резервные копии системы за ночь в ленточной библиотеке, чередуя наборы лент еженедельно. Я бы хотел отказаться от хранения 8-10 лент в неделю и, возможно, использовать съемное хранилище, такое как Dell RD1000. Есть ли у кого-нибудь реальный опыт использования RD1000 для ночного резервного копирования? Точно так же Backup Exec по-прежнему является достойным выбором или мне следует искать в другом месте?
Спасибо!
Это сильно зависит от ваших требований. Если можно потерять целый день, можно делать полные резервные копии каждую ночь. В противном случае вы можете делать полные резервные копии каждую ночь и отправлять журналы в короткие сроки. С помощью этой конфигурации вы можете восстановить последнюю полную резервную копию и выполнить повтор транзакций до заданного момента времени, используя сохраненные журналы транзакций.
Другой вопрос, какой тип носителя вы выберете. Ленты в наши дни, ИМХО, не нужны. Жесткие диски и офшорные серверы в наши дни очень дешевы.
Уже почти год я использую Quest LiteSpeed для большинства производственных резервных копий вместо резервных копий Native SQL или агентов прямого переноса на ленту, таких как Backup Exec. Я пришел к выводу, что только для экономии места на резервном копировании оно стоит затрат на лицензирование. Следующее, что меня спасло, - это время как для резервного копирования, так и для восстановления. На мощном оборудовании сжатие не создает особых проблем, а резервное копирование 200 ГБ выполняется быстрее, чем резервное копирование 500 ГБ, независимо от того, как вы это делаете (YMMV, но мои резервные копии LS постоянно составляют четверть собственного размера резервной копии или меньше ). Вы по-прежнему можете использовать Backup Exec, но вам не понадобится агент SQL, потому что вы просто выполняете резервное копирование файлов резервных копий. Даже с резервным копированием системы, если вы перейдете с 10 лент в неделю на 5, вы сэкономите много денег в долгосрочной перспективе.
Восстановленная деталь великолепна из-за вариантов на уровне кирпича. Необходимость восстановления базы данных TB для исправления 5 записей осталась в прошлом, вы можете восстанавливать отдельные объекты или запросы к объектам в выбранном вами месте назначения. Там экономятся время, деньги, иногда немного здравомыслия.
Прошло много лет с тех пор, как я использовал агент Backup Exec, и, возможно, они добавили подобные функции, но с их сайта это не похоже. Помимо LiteSpeed есть и похожие решения, но я ими не пользовался, поэтому не могу комментировать их относительную ценность.
Не совсем ленточное или съемное решение, но мы используем доставку журнала транзакций каждые 10 минут на сервер горячего резервирования, а когда однажды у нас случился катастрофический сбой, мы просто указали строку подключения на 2-й сервер и продолжили транспортировку.
Во-первых, убедитесь, что вы используете либо собственные резервные копии SQL Server, либо SQL Backup / Litespeed / Hyperbac для резервного копирования на DISK. Хотя мне нравится переносить вещи на магнитную ленту, она ненадежна и недостаточно быстра для резервного копирования с SQL Server. BackupExec, Arcserver и другие решения на основе агентов никогда не были для меня достаточно надежными. Я бы использовал их для перемещения файлов с диска на ленту, но не из такого процесса, как SQL Server. Они просто терпели неудачи достаточно много раз в прошлом, поэтому я им не доверяю.
Ночное резервное копирование работает нормально, однако, если кто-то ударил по таблице или вы что-то испортили, есть вероятность, что вы захотите восстановить данные до последнего часа или минуты. Поэтому я был бы уверен, что у вас есть как минимум ежечасные резервные копии журнала транзакций.
Обычно я не храню резервные копии более чем за 2 дня, но это зависит от того, насколько далеко вам может понадобиться вернуться, и нормативных вопросов. Планы обслуживания в SQL Server 2005 могут помочь вам настроить их, а также удалить старые резервные копии. Обратите внимание: перед удалением старых создайте новую резервную копию.
Я знаю, что многие люди хотят просто использовать диск, и я понимаю, что ЕСЛИ вы можете получить свои данные за ночь. Это требует пропускной способности, и вы знаете, сможете ли вы это сделать. Если вы не можете достать его на проводе, сделайте это с помощью изоленты.
Iron Mountain или какой-то подобный сервис, вероятно, существует в вашем городе, чтобы ежедневно брать кассеты и пересылать их за пределы офиса. Вы также можете попросить их забрать USB-накопители, но следите за тем, чтобы все было регулярно.
Мы развертывали Резервное копирование Red Gate SQL для некоторых серверов такого размера. Кажется, что это значительно быстрее, чем Backup Exec для резервного копирования и восстановления на дисках. Это также довольно разумная цена.