Поэтому серверы и базы данных в большинстве случаев сначала объединяют, а затем приступают к их расширению.
Размер резервируемых баз данных, безусловно, важная проблема, но далеко не единственная. Требования к защищенности резервных копий также возрастают. До сих пор свежи воспоминания о нескольких недавних громких аферах, связанных с данными. В растущих и все усложняющихся средах ИТ восстановление требуется чаще, чем там, где работают несколько пользователей. К тому же сегодня слишком часто владельцы требуют предоставить отчет по большим объемам данных в любой момент времени.
Все это приводит к появлению очень крупных баз данных, причем для выполнения задач администрирования предоставляются все меньшие интервалы времени, а отвечать за последствия приходится администратору. Он должен более эффективно использовать доступное для резервного копирования время, отвести для записи резервных копий как можно меньше места, а в случае ошибки максимально быстро восстановить базу данных.
SQL Server предлагает два варианта резервного копирования: сохранение на диск и на ленту. При этом вся база данных в несжатом виде передается на подсистему хранения по сети, что может привести к перегрузке сети и отрицательно сказаться на производительности. Пропускная способность наиболее распространенных систем хранения составляет около 50 Мбайт/с, у более новых продуктов — до 250 Мбайт/с. При таких условиях сохранение базы данных размером 1 Тбайт займет несколько часов — слишком много для ежедневного или хотя бы относительно регулярного резервного копирования.
Ленточные системы хранения представляют собой более дешевую альтернативу и поэтому широко распространены. Однако резервное копирование занимает еще больше времени, чем при использовании дисков. Даже если соответствующую процедуру удастся более-менее органично вписать в ежедневный распорядок дня, то в случае необходимости восстановления возможны неприятные сюрпризы, поскольку, быстро реанимировать базу данных не получится.
Передача журналов (Log Shipping) — еще один вариант резервного копирования, предусмотренный в SQL Server. После создания копии записи о транзакциях постоянно переносятся на нее с используемой базы данных. Преимущества такого подхода очевидны: копия базы данных всегда достаточно актуальна, записи о транзакциях гораздо меньше загружают сетевой трафик и при необходимости их можно считать.
ПРИМЕНЯТЬ ЛИ ТРАДИЦИОННЫЕ МЕТОДЫ?
Проблема высокой стоимости и затрат времени вынуждает заняться поиском альтернативных вариантов. К примеру, два первых варианта резервного копирования можно комбинировать. Новые резервные копии размещаются на жестком диске, а более старая информация сохраняется и архивируется на лентах. Последней копии данных достаточно для более чем 90% всех случаев аварийного восстановления. Таким образом можно использовать ценовое преимущество лент, а в критической ситуации достаточно быстро восстановить базу данных с диска.
Помимо перечисленных, существует ряд других возможностей оптимизации процессов резервного копирования и аварийного восстановления. Прежде чем отправлять файл по сети, данные можно сжать. В этом отношении функциональность системы резервного копирования в SQL Server ограничена, хотя в версию 2008 г. внесены некоторые улучшения. Возможность сжатия резервной копии появилась, но эта функция не особенно гибка. Однако выбор степени сжатия может иметь важное значение для оптимизации процессов резервного копирования и аварийного восстановления и требует отдельного решения в каждой конкретной ситуации. Чем сильнее сжатие, тем меньше файл с резервной копией и тем меньше времени потребуется на восстановление. Вместе с тем, чем выше степень сжатия, тем дольше создается резервная копия. Эффективность сжатия зависит от используемого аппаратного обеспечения. SQL Server не предусматривает возможности предварительного тестирования или анализа этого процесса.
Для обеспечения высокого уровня безопасности может потребоваться шифрование резервной копии. В SQL Server 2008 реализована возможность прозрачного шифрования отдельных данных или баз данных. Это сокращает преимущества от сжатия резервных копий, поскольку зашифрованные данные сжимаются в гораздо меньшей степени. Кроме того, лишь немногие предприятия решатся сразу же мигрировать на новую версию SQL Server, так что новые функции для них пока недоступны.
Эти пробелы заполняются другими производителями, к примеру, Quest Software выпустила решение Litespeed for SQL Server. Разработчики Microsoft тестировали это решение на базе данных размером в 1 Тбайт. Сохранение всей базы данных длилось всего 31 мин, резервная копия заняла около 115 Гбайт. В самом SQL Server (более ранних версий) размер резервной копии соответствует полному объему базы данных, то есть в этом случае действительно почти 1 Тбайт. Сжатие на стороне сервера обес-печивает меньший размер резервных копий и более быстрое сохранение на выбранной системе хранения. Поскольку дополнительно можно ограничить выделение ресурсов процессора на резервное копирование, влияние резервирования на сеть можно регулировать.
Помимо сжатия, такие программные решения имеют ряд дополнительных преимуществ. Выбор решения зависит от того, какие требования предъявляются предприятием к резервному копированию и аварийному восстановлению. В зависимости от политики безопасности может иметь смысл одновременное осуществление шифрования и сжатия данных. Зачастую достаточно восстановить лишь отдельные объекты или даже строчки таблицы, а не всю базу данных. Такое восстановление на уровне объектов (Object Level Restore) экономит время, средства и сетевой трафик и позволяет осуществлять чтение содержимого баз данных из сохраненных файлов без необходимости полного восстановления очень крупных баз данных. Log Reader в Litespeed имеет доступ
к записям транзакций SQL Server и может анализировать все изменения в базе данных с указанием даты и идентификационного номера транзакции.
В SQL Server отсутствует возможность предварительной проверки разных опций, однако оптимальные настройки для эффективного резервного копирования варьируются в зависимости от аппаратного обеспечения, разновидности системы хранения, а также вида данных (см. Рисунок 1). Еще интереснее, если одновременно используются различные системы управления базами данных. Некоторые решения сторонних производителей предоставляют удобные хранилища, обеспечивающие обзор всех действий по резервному копированию и аварийному восстановлению. При выборе продукта необходимо проверить, удастся ли органично вписать его в среду SQL Server. Для этого Microsoft предоставляет интерфейс виртуального устройства (Virtual Device Interface, VDI). Столь же важно, чтобы резервная копия, созданная с помощью иного решения, могла быть считана, даже если при аварийном восстановлении это решение будет недоступно.
ЗАКЛЮЧЕНИЕ
SQL Server предлагает некоторые полезные опции для резервного копирования, однако их можно удачно дополнить решениями сторонних производителей. В частности, сжатие данных перед передачей по сети и их шифрование позволят сэкономить средства и время, а также будут способствовать обеспечению безопасности.
Иро Маттила – системный консультант в Quest Software.