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

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

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

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

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

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

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

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

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

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

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

• Как выполнить резервное копирование небольшой базы данных в SQL Server 2008 R2 Express Edition,
  используя для этого резервное копирование DIFF

  Я бы хотел, чтобы все было максимально просто с точки зрения восстановления, при этом сводя к минимуму количество потерянных данных в случае сбоя

• Плюсы и минусы стратегий резервного копирования SQL Server и соответствующие сценарии их использования
• Миграция большой базы данных
  Использование резервных копий DIFF для ускорения миграции сервера резервного копирования / восстановления

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

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

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

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

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

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

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

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

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

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

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

Вопрос 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 и все из связанных индексов исчезают. Этот трюк опасен, совершенно не поддерживается, и чертовски плохая идея - но, эй, вы просили об этом.

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

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

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

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

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

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

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

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

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

Я бы использовал репликацию транзакций 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.