VIP Studio - журнал «Современная наука» - Распределенная система резервного копирования для малых предприятий

Р егулярное резервное копирование данных является неотъемлемой частью успешного бизнеса. Потеря информации и невозможность быстрого ее восстановления может привести к огромным убыткам, вплоть до полного прекращения деятельности компании [1]. К сожалению, зачастую о проблеме начинают задумываться слишком поздно. Ситуация усугубляется в небольших компаниях, где может не хватать ресурсов для привлечения квалифицированных специалистов, способных качественно и надежно организовать резервное копирование.

В данной работе рассмотрен один из возможных подходов к решению проблемы. Хотя и существует ряд ограничений, препятствующих его использованию в крупных компаниях, у него есть ряд преимуществ, делающих его актуальным для небольших компаний. К преимуществам распределенной системы резервного копирования, предлагаемой в данной работе, можно отнести простоту внедрения, отсутствие необходимости в выделенном сервере, возможность задействовать имеющиеся ресурсы (неиспользуемое дисковое пространство) оптимальным образом.

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

К разрабатываемой системе были предъявлены следующие функциональные требования:

• работа по расписанию – резервное копирование должно начинаться автоматически в строго установленное время, это поможет минимизировать ошибки связанные с человеческим фактором (забывчивость человека);
• возможность разбиения резервной копии на части с добавлением избыточной информации – файл разбивается на n частей, дополнительная избыточная информация создается путем генерации еще m частей таким образом, что из любых n частей можно будет восстановить исходный файл, это позволит увеличить надежность системы;
• использование одноранговой p2p сети – после разбиения все части файла распределяются по сети, система должна обеспечивать их передачу, а также прием и сохранение;
• восстановление резервных копий – в случае отказа оборудования и утери данных, по запросу пользователя, система должна предоставить ему список резервных копий, доступных для восстановления, переслать части и восстановить из них исходный файл;
• гибкость настройки – параметры системы должны быть изменяемы, например, путь к файлам, резервные копии которых будут создаваться, путь, по которому сохраняются принятые части файлов, время начала работы, уровень избыточности;
• ведение журнала работы – все действия необходимо записывать в специальные файлы журналов, что поможет выявить неполадки в работе системы, оценить скорость проведения операций, принять верные решения, связанные с оптимизацией работы системы.

В качестве архитектуры системы выбрана одноранговая сеть p2p. P2p (peer-to-peer) – компьютерная сеть, основанная на равноправии участников. В такой сети отсутствуют выделенные серверы, а каждый узел (peer) является как клиентом, так и сервером. В отличие от архитектуры клиент-сервер, такая организация позволяет сохранять работоспособность сети при любом количестве и любом сочетании доступных узлов [3]. Таким образом, разрабатываемая система является полностью распределенной и не требует выделенного сервера.

Для надежного распределения резервных копий по узлам одноранговой сети, необходимо ввести избыточную информацию, то есть сгенерировать дополнительные части резервной копии. Для решения этой задачи подходит алгоритм, используемый в RAID (Redundant Arrays of Inexpensive Disks) массивах [1]. Работа данного алгоритма основана на корректирующих кодах Рида-Соломона.

Рассмотрим алгоритм [4]. Перед нами стоит следующая задача: пусть имеется n частей резервной копии размером b байт каждая D ₁ ,D ₂. … ,D_n .

резервная копия может быть восстановлена.

Будем рассматривать каждую часть как последовательность слов.

Резервное копирование и восстановление баз данных

Возможность в любой момент восстановить базу данных из рабочей копии – существенная часть обеспечения непрерывности бизнеса. Целостность и возможность к восстановлению являются важной частью задач управления ИТ для Sarbanes-Oxley, представленных институтом IT Governance.

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

В этой статье рассматриваются вопросы, связанные с потерей данных, а также различные варианты резервирования баз данных. Также освещаются лучшие практики, которые могут помочь аудиторам в оценке эффективности резервного копирования баз данных. Особое внимание в этой статье уделяется технологиям и возможностям реляционных СУБД Oracle и Microsoft SQL Server, так как вместе они составляют примерно 40% от всех установленных баз данных. В таблице 1 приводится краткое сравнение этих СУБД.

Таблица 1. Сравнение Oracle RDBMS и MS SQL Server RDBMS

MS SQL Server RDBMS

В Oracle база данных при запуске обращается ко всем средам СУБД, включая структуру памяти, фоновые процессы, файлы базы данных, логи online redo, и некоторым другим файлам, включая файлы параметров сервера и файлы паролей.

SQL сервер при запуске выделяет пул памяти, использует фоновые процессы, и работает с несколькими базами данных, в том числе системными и пользовательскими. Мастер база MS SQL - это основная база данных системы, которая содержит системный каталог и информацию об остальных отдельных базах.

Любая база данных Oracle работает с одним централизованным системным каталогом или словарем данных, которые находятся в системном табличном пространстве.

В SQL сервере системный каталог, аналогичный словарю данных Oracle, разбит между отдельными базами данных, мастер базой и базами ресурсов (в более поздних версиях).

СУБД Oracle состоит из логических структур, называемых табличным пространством, которые, в свою очередь, состоят из физических файлов с данными. Табличное пространство/файлы данных форматируются во внутренние элементы, называемые блоками. СУБД состоит из цепочки связанных блоков разного размера.

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

Oracle для работы с базами данных предоставляет зарегистрированным пользователям логины, для которых прописан набор привилегий и операций, разрешенных в системе.

В SQL сервер логин позволяет пользователю подключаться к инстансу. Однако, доступ к базам данных внутри инстанса не автоматический и осуществляется посредством заведения отдельных акаунтов на доступ к конкретным базам данных. Привилегии внутри инстанса привязаны к логину, а привилегии внутри баз данных привязаны к конкретным пользователям.

Аутентификация – процесс проверки того, что логин введенный пользователем, принадлежит авторизованному пользователю. Oracle позволяет производить аутентификацию через операционную систему или через СУБД (сервер).

SQL также позволяет производить аутентификацию через операционную систему или через СУБД. В SQL сервере аутентификация через OS называется Windows Authentication, а через СУБД - SQL

Режим ведения логов

Логи online redo используются в Oracle для регистрации изменений в БД прежде чем применить эти изменения к БД. Oracle позволяет использовать функцию отмены чтобы возможно было вернуться к состоянию в прошлом, чтобы облегчить процесс отката транзакций.

В SQL сервере логи online redo называются логами транзакций. Они объединяют в себе функции Oracle redo логов и функции откатов. Каждая база данных SQL имеет один или несколько лог файлов.

Oracle осуществляет автоматическое восстановление каждый раз при загрузке. Он проверяет соответствие наполнения файлов данных файлам redo логов. В случае обнаружения расхождений, Oracle записывает содержимое redo логов в БД и удаляет все найденные несоответствия. Если Oracle не может найти необходимую информацию в redo логах, он обращается к их архивным версиям.

SQL также осуществляет автоматическое восстановление при каждом запуске, проверяя каждую базу данных. Сперва производится проверка мастер базы, а затем остальные базы в системе. Механизм автоматического восстановления проверяет соответствие каждой базы данных логам транзакций, и, в случае обнаружения расхождений, записывает их из логов в БД.

Резервное копирование и восстановление

В Oracle методы резервного копирования можно разделить на физические и логические. Два способа осуществления физического резервирования и восстановления Oracle: Recovery Manager (RMAN) и ручное под управлением пользователей. Oracle делит резервные копии по типу состояния на постоянные и изменяющиеся (холодные и горячие копии).

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

Логические резервные копии

Цель логического резервного копирования – иметь возможность восстановиться на уровне отдельных элементов схемы. В Oracle, логическое резервирование обычно осуществляется посредством утилит Export и Data Pump. Эти утилиты экспортируют объекты схемы в бинарный файл. Этот файл может быть открыт только утилитами Import и Data Pump, которые импортируют объекты схемы в базу данных.

В SQL сервере отдельные объекты схемы можно копировать в файлы любого поддерживаемого формата. Затем, эти файлы можно восстановить в базу данных, используя утилиты bulk copy program (bcp), Import and Export Wizard или службы интеграции SQL.

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

• Насколько администратор БД уверен в том, что критичная для бизнеса информация успешно резервируется и может быть восстановлена в течении времени, установленного сервисным контрактом (SLA) или прописанным в планах по восстановлению (RTO в DR-плане).
• Принял ли администратор меры по защите (а также восстановлению) СУБД от многочисленных типов сбоев?

Ниже приводится контрольный список для процедур резервного копирования и восстановления баз данных, описанных в этой статье:

1. Разработать комплексный план резервного копирования;
2. Эффективно управлять резервным копированием;
3. Периодически тестировать восстановление баз данных из резервных копий;
4. Согласовать периодичность резервного копирования и время восстановления со всеми заинтересованными лицами.
5. Разработать и задокументировать планы аварийного восстановления в части баз данных.
6. Поддерживать актуальность ваших знаний по восстановлению баз данных и операционных систем.

Администраторы ответственны за разработку комплексного плана резервного копирования баз данных, за которые они отвечают. Такой план должен распространятся на все типы СУБД в организации и освещать следующие области:

• Решить что нужно копировать. Необходимо чтобы администратор СУБД был в курсе того, какие базы данных, а также связанные с ними операционные системы и приложения необходимо копировать. Перечень того, что должно быть зарезервировано:
  • Операционные системы. В случае сбоев аппаратного обеспечения, необходимо будет производить полное восстановление системы, начиная с операционной системы. Поэтому, необходимо создавать резервную копию операционной системы сервера сразу после обновления или внесения изменений в конфигурацию системы.
  • СУБД. Необходимо также создавать резервную копию СУБД после всех изменений и обновлений.
  • Приложения. где это необходимо. В первую очередь, это касается Oracle E-Business Suite, Oracle Application Server и Oracle Enterprise Manager (OEM). Администратор должен создать полную резервную копию диска с установленными приложениями, а затем настроить инкрементное копирование при внесении изменений. Эти копии должны периодически переноситься на ленты.
  • Пароли. Все пароли superuser, которые могут понадобиться во время восстановления, должны храниться в надежном и доступном месте. Рекомендуется убедиться что пароль, который был предоставлен по умолчанию во время установки СУБД, был изменен.
  • Компоненты баз данный Oracle.
    • Файл параметров БД. В этом файле хранятся параметры инициализации базы данных, в том числе информация о файлах БД управления.
    • Файлы контроля БД. Эти файлы содержат информацию о физической структуры баз данных. Без них невозможна работы баз данных, поэтому, необходимо копировать их наряду с другими компонентами базы данных. В последних версиях Oracle (начиная с 9i) администратор может настроить автоматическое копирование файлов контроля БД и файла параметра БД после каждого обновления или изменения БД.
    • Файлы данных БД. Они могут быть скопированы как посредством холодного копирования, так и в режиме online при помощи Oracle’s Recovery Manager (RMAN), или, в версиях Oracle где такого функционала нет, установив для табличного пространства режим резервного копирования. Администратор БД должен пробовать запустить рабочие базы данных в режиме Archive log, чтобы убедиться в возможности восстановления БД на момент времени «до сбоя».
    • Redo лог файлы и архивные redo логи. Во время холодного резервирования, администратор должен копировать redo логи. В случае, если база даных работает в режиме Archive log, администратор должен сперва создать резервные копии redo логов в ручном или автоматическом режиме, а затем создать резервные копии архивных redo логов.
    • Сетевые файлы Oracle. Важно копировать все сетевые файлы Oracle в первую очередь после каждого изменения.
    • Файлы паролей. Файлы паролей также должны копироваться после каждого изменения.
  • СУБД MS SQL сервер.
    • Необходимо создавать резервные копии как системной, так и пользовательских БД.
    • Иметь отдельный план технического обслуживания системных БД, т.е. мастер, модель, MSDB. Мастер поддерживает только полные резервные копии, резервирование tempdb не требуется, так как она перестраивается при запуске SQL сервер.
    • Создавать резервные копии всех пользовательских БД. Настроить все пользовательские базы данных на работу в режиме полного восстановления, и копировать как БД, так и логи транзакций.
• Определить подходящий тип резервного копирования.
  • Oracle СУБД.
    • Логическое резервное копирование – этот тип резервного копирования, осуществляющийся посредством утилиты «exp». Начиная с версии Oracle 10g для этих целей также может использоваться Data Pump. БД целиком, отдельные схемы, таблицы или табличное пространство может быть зарезервировано. Восстановление осуществляется при использовании утилит «imp» или Data Pump. При таком типе резервирования, восстановление на момент времени «до сбоя» невозможно.
    • Физическое офлайн (или холодное) копирование – во время копирования всей необходимой информации и важных компонентов БД она должна быть выключена.
    • Физическое онлайн (или горячее) копирование – такой метод позволяет делать резервные копии баз данных без прекращения их работы. Однако, необходимо помнить следующие вещи при горячем копировании:

1. Либо установить для табличного пространства режим резервного копирования и затем скопировать необходимые данные используя команду копирования операционной системы, либо использовать средство RMAN (начиная с 8 версии Oracle). Oracle добавляет новый функционал к этому средству с каждой новой версией. RMAN может использовать контрольный файл БД для хранения своего каталога, или администратор может настроить схему для каждой базы данных в отдельной БД для каталогов RMAN.
2. Администратор должен держать в голове и регулярно пересматривать матрицу совместимости для резервируемой/восстанавливаемой БД. Также, под рукой должны быть исполняемые файлы и БД/схема каталога RMAN.
3. Администратор должен ознакомиться с полным, инкрементным и дифференциальным резервным копированием и настроить их используя RMAN скрипт. Администратор должен следить за версией RMAN, так как, например, в стандартных версиях до Oracle 10g, инкрементное резервное копирование было недоступно. Для того чтобы восстановить базу данных на момент «до сбоя», или на другой определенный момент времени, администратор должен переключить базу данных в режим Archive log и скопировать все архивные redo логи.
4. Важно не забывать копировать каталог RMAN после каждого резервного копирования.

• SQL сервер СУБД.
  • Логические резервные копии. В SQL сервере отдельные объекты схемы можно копировать в файлы любого поддерживаемого формата. Затем, эти файлы можно восстановить в базу данных, используя утилиты bulk copy program (bcp), Import and Export Wizard или службы интеграции SQL.
  • Физические резервные копии. Рекомендуется, чтобы для всех пользовательских баз данных было настроено полное копирование. Также, должны копироваться логи БД и транзакций для обеспечения восстановления на момент времени «до сбоя». Администраторы должны досконально разбираться в моделях резервирования и настраивать их в соответствии с требованиями. Резервирование отдельных файлов или групп файлов может быть использовано в случае когда надо создать резервную копию БД большого размера (Very Large Data Base - VLDB), распределенную между несколькими местами хранения.

Разработка стратегии для резервного копирования VLDB. Администратор Oracle может сократить время резервного копирования VLDB путем выделения нескольких каналов копирования, и тонкой настройки резервирования. Объем требуемого места на диске может быть сокращен при использовании сжатых резервных копий. Также, может быть заблокирован трекинг при использовании технологий инкрементного копирования (в поздних версиях). В случае, если эта функция недоступна, рекомендуется использовать метод split mirror. Администратор SQL сервера может разделить одну базу данных на много файлов и разрабатывать стратегию резервирования файловых групп. Также, при использовании нескольких устройств резервного копирования, SQL сервер позволяет записывать на них данные параллельно.

• Установка приемлемого окна и расписания резервного копирования. Хорошая практика – выбрать для времени проведения (окна) резервного копирования время, кода нагрузка на базу со стороны пользователей минимальна. Администратор может оптимизировать время резервного копирования, указав несколько путей для резервирования (необходимо уточнить, доступна ли эта функция в текущей версии и издании программы). В большинстве случаев оптимальное расписание резервного копирования – создание полной копии раз в неделю в ночь с пятницы на субботу, а инкрементных/выборочных копий в течение недели. Архивные/транзакционные логи должны копироваться раз в несколько часов в зависимости от критичности данных.
• Принятие решения о месте хранения резервных копий. И Oracle и MS SQL могут писать свои резервные копии напрямую на ленту или диск (локально или по сети), а затем эти копии могут быть записаны на ленточный архив. Хорошей практикой считается записывать резервные копии на диск, дублировать их на ленты и хранить эти копии в разных зданиях для большей гарантии восстановления в случае чрезвычайной ситуации. Резервное копирование на диски происходит быстрее, у администраторов есть больше возможностей контроля и мониторинга. Восстановление информации с диска также происходит быстрее, что позволяет в результате снизить общее время восстановления системы.
• Разработка политики хранения резервных копий. Эта политика относится в равной степени к расписанию времени хранения копий на дисках и на лентах. Политика разрабатывается с учетом требований бизнеса и пользователей. Владелец информации должен определить время хранения данных. Этот период может колебаться от нескольких месяцев до нескольких лет, и зависит во многом от местных законов. Соответственно, администратор должен своевременно удалять старые резервные копии, чтобы освободить место для новых. Политика хранения резервных копий должна быть тщательным образом разработана и учитывает аппаратные возможности системы хранения и требования стратегии резервного копирования и восстановления. Если не используется каталог, администратор должен убедиться, что время хранения, прописанное в файле управления, совпадает с требованием политики хранения резервных копий.

После разработки плана резервного копирования и завершения первоначальных работ, администратор должен управлять резервным копированием, принимая во внимание следующее:

• Автоматизация резервного копирования. В случае с Oracle, можно либо настроить копирование через OEM, либо использовать планировщик задач операционной системы. Лог файл процесса нужно просматривать на предмет возможных ошибок. В случае SQL сервер лучше использовать планы обслуживания БД (Maintenance Plans) для управления расписанием резервного копирования.
• Мониторинг резервного копирования. Нужно настроить мониторинг, используя специализированные утилиты, позволяющие администратору получать на телефон или e-mail сообщения об ошибках резервного копирования, которые должны быть как можно быстрее устранены.
• Логи и каталоги резервного копирования. Нужно регулярно просматривать логи резервного копирования и информацию, содержащуюся в каталогах резервного копирования. Можно использовать отчеты RMAN для просмотра статуса резервного копирования. В случае Oracle, необходимо на регулярной основе делать копии каталога RMAN, не забывая делать их копии после каждого резервного копирования БД. Для SQL сервера нужно копировать системные базы данных, в первую очередь master и msdb.
• Обслуживание каталога базы данных. В случае с Oracle следует использовать функцию «удалить устаревшие» (delete obsolete) чтобы удалить резервные копии, которые не требуется хранить согласно политике хранения резервных копий. Если устаревшие базы данных не удалять, то каталог продолжит расти и рано или поздно мы столкнемся с проблемами с производительностью. Перекрестное тестирование (cross-check backup) позволяет проверить соответствие файла управления/каталога физическим резервным копиям.
• Проверка резервного копирования. Необходимо проверять резервные копии, не производя фактического восстановления.
• Настройка зависимостей. При создании резервной копи на диске, необходимо сразу по завершении резервирования скопировать их на ленту. Необходимо настроить этот процесс таким образом, чтобы задержка по времени между этими двумя мероприятиями была минимальная.

Представьте следующий сценарий: наводнение накрыло район, где расположен головной офис компании, и вся ИТ инфраструктура была повреждена, но не утрачена целиком. Непосредственно перед наводнением, администратор произвел резервное копирование информации согласно требованиям всех пунктов, указанных выше в этой статье, а хранил эти копии вне здания головного офиса. Во время последнего аудита, аудитор оценил процедуру резервного копирования как «эффективную». Носитель с резервной копией привезен из другого здания и загружен. Однако, при попытке восстановления, появляется ошибка чтения данных из-за нарушения их целостности.

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

1. Тестирование восстановления. Должно быть прописано требование к тестированию возможности восстановления с дисков и с лент.
2. Проверка восстановления, где возможно. Администратор может проверить резервные копии не выполняя процедуру восстановления. Команда «проверка восстановления БД» (restore validate database) выполнит все действия, кроме самого восстановления. Это лучший метод определения работоспособности резервных копий, до того как ситуация не стала критической.
3. Развертывание тестовых баз из резервных копий продуктивных баз. Это хорошая практика – периодически производить восстановление БД в непродуктивной среде из резервных копий продуктивных баз данных.
4. Выполнение тестирования восстановления баз данных из резервной копии раз в 1-2 года в рамках проведения аудита. Администратор должен рассказать процесс восстановления, а также показать логи и скриншоты процедуры восстановления.
5. Фактические восстановления. Во время фактических восстановлений, администратор должен создать резервную копию БД перед процедурой восстановления. В зависимости от типа потери данных и наличия актуальной резервной копии, администратор принимает решение о полном восстановлении с частичной потерей данных, либо о частичном восстановлении.
6. Стратегия восстановления поврежденной базы данных. В случае с Oracle, администратор может запустить проверку блоков с определенными параметрами для обнаружения поврежденных блоков в БД. Это ведет к снижению производительности, однако позволяет заранее выявить повреждения блоков, вызванные проблемами с диском, с системой хранения или проблемами ввода-вывода (I/O). По умолчанию, RMAN выполняет проверку на поврежденные блоки во время резервного копирования. В поздних версиях Oracle, RMAN может использоваться также для восстановления поврежденных блоков в БД.

Группа администраторов СУБД должна подготовить документ об уровне обслуживания, детализирующий процедуру резервного копирования, включающий требования ко времени восстановления, и подписать его у руководства. Этот документ никак не поможет при восстановлении БД, но определяет ожидания пользователей и руководства от процесса восстановления, что может обеспечить администраторам БД больше времени на восстановление.

Администратор должен убедиться, что базы данных включены в общий DR план компании в качестве ключевого элемента. Все заинтересованные лица должны понимать все разделы DR плана и последовательность восстановления баз данных группой восстановления. Бизнес должен предоставить эти данные для того, чтобы бизнес-критичные приложения заработали в первую очередь.

Это кажется очевидным, но администраторы играют ключевую роль в этом процессе, поэтому они постоянно должны поддерживать актуальность своих знаний о резервном копировании и восстановлении СУБД на должном уровне. Во время реального восстановления, у администратора не будет времени, чтобы ознакомиться со всеми новыми функциями и преимуществами средств восстановления.

Первоочередная задача группы администраторов БД – изучить все типы СУБД в компании и разработать исчерпывающий план резервного копирования для осуществления эффективного управления резервным копированием посредством активного мониторинга состояния резервных копий, получения своевременных оповещений об ошибках в процессе резервного копирования, позволяющих перезапустить процесс без потери времени. Хорошей практикой, с точки зрения аварийного восстановления, является копирование данных на диск, с последующим переносом их на ленту для архивного хранения.

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

Александр Шабалин alexander.shabalin@4by4.ru. Ведущий консультант 4х4, аудитор СТО БР ИББС. По материалам www.isaca.org

Специалисты компании 4x4 имеют богатый опыт по планированию обеспечения непрерывности бизнеса и разработке планов аварийного восстановления ИТ инфраструктуры. Наши сотрудники помогут вашим администраторам БД, усилив их контроль над процессом резервного копирования и восстановления данных. Совместная работа консультантов и администраторов может дать дополнительные гарантии того, что в случае аварии, информация, критичная для бизнеса, будет восстановлена.