Pull to refresh

Инкрементально обновляемый бэкап как стратегия резервного копирования СУБД

Reading time 4 min
Views 9.5K
На сегодняшний день существует множество вариантов резервного копирования СУБД Oracle, которые позволяют администраторам спать спокойно по ночам и не переживать о том, что могло бы случиться, и как можно было бы этого избежать. Также в помощь – множество программного обеспечения, позволяющего упростить ежедневные рутинные задачи.
Использование Recovery Manager (RMAN), согласно официальной документации, является рекомендованным и одним из наиболее оптимальных способов для резервного копирования и восстановления базы данных Oracle. А возможность выполнять «горячие» бэкапы, оставляя базу доступной для чтений и изменений, делает эту утилиту мощным инструментом для резервирования высокодоступных систем.

В статье я не буду говорить обо всех возможностях Recovery manager, а опишу одну из интересных стратегий резервного копирования, позволяющую по-новому взглянуть на построение системы отказоустойчивости на предприятии. Технология инкрементально обновляемого бэкапа появилась в 10-й версии Oracle. Она предоставляет те же возможности по восстановлению, что и копирование образа базы (image copy), но более быстрая и оказывает меньшую нагрузку на ресурсы системы. Также эта опция сокращает время восстановления за счет меньшего количества журналов, которые необходимо применить для актуализации данных.

Концепция


Суть сохранения данных при помощи Recovery manager в том, что мы один раз делаем полную копию базы, а затем только копируем изменения, при этом – каждый раз при выполнении инкрементального бэкапа предыдущий накатывается на образ базы, актуализируя данные. В результате наш бэкап на физическом уровне состоит всегда из копии данных и файла изменения.



Рассмотрим пример выполнения:

RUN
{
RECOVER COPY OF DATABASE
WITH TAG 'incremental';
BACKUP
INCREMENTAL LEVEL 1
FOR RECOVER OF COPY WITH TAG 'incremental'
DATABASE;
}


Эту команду мы можем поставить в расписание на ежедневное выполнение. Вот как она будет интерпретироваться:

День 0
  • RECOVER – так как нет ни инкрементального бэкапа, ни полноценной копии, команда не дает никакого эффекта.
  • BACKUP – так как нет копии данных (0 уровень), то команда создает ее с указанным тэгом. Данный уровень необходим для создания цикла.

День 1
  • RECOVER – на этот раз копии базы есть, но инкрементального бэкапа первого уровня, который можно было бы применить, нет. Команда не дает эффекта.
  • BACKUP – команда создает инкрементальный бэкап первого уровня и присваивает ему необходимый тэг. В нем содержатся изменения, сделанные с 0 дня по 1.

День 2 и последующие
  • RECOVER – инкрементальный бэкап первого уровня, сделанный в предыдущий день, применяется к копии базы, накатывая вперед зафиксированные изменения.
  • BACKUP – команда создает инкрементальный бэкап первого уровня и присваивает ему необходимый тэг. В нем содержатся изменения, сделанные с 1 дня по 2-й.

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

Рассмотрим пример команды восстановления с окном в 7 дней:

RUN
{
RECOVER COPY OF DATABASE
WITH TAG 'incremental'
UNTIL TIME 'SYSDATE — 7';
BACKUP
INCREMENTAL LEVEL 1
FOR RECOVER OF COPY WITH TAG 'incremental'
DATABASE;
}


Оптимизация


Вместе с инкрементально обновляемым бэкапом мы можем использовать еще одну технологию – BLOCK CHANGE TRACKING. При выполнении резервного копирования recovery manager исследует каждый блок данных, отслеживая изменения. Время выполнения такой процедуры прямо пропорционально размеру файлов данных. Она может быть достаточно длительной, даже если было изменено всего лишь несколько блоков. Начиная с 10-й версии в Oracle была представлена новая технология — BLOCK CHANGE TRACKING мы можем создать специальный файл, который записывает модифицированные блоки с момента предыдущего бэкапа. Затем RMAN использует его, чтобы определить изменения. Уже не нужно полностью изучать все доступные данные. Таким образом, скорость выполнения инкрементальной копии прямо пропорциональна измененным блокам. Благодаря реализации такого функционала можно существенно уменьшить время выполнения резервирования.



  • Стоит отметить, что размер change tracking файла очень мал и совершенно не нуждается в администрировании (пропорция к общему размеру всех файлов данных примерно 1/30,000).
  • По умолчанию файл располагается в зоне FRA, но также может быть размещен в любом месте, которое обозначают при включении данного функционала.
  • RMAN не резервирует change tracking файл, поэтому в случае его повреждения или случайного удаления можно просто создать новый (соответственно, первичное занесение измененных данных будет выполнено заново).

Быстрое восстановление


Используя приведенную стратегию для резервирования СУБД, мы можем быстро восстановить отдельные поврежденные файлы:
  • если база открыта – поместить файл в offline-режим;
  • выполнить команду: switch datafile ‘datafile_name’ to copy;
  • выполнить команду recover для применения текущих журналов;
  • поместить файл в online режим.

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

SWITCH DATABASE TO COPY;
RECOVER DATABASE;


Заключение


Стратегия резервного копирования, представленная в статье, является весьма эффективным способом защиты СУБД от потери данных. Технология фиксации уже измененных блоков в паре с инкрементальным бэкапом позволяет значительно ускорить ежедневную процедуру «горячего» резервного копирования. А возможность быстро переключать поврежденный файл на свежую копию делает ее отличным подспорьем в системах, критичных к времени восстановления. Также стоит отметить простоту разворачивания клона базы, например, для среды разработки, ведь наш бэкап является полноценной копией, не требующей отдельных манипуляций с файлами.
Автор – Олег Константинов.
Tags:
Hubs:
+3
Comments 3
Comments Comments 3

Articles