Наименьшее возможное резервное копирование ... с SQL Server

37

Ежедневно мы отправляем наши резервные копии SQL Server через WAN. Нам нужно минимизировать размер этих резервных копий, чтобы они не длились вечно.

Мы не против, если наш процесс резервного копирования займет немного больше времени; в настоящее время нам необходимо переместить 30 гигабайт сжатой резервной копии по глобальной сети, что занимает более 10 часов.

Есть 2 варианта, которые мы должны получить меньшие ежедневные резервные копии.

  1. Доставка журналов, что означает, что нам придется реструктурировать процесс аварийного восстановления.
  2. Удалите информацию из базы данных и перестройте ее с другой стороны (отбросьте некластеризованные индексы, упакуйте кластеризованные индексы на 100% - перестройте с другой стороны)

И то и другое потребовало бы изрядного количества работы с нашей стороны. Мы используем SQL Server 2008 pro, все резервные копии сжаты.

Существуют ли какие-либо коммерческие продукты, которые могут предоставить нам размер резервной копии, аналогичный варианту (2)?

Существует ли всеобъемлющий сценарий, который позволит нам выполнить (2)? (обработка индексированных представлений, отфильтрованных индексов, внешних ключей и т. д.)

Сэм Шафран
источник
2
Какова ваша текущая степень детализации и частота резервного копирования, пожалуйста (регулярное резервное копирование журнала? Ежедневно заполнено?) Вы используете Enterprise или стандартную версию? Обновление: вы небольшая компания DR на арендованном сайте или большая компания с постоянным DR сайтом? Если 1-й, у вас есть файловый сервер или SQL Server, работающий вне сайта
gbn
@ gbn, нам нужно оптимизировать ежедневную загрузку, мы используем предприятия, DR все локальные, и люди забирают вещи вне офиса. Небольшие резервные копии требуются для разработчиков и второго внешнего сайта, который у нас есть. примечание ... разработчики находятся вне офиса, в других странах с ограниченной пропускной способностью нам нужен минимальный размер передачи с серверов в Нью-Йорке (например) в Австралию. Мы синхронизируемся раз в несколько месяцев.
Сэм Шафран
1
Для тех, кто этого не понимает, это для самой SO-команды;)
jcolebrand
1
@ Сэм Шафран: есть ли какие-либо отзывы, пожалуйста, приняли ли вы что-то вроде моего предложения?
Гбн
@gbn ... все еще решая, что делать, я думаю, что "обычные" - возвратные материалы до работы в Орегоне осуществимы с решением, которое вы предложили. Тем не менее, «Сэму нужно скачивать SO db раз в месяц, проблема все еще очень и очень болезненная, потому что мне нужно перевезти 22 гигабайта в Австралию - когда реальность такова, что« настоящая »информация может легко уместиться в 10 гигабайт».
Сэм Шафран

Ответы:

22

Первая мысль, основанная на комментариях ...

Используйте разностное резервное копирование каждые, скажем, 6 часов, чтобы уменьшить размер / время резервного копирования + FTP. Затем уменьшите полное резервное копирование + FTP только на выходные. Это позволяет избежать сложности доставки журналов, просто сделать и лишь добавляет небольшую сложность к DR

Я чувствую, что дифференциальные резервные копии игнорируются ... Я предлагал использовать их раньше:

Edit: после комментария Jcolebrand я попытаюсь объяснить больше

Дифференциальное резервное копирование принимает только те страницы, которые были изменены. Вне всякого обслуживания индекса (которое может повлиять на большую часть базы данных), только несколько% страниц будут меняться в течение дня. Таким образом, дифференциальное резервное копирование намного меньше, чем полное резервное копирование перед любым сжатием.

Если у вас есть полная резервная копия, скажем, еженедельно, вы можете делать ежедневные дифференциалы и отправлять их за пределы площадки. Ежедневное полное резервное копирование с разницей все еще потребует, чтобы оба файла были удалены с сайта.

Это должно решить проблему быстрого получения данных от A до B, C и D.

Возможно, вам нужно восстановить как полный, так и последний дифференциал, чтобы получить последние данные, но вы можете обойти это с помощью NORECOVERY и файла STANDBY (я не пробовал его с восстановлением различий в течение многих лет, так как последний раз был в чистом DBA работа).

Дополнительным бонусом является то, что резервные копии diff не связаны с текущими резервными копиями журналов, поэтому вы можете отделить любое требование High Availability / DR от требования «получить данные для обезьян кода».

Я вижу некоторые проблемы, если у вас есть ежедневные полные резервные копии с помощью политики или аудита, но разностное восстановление можно применить до восстановления любого журнала, чтобы сократить время восстановления. В отличие от резервного копирования, diff и log log действительно взаимодействуют.

Надеюсь, я рассмотрел большинство основ ...

ГБН
источник
Hyperbac - очень умный инструмент сжатия, который позволяет сжимать резервные копии и оставлять все планы обслуживания и задания без изменений, поскольку он обрабатывает файлы на уровне операционной системы. Если они не хотят ничего менять, а просто добавляют новый инструмент в коробку, им обязательно стоит попробовать. Я знаю, что использовал его и полюбил его для SQL 2005. Но для большего сжатия они все равно должны выполнять некоторый ручной труд ...
Marian
@ Мариан, я ... почти уверен, что Брент О - просто нуждающийся консультант.
Jcolebrand
@Marian: есть ограничение на сжатие и большее сжатие = больше процессора / времени. Наименьшей резервной копией будет та, с наименьшим входным значением = дифференциалом, независимо от инструмента / формата сжатия. Ссылка о времени и соотношении Один : вы можете дать экстремальное сжатие, но это займет больше времени, а для сжатого файла объемом 30 ГБ это может занять больше времени, чем FTP ...
gbn
Я согласен с вами в том, что коммерческие инструменты имеют более высокую степень сжатия, чем MS, и их можно настраивать (без использования ЦП, выделенных для операции), они предлагают шифрование ... и другие функции. Я не обязательно хвалить их (они не очень дешевые), я просто сказал, что некоторые из них можно использовать в сочетании с текущими резервными копиями SQL Server (full, diff, log) без изменения среды, что, кажется, ребята потребность / хотите. @jcolebrand: получил, спасибо!
Мариан
13

Существуют коммерческие продукты, которые могут помочь вам сжать резервные копии лучше, чем нативное сжатие 2008 года. Примерами являются RedGate Backup , Hyperbac , Idera SQL Backup , Litespeed Backup .

Они поставляются с добавленной стоимостью высокой загрузки ЦП и типов файлов, которые необходимо обрабатывать инструментами, не входящими в комплект поставки MS. Это за исключением сжатия Hyperbac (теперь приобретенного Redgate), которое прозрачно обрабатывает файлы и позволяет создавать zip-совместимые файлы (а также не нуждается в сторонних инструментах).

Но нет инструмента, который бы предлагал вам файл того размера, который вы бы получили, выполнив ручную очистку. Пожалуйста, просмотрите статью Брента Озара: как сжимать резервные копии SQL Server , он посоветует сделать те же шаги, что и в пункте №. 2.

Мэриан
источник
RedGate FTW !!!!
Хоган
@ Хоган: если вы не можете победить их, купите их. Это очень хороший пример :-). В любом случае, оба продукта, которые теперь являются частью Redgate и обрабатывают сжатие базы данных, могут успешно сосуществовать.
Мариан
12

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

Нет. Существует множество продуктов для сжатия резервных копий (Quest LiteSpeed, Red Gate SQL Backup, Idera SQLSafe, Hyperbac и т. Д.), Но все они работают, просто сжимая выходные данные процесса резервного копирования SQL Server. Некоторые из них делают это хитрыми способами - HyperBac и опция Engine LiteSpeed ​​являются драйверами фильтра файловой системы, то есть они перехватывают вывод на пути к диску - но конечный результат всех этих продуктов - просто сжатый вывод резервной копии.

Вопрос 2. Существует ли комплексный скрипт для сброса всех этих дополнительных данных?

Со временем, по мере того, как вы будете хранить больше истории в базе данных (4, 5, 8, 10 лет), вы не захотите вырывать все данные индекса и перестраивать их на другой стороне глобальной сети. Вместо этого вы хотите просто передать измененные данные, и вот тут начинается доставка журналов.

Ты не должен этого делать.

Но если вы действительно, действительно хотите это сделать (и нет, я вам не помогу), вы можете сделать это с помощью резервных копий файловой группы. Настройте группы файлов вашей базы данных следующим образом:

  • Основная файловая группа (обязательно, но оставьте пустым)
  • Файловая группа ClusteredIndex (поместите ваши кластерные индексы здесь)
  • Файловая группа ExtraneousCrap (все остальное здесь)

Начните создавать сжатые резервные копии файловых групп только из первых двух и скопируйте их на свой сервер DR. Вы можете использовать возможность резервного копирования и восстановления файловой группы в SQL Server 2008, чтобы просто восстановить первичные и файловые группы ClusteredIndex, и тогда они сразу же будут доступны для запросов. Они не будут реально работоспособны до тех пор, пока вы не подключите файловую группу ExtraneousCrap к сети, но для этого тоже есть неприятный трюк - в книге о глубоких погружениях MVP есть глава, посвященная редактированию системных таблиц, чтобы сделать файловую группу ExtraneousCrap и все из связанных индексов исчезают. Этот трюк опасен, совершенно не поддерживается, и чертовски плохая идея - но, эй, вы просили об этом.

Brent Ozar
источник
10

Я рекомендую перейти на что-то вроде доставки журналов. По сути, если у вас есть выбор отправки 30 гигабайт в течение 24 часов по сравнению с отправкой в ​​конце дня в течение более короткого временного интервала, скорость сети будет для вас меньшей проблемой.

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

В дополнение к сжатию сервера sql, вы можете реализовать сторонний инструмент, который имеет более высокое сжатие, например litespeed или redgate sqlbackup.

Кроме того, на стороне сети вы можете установить сетевые устройства, которые могут оптимизировать вашу пропускную способность на сайт DR. Раньше я успешно использовал Riverbed Appliance для получения резервной копии объемом 90 ГБ от FL до VA менее чем за 3 часа.

Другим вариантом может быть резервное копирование определенных групп файлов, за исключением индексов и т. Д., Но вы все еще застряли с кластерными индексами, и в зависимости от структуры вашей базы данных вы можете получить больше затрат / хлопот, чем пользы от такого подхода.

Благодарность

johndacostaa
источник
7

Если у вас есть на это деньги, а ваша архитектура это позволяет, зайдите на что-то вроде технологий Riverbed (http://www.riverbed.com/us/). Такое устройство в сочетании со сценарием репликации или доставки журналов может быть лучшим выбором.

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

Другая возможность - вместо того, чтобы беспокоиться о том, чтобы передать все эти данные, настроить среду Citrix и передать их вам. С Citrix у вас есть минимальные требования к пропускной способности между клиентом и хостом, и вы можете делать то, что вам нужно локально, и не беспокоиться о необходимости реплицировать эти изменения в другом месте. Просто мои 0,02 доллара

SQLChicken
источник
Можете ли вы объяснить это больше? Я знаю, что это для команды StackExchange, поэтому я уверен, что им понравится более углубленное прохождение;)
jcolebrand
Хаха, здесь есть над чем подумать. Какой момент вы бы хотели, чтобы я изложил?
SQLChicken
Я думал о доставке репликации / журналов, но это было как две недели назад, поэтому я сомневаюсь, что это так же важно сейчас. Кроме того, я просто перечитал и увидел часть о Citrix, и тогда я мог бы сказать вам (как сейчас), что они этого не делают. Они просто занимаются локальной разработкой с использованием инфраструктуры DVCS и просто хотят получить данные для тестирования / воспроизведения / подтверждения. Также возможно для дампов данных.
Jcolebrand
Попался. Тогда, как уже говорили другие, сторонние поставщики, такие как Redgate и Quest, имеют очень хорошие инструменты сжатия резервных копий, которые помогут вам удовлетворить их потребности. Другим потенциальным решением является SQL Azure. В настоящее время ограничение размера базы данных составляет 50 ГБ, но они подняли плату за любые загружаемые данные, поэтому это может быть экономически эффективным решением.
SQLChicken
4

Я бы использовал репликацию транзакций SQL. Ваша первоначальная загрузка займет некоторое время, но как только вы начнете работать, вы сможете только отправить ту информацию, которую хотите. Например, если у вас есть только 3 или 4 таблицы, которые обновляются, вы можете отправить только эти 3 или 4 таблицы.

Вы также можете выбрать, что вы хотите отправить. FK, кластеризованные / некластеризованные индексы, схемы секционирования таблиц, хранимые процедуры и многое другое.

http://www.sql-server-performance.com/2010/transactional-replication-2008-r2/

Если это не вариант, вы можете использовать REDGATE SQL BACKUP - http://www.red-gate.com/products/dba/sql-backup/ . Я использовал это раньше и получил степень сжатия до 90%. Гораздо меньше, чем у SQL.

SqlSandwiches
источник