Подожди подожди.
Я не написал в заголовке «Как обойтись без бекапа».
Без резервного копирования обойтись невозможно, это знает любой первокурсник.
Но навсегда забыть о резервных копиях — это, пожалуй, мечта любого ИТ-менеджера.
Но эта мечта все еще казалась нереальной.
Потому что даже если в вашей компании отличный бэкап, вы вспомните об этом сразу после большого провала, а не добрым словом.
Вы не скажете что-то вроде: «Как здорово, что у нас каждую ночь выполняется резервное копирование», а скорее: «Сколько часов прошло с момента резервного копированияЭ» Давайте посмотрим, каковы ключевые цели резервного копирования баз данных и почему ни одно из существующих на сегодняшний день решений не удовлетворяет этим целям.
Компании требуют, чтобы системы никогда не теряли критически важные для бизнеса данные и чтобы резервные копии не влияли на работу бизнес-приложений.
Соответственно, решения должны гарантировать восстановление баз данных после сбоев.
Но резервное копирование базы данных требует особого подхода; недостаточно рассматривать базу данных как набор файлов.
И в этом проблема традиционных решений резервного копирования баз данных — они не отвечают потребностям защиты критически важных данных, поскольку рассматривают базу данных как набор файлов, которые необходимо скопировать, а не как транзакционную систему с особыми требованиями к целостности данных, производительности.
и доступность.
Простого копирования файлов базы данных недостаточно, поскольку оно не гарантирует целостности базы данных.
После восстановления из такой копии база данных может просто не открыться пользователям.
Кроме того, традиционный подход не позволяет выполнять резервное копирование данных в реальном времени, чтобы это не влияло на производительность системы.
Необходимо найти временные «окна» для резервного копирования — неважно, что в странах, живущих в одном или двух часовых поясах, но это, сами понимаете, не про нас.
При этом не только объем баз данных растет, как на стероидах, но и количество баз данных бесконтрольно множится.
И как, спросите вы, можно создать единую политику резервирования с таким количеством систем? А масштабирование самой системы бронирования в таких условиях становится адом.
Итак, мы разобрались, «кто виноват».
У нас есть три основные проблемы – риск потери данных при резервном копировании баз данных в виде файлов, снижение производительности информационной системы предприятия из-за резервного копирования и сложность создания централизованной службы резервного копирования из-за большого количества корпоративные базы данных.
Перейдем к вопросу «что делать».
Oracle решил эту проблему просто и естественно.
Во-первых, чтобы не потерять данные и минимизировать влияние на производительность, нужно рассматривать ее как транзакционную систему, а не файловую систему, и делать резервные копии журналов транзакций.
Во-вторых, для обеспечения масштабируемости услугу резервного копирования должен обеспечивать аппаратно-программный комплекс – устройство.
Получившееся решение, обеспечивающее резервное копирование без потери данных, называется Oracle Zero Data Loss Recovery Appliance. Recovery Appliance защищает все базы данных Oracle в вашем центре обработки данных, поддерживая все редакции и все версии Oracle Database от 10.2 до 12.2 на любых платформах.
Чтобы обеспечить надежное восстановление базы данных, Recovery Appliance постоянно проверяет целостность данных.
Сжатие данных также выполняется с помощью Recovery Appliance, а резервное копирование на ленту, если оно практикуется в вашей организации, также будет выполняться с помощью Recovery Appliance, освобождая ваши промышленные серверы для основной работы.
Все, что вам нужно для подключения сервера базы данных к Recovery Appliance, — это установить на него утилиту резервного копирования и восстановления данных под названием Recovery Manager (RMAN).
Никакое дополнительное программное обеспечение, отвечающее за резервное копирование данных, на стороне сервера работать не будет. Recovery Appliance также хранит Каталог восстановления — это информация обо всех выполненных резервных копиях; он необходим для процедур инкрементного резервного копирования и восстановления данных.
После завершения полного резервного копирования процесс DeltaPush передает на Recovery Appliance только изменения базы данных, что означает минимальное влияние на производительность рабочего сервера (рис.
1).
Между инкрементами создаются резервные копии журналов транзакций.
Ясно? Recovery Appliance всегда хранит самые последние версии баз данных, минимизируя при этом объем информации, передаваемой из базы данных в систему резервного копирования.
Все проверенные и сжатые изменения базы данных хранятся на Recovery Appliance в специальном хранилище под названием Delta Store. Использование Delta Store Recovery Appliance позволяет быстро воссоздать полную копию базы данных в любой момент времени, быстро суммируя все изменения.
Все это управляется через Enterprise Manager. 
Кроме того, Recovery Appliance может автономно, асинхронно копировать данные на ленту и в резервный центр обработки данных.
Нет необходимости загружать рабочие серверы баз данных; данные копируются из Recovery Appliance (рис.
2).
Вы можете восстановить базу данных RMAN либо с Recovery Appliance в основном или резервном центре обработки данных, либо непосредственно из ленточной библиотеки.
Архитектура, обеспечивающая беспрецедентно высокую скорость резервного копирования, называется Delta-Only. RMAN никогда не создает резервные копии повторяющихся блоков, блоков «Отменить» для завершенных транзакций или неиспользуемых блоков.
В Delta Store хранятся только изменения, реплицируются только изменения, а данные сжимаются на уровне блоков.
Мой любимый новый термин, появившийся благодаря Recovery Appliance, — «виртуальная полная копия базы данных».
Если вы внимательно прочитали начало статьи, то уже все о ней поняли — сначала полная резервная копия создается только один раз, а затем, благодаря инкрементным копиям, Recovery Appliance может воссоздать «виртуальную полную копию базы данных» на муха.
При этом за счет сохранения журналов транзакций из базы данных непосредственно в режиме реального времени обеспечивается нулевая потеря данных (рис.
3).
И это не то же самое, что сумма полной копии со всеми инкрементными, накопительными и дифференциальными при использовании традиционных систем.
Полная виртуальная копия объединяет блоки полной резервной копии с инкрементными копиями, т.е.
просто содержит ссылки на нужные версии блоков.
В результате это эквивалентно полному резервному копированию.
Экономия дискового пространства и времени - вы сами понимаете, в чем они заключаются.
Полная виртуальная копия и журнал транзакций из последней инкрементной резервной копии составляют необходимый и достаточный набор для быстрого восстановления базы данных в любой момент времени.
Вам больше никогда не придется делать полное резервное копирование, в этом просто нет смысла.
Сам процесс восстановления файловой базы называется «восстановлением», а процедура отражения в нем последних изменений из журнала транзакций — «восстановлением».
А поскольку журналы транзакций накапливаются между каждым сеансом инкрементного копирования, вы можете быстро восстановить базу данных на любой момент времени в прошлом.
И для этого не нужно, как раньше, объединять полные и инкрементные копии с помощью рабочих серверов — виртуальный бэкап содержит ссылки на все блоки, необходимые блоки просто извлекаются из Delta Store. Recovery Appliance настроен по всем правилам хорошего тона, с использованием политик.
Политики определяют, сколько дней резервные копии должны храниться на диске, сколько дней на ленте и сколько дней в резервном центре обработки данных.
Политик может быть несколько — например, для некритических, критических и наиболее критичных баз данных.
Набор политик стандартизирует все регламенты резервного копирования на предприятии (рис.
4).
Благодаря этому управлять регламентом резервного копирования становится очень просто — например, если вдруг окажется, что резервные копии финансовых данных нужно хранить не месяц, а год, вы просто присваиваете соответствующей политике значение 365 дней.
вместо 30 - и все базы данных, которые управляются этой политикой, будут иметь новый регламент резервного копирования, что очень удобно.
Recovery Appliance будет вести статистику загрузки дисковой подсистемы и прогнозировать, как долго она продлится.
Политики резервного копирования также определяют, какие данные должны быть реплицированы в резервном центре обработки данных, а для организаций, имеющих несколько центров обработки данных, каждый из которых содержит активные базы данных, реплики могут быть двунаправленными (рис.
5).
Для организаций с разветвленной структурой настраивается схема консолидации – Recovery Appliance в каждом филиале отправляет данные на Recovery Appliance в главном дата-центре (рис.
6).
При этом базу данных можно восстановить как с основного, так и с резервного Recovery Appliance — это может потребоваться в случае выхода из строя одного из локальных дата-центров.
Очень важно, чтобы процесс резервного копирования Recovery Appliance, все базы данных, все реплики и копии на ленту управлялись через единый интерфейс Enterprise Manager. Все копии регистрируются в Каталоге восстановления, и администратор базы данных видит все способы восстановления базы данных.
Базовая конфигурация устройства восстановления с нулевой потерей данных называется Base Rack и состоит из двух серверов, выполняющих резервное копирование (каждый с пятью портами Ethernet 10 Гбит/с, двумя портами InfiniBand 40 Гбит/с и опционально двумя портами Fibre Channel 16 Гбит/с для подключения ленточной библиотеки), и тремя хранилищами данных.
серверы, на которых хранятся резервные копии (каждый по двенадцать дисков по 4 ТБ со скоростью вращения 7200 об/мин).
Объем дискового хранилища с учетом зеркального блочного резервирования составляет 42 ТБ.
Вы можете расширить дисковое хранилище до 18 серверов хранения, эта версия называется Full Rack или по-русски полный серверный шкаф, емкость хранилища которого составляет 320 ТБ, а скорость резервного копирования 12 ТБ/час.
Этого достаточно, я считаю, для резервного копирования любой базы данных, а для резервного копирования большого количества баз данных внутри дата-центра этот аппаратный комплекс можно масштабировать до Full Rack, а то и до 18 Full Rack 18 таких шкафов с скорость резервного копирования 216 ТБ/час.
Система работает под управлением программного обеспечения Zero Data Loss Recovery Appliance, которое лицензируется для каждого диска сервера хранения.
Все остальное программное обеспечение, включая Oracle Secure Backup, Oracle Database, Oracle Partitioning и т. д. — в отличие, скажем, от решения с использованием Oracle Data Guard — вы получаете Recovery Appliance внутри бесплатно.
Очень рекомендую ознакомиться с материалами по ссылкам www.oracle.com/recoveryappliance , www.oracle.com/goto/ha И www.oracle.com/goto/maa .
И обязательно записывайтесь на наши онлайн-тренинги.
Теги: #oracle #recovery #копирование #Backup #oracle
-
Этрусский Язык
19 Oct, 24 -
Как Работает Робот Atlas От Boston Dynamics?
19 Oct, 24 -
Земля Растет
19 Oct, 24
