Computerworld, США
С ростом объемов накопленных данных их резервное копирование превращается едва ли в неразрешимую задачу; между тем, иногда можно вообще отказаться от их восстановления
Обеспечение сохранности и своевременного восстановления баз данных всегда было задачей особой важности для ИТ-специалистов. В отличие от файловых систем, базы данных, как правило, представлялись для программных средств резервного копирования в виде огромных, монолитных контейнеров. И с ростом объемов данных задача резервного копирования и восстановления данных превращалась во все более серьезную проблему. Не так еще давно база данных размером 50-100 Гбайт считалась громадной. А сегодня уже можно нередко встретить транзакционную базу данных размером в терабайт, а то и больше, или хранилище данных емкостью в десятки терабайт. Так каким же образом организовать эффективное и рациональное обеспечение сохранности таких сред? Традиционные подходы, такие как создание резервных копий в ночное время, просто неадекватны, а принятая практика использования множественных разделенных зеркал (например, Business Continues Volume — BCV) может оказаться слишком дорогой при современных уровнях емкости систем хранения.
В разработке любой стратегии обеспечения сохранности первым шагом, безусловно, должен быть анализ требований к восстановлению данных (прежде всего, время восстановления и точка восстановления). При работе с очень большими базами данных особое значение приобретает также серьезный анализ требований к продолжительности хранения. Регулярно встречаются ИТ-среды, которые поддерживают копии баз данных 30-дневной давности или даже больше. Зачастую при дальнейшем анализе становится ясно, что эти старые копии для компании практически не представляют ценности. Действительно, поддержка избыточных копий многотерабайтных баз данных является бессмысленной тратой ресурсов.
Как бы странно это ни показалось на первый взгляд, но в некоторых случаях можно вообще отказаться от восстановления. К примеру, если для хранилища данных всегда доступен оригинальный источник информации, то вполне возможно, что воссоздать это хранилище заново будет намного дешевле, чем восстанавливать его.
В других ситуациях оправданным может оказаться сочетание сразу нескольких хорошо зарекомендовавших себя технологий, таких как поддержка журнала регистрации базы данных вместе с возможностями создания мгновенных снимков (что требует значительно меньше ресурсов, в том числе и памяти, нежели создание зеркал). Такой подход способен обеспечить требуемые уровни защиты как от физического, так и от логического разрушения данных. Кроме того, имеет смысл подумать и об использовании такого нового подхода, как непрерывное обеспечение сохранности данных (continuous data protection).
С другой стороны, возникает резонный вопрос: а разумно ли вообще создавать громадные, монолитные базы данных? Появляется все больше прикладных систем, в которых применяется архитектура, состоящая из нескольких небольших по размеру баз данных с общим слоем параллельных запросов. Такая архитектура значительно упрощает как обеспечение сохранности, так и масштабирование. К сожалению, проектные решения, как правило, принимаются людьми, стоящими в корпоративной иерархии на несколько уровней выше, чем те специалисты, в обязанности которых входит обеспечение сохранности данных и которым по-прежнему приходится заниматься их восстановлением, вне зависимости от того, хороша архитектура баз данных или нет.