Настройка резервного копирования СУБД Oracle

Резервное копирование БД рекомендуется выполнять следующими способами:

Способ 1. Экспорт схемы PLATEX

Данный способ рекомендуется для выполнения копирования с целью долговременного (архивного) хранения.

Достоинства:

•Самодостаточная копия (для восстановления схемы из нее не требуется соблюдения каких-либо условий или наличия дополнительных файлов);

•Минимальный размер полной копии данных;

•Возможность восстановления в любую базу и схему;

•Файл экспорта может использоваться для частичного восстановления (только необходимых таблиц);

•Это логическое копирование - его успешное завершение гарантирует возможность восстановления данных из созданного файла.

Недостатки:

•Не гарантирует консистентного снимка данных на момент копирования;

•Не поддерживает инкрементального копирования/восстановления;

•Не содержит информацию о паролях пользователей системы (сотрудников оператора связи) - их потребуется при восстановлении пересоздать;

•Это не блочное копирование, следовательно, выполняется дольше копирования на уровне файлов.

Основа способа:

[oracle] export NLS_LANG=AMERICAN_AMERICA.UTF8
[oracle] exp /@PLATEX file=/path/to/backups/export_18.01.2022.dmp owner=PLATEX

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

Пример из практики:

В папку /usr/local/PLATEX/backup смонтирован раздел с сетевого накопителя для резервных копий

Настроено задание в crontab от пользователя oracle, сохраняющее данные системы в 0:03 каждый понедельник, среду, пятницу.

3 0 * * 1,3,5 . /etc/profile.d/platex.sh; find /usr/local/PLATEX/backup/oracle/ -type f -name "PLATEX_DB_*exp.bz2" -mtime +62 -delete; export NLS_LANG=AMERICAN_AMERICA.UTF8; exp platex/goodpassword@PLATEX FILE=/usr/local/PLATEX/oracle/PLATEX_DB_$(date +\%Y\%m\%d).exp OWNER=PLATEX; /usr/local/PLATEX/scripts/pbzip2 -p6 /usr/local/PLATEX/oracle/PLATEX_DB_$(date +\%Y\%m\%d).exp; mv /usr/local/PLATEX/oracle/PLATEX_DB_$(date +\%Y\%m\%d).exp.bz2 /usr/local/PLATEX/backup/oracle/

В данном примере можно увидеть:

•Подключение настроек окружения системы для подключения к базе данных из /etc/profile.d/platex.sh;

•Удаление резервных копий, созданных более 2х месяцев назад;

•Выставление значения переменной NLS_LANG и запуск экспорта в папку /usr/local/PLATEX/oracle;

•Сжатие файла многопоточным архиватором с использованием 6ти потоков (6ти процессорных ядер);

•Перемещение архива на сетевой накопитель.

Способ 2. Копирование файлов базы

Файлы БД можно скопировать как в холодном, так и в горячем режиме. Поскольку в документации речь идет о вопросах эксплуатации, холодный режим копирования рассматриваться не будет (т.к.  регулярный простой БД с целью резервирования недопустим).

Данный способ копирования рекомендуется:

•при отсутствии возможности обеспечить постоянно смонтированную, надежную файловую систему с резервного накопителя, необходимую для Способа 3;

•при выполнении регламентных работ для создания архивной копии долговременного хранения.

Достоинства:

•Гарантирует консистентное состояние данных после восстановления;

•Выполняется для отдельных табличных пространств (можно разделить процесс резервирования по времени или не копировать определенные пространства);

•Полностью контролируемый пошаговый процесс, размещение каждого файла можно определить отдельно (полезно при запуске из скриптов);

•На 100% прогнозируемый необходимый объем резервного накопителя для создания копии;

•Копия может использоваться для частичного восстановления (только необходимых табличных пространств);

•Это блочное копирование - выполняется быстрее чем экспорт, скорость напрямую зависит от скорости копирования файлов, но консистентность будет обеспечена, даже если копирование займет продолжительное время.

Недостатки:

•Не поддерживает инкрементального копирования/восстановления;

•Не позволяет восстанавливать отдельные таблицы, и производить восстановление в "чужую" базу;

•Не позволяет "из коробки" осуществлять контроль восстановимости резервной копии;

•Много ручных действий связано как с процессом копирования, так и при восстановлении;

•Это не логическое копирование - его успешное завершение не гарантирует возможность восстановления в случае, если файлы данных были уже повреждены на момент копирования.

Основа способа:

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

1 (sys) alter tablespace SYSTEM begin backup;
2 [oracle] cp /oradata/PLATEX/system01.dbf /mnt/backup/PLATEX/BeforeRDBMSUpgrade/
3 (sys) alter tablespace SYSTEM end backup;
4
5 (sys) alter tablespace CORE begin backup;
6 (sys) !cp /oradata/PLATEX5/CORE01.dbf /oradata/PLATEX/CORE02.dbf /mnt/backup/PLATEX/BeforeRDBMSUpgrade/;
7 (sys) alter tablespace CORE end backup;
8
9 ...
10
11 (sys) alter system switch logfile;
12 (sys) alter database backup controlfile to '/mnt/backup/PLATEX/BeforeRDBMSUpgrade/controlfile.bkp';
13 (sys) create pfile='/mnt/backup/PLATEX/BeforeRDBMSUpgrade/initPLATEX.ora' from spfile;
14 (sys) !cp /oracle_home/network/admin/*.ora /mnt/backup/PLATEX/BeforeRDBMSUpgrade/;

 
Здесь можно увидеть в строках 1-3 и 5-7 однотипные блоки команд для перевода пространства в режим BACKUP, копирования файлов (двумя способами), снятия статуса BACKUP с табличного пространства. Если необходимо скопировать больше табличных пространств или всю базу - необходимо создать такие блоки по каждому табличному пространству. Табличное пространство TEMP не резервируется, потому при попытке его перевода в BACKUP будет выдана ошибка о том, что это состояние для временных пространств не поддерживается (и не требуется т.к. пространство TEMP очищается при каждом перезапуске базы).

В строке 11 переключается redo-лог для принудительного обновления информации в control-файле перед тем, как строкой 12 будет создана его копия. В строке 13 и 14 создается копия настроек базы для упрощения ее восстановления.

Следует помнить, что для восстановления любой созданной в горячем режиме копии файлов базы данных необходимо иметь, как минимум, несколько первых архивлогов (копии журналов redo) созданных от момента начала резервного копирования до архивного лога полученного перед копированием control-файла. В штатном режиме эксплуатации хранятся также ВСЕ архивлоги от момента начала последнего резервного копирования, если на копию, созданную данным методом возложены надежды восстановления базы в случае сбоя.

На практике для резервного копирования данным способом часто используются скрипты, входящие в комплект поставки АСР, автоматизирующие часть работы администратора (hot_backup.sql, backup.sh, end_backup.sh в каталоге /usr/local/PLATEX/scripts).

Способ 3. Резервирование "окна" средствами RMAN

Данный способ рекомендуется для регулярного резервного копирования при наличии необходимого места на хранилище.

RMAN (Recovery Manager) - мощное средство для организации резервного копирования любого масштаба и сложности с использованием простых интуитивных команд. Ключевое отличие данного подхода заключается в том, что он использует "каталог". Каталог RMAN - это база данных, в которой хранится информация о состоянии БД, архивных журналах транзакций, резервных копиях базы, файлов настроек инстансов и копиях control-файлов. Она может быть размещена в отдельном инстансе и использоваться несколькими базами данных централизованно, а также располагаться в control-файле базы данных.

В рамках темы резервного копирования RMAN также позволяет выполнять проверку логической целостности резервной копии (фиктивное тестовое восстановление), создавать избыточные резервные копии, инкрементальные, зеркальные копии на разных носителях за один проход (параллельное копирование), делать резервные копии архивных журналов redo, проверять доступность перечисленных в каталоге копий, удалять устаревшие (по различным причинам) копии и множество других полезных действий.

"Окно" в резервном копировании - это ограниченная явным периодом возможность восстановления базы данных или отдельных ее файлов на любой момент времени. Началом этого периода всегда является резервная копия (базы данных или файла), обеспечение возможности восстановления на любой момент (продолжительность периода) определяется наличием непрерывной последовательности архивных журналов redo до необходимого момента. Это позволяет поддерживать "окно" не только для восстановления регулярной резервной копии, но и хранить подобное окно за требуемый период в архивных целях. При регулярном резервном копировании финальной точкой этого "окна" является текущее состояние базы данных, т.е. восстановление без потерь.

Например, имеются резервные копии архивных журналов redo с 1 января 2022 года, копия базы данных от 5 января 2022 года, текущий момент предполагается 12 января 2022:

Восстановление базы данных на 1 января - недоступно, т.к. нет копии, от которой возможность восстановления ("окно") начинается.
Восстановление базы данных на 5 января - доступно (от момента создания копии).
Восстановление базы данных на 6 января на время 12:34:40 - доступно (например, на случай если сотрудник совершил фатальные для бизнеса действия в базе в 12:34:41).
Восстановление базы данных на 12 января - доступно.
Восстановление базы данных на момент сбоя - доступно (в т.ч. без потерь).

Описанное выше можно автоматически отнести к достоинствам третьего способа.

Недостатки:

•Не позволяет восстанавливать отдельные таблицы, и производить восстановление в "чужую" базу.

•Это не логическое копирование - его успешное завершение не гарантирует возможность восстановления если  файлы данных были уже повреждены на момент копирования.

Основа способа:

(sys) alter system set db_recovery_file_dest_size=500G scope=both;
(rman) backup database;

В первой строке определяется максимальный размер пространства, которое могут занимать резервные копии. Вторая строка запускает сам процесс резервного копирования.

Далее можно настроить свою политику копирования, применяя богатые возможности RMAN или использовать предоставляемую производителем:

Типовая политика копирования обеспечивает избыточность резервной копии и окно восстановления в 3 недели.
Она состоит из заданий в планировщике crontab для пользователя oracle и нескольких простых скриптов /usr/local/PLATEX/scripts/rman_*.cmd.

Предварительная разовая настройка RMAN (включение сжатия файлов и оптимизированного режима):

(rman) CONFIGURE BACKUP OPTIMIZATION ON;
(rman) CONFIGURE CONTROLFILE AUTOBACKUP OFF;
(rman) CONFIGURE DEVICE TYPE DISK PARALLELISM 2 BACKUP TYPE TO COMPRESSED BACKUPSET;
(rman) CONFIGURE MAXSETSIZE TO 32G;
(rman) CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP 1 TIMES TO DISK;

Планировщик для пользователя oracle:

## Oracle backup
# Clean old
10 7 * * * /usr/local/PLATEX/scripts/rman_clean.sh >>/var/log/platex/rman_backup.log 2>&1
# Weekly - create full backup (0 incr)
30 3 * * 1 /usr/local/PLATEX/scripts/rman_backup_weekly.sh >>/var/log/platex/rman_backup.log 2>&1
# Daily on Tue-Sun - create incremental backup (1 incr)
30 3 * * 2-7 /usr/local/PLATEX/scripts/rman_backup_daily.sh >>/var/log/platex/rman_backup.log 2>&1
# Backup archivelog
40 13 * * * /usr/local/PLATEX/scripts/rman_backup_arch.sh >>/var/log/platex/rman_backup.log 2>&1
## End Oracle backup

Файл rman_clean.sh:

#!/bin/bash
. /etc/profile.d/oracle.sh >/dev/null
export ORACLE_SID=PLATEX
rman @/usr/local/PLATEX/scripts/rman_clean.cmd

Файл /usr/local/PLATEX/scripts/rman_clean.cmd - чистка старых копий (именно этот файл определяет ширину "окна" в 22 дня):

connect target;
crosscheck copy;
crosscheck archivelog all;
delete noprompt expired archivelog all;
delete noprompt archivelog all backed up 1 times to device type disk;
delete noprompt obsolete until time 'sysdate-22';
delete noprompt backupset completed before 'sysdate-22';
quit;

Файл rman_backup_weekly.sh:

#!/bin/bash
. /etc/profile.d/oracle.sh >/dev/null
export ORACLE_SID=PLATEX
rman @/usr/local/PLATEX/scripts/rman_backup_weekly.cmd

Файл /usr/local/PLATEX/scripts/rman_backup_weekly.cmd - полное копирование:

connect target;
backup incremental level 0 database skip offline skip readonly;
backup archivelog all;
quit;

Файл rman_backup_daily.sh:

#!/bin/bash
. /etc/profile.d/oracle.sh >/dev/null
export ORACLE_SID=PLATEX
rman @/usr/local/PLATEX/scripts/rman_backup_daily.cmd

Файл rman_backup_daily.cmd - инкрементальное копирование:

connect target;
backup incremental level 1 database skip offline skip readonly;
backup archivelog all;
quit;

Файл rman_backup_arch.sh:

#!/bin/bash
. /etc/profile.d/oracle.sh >/dev/null
export ORACLE_SID=PLATEX
rman @/usr/local/PLATEX/scripts/rman_backup_arch.cmd

Файл rman_backup_arch.cmd - копирование архивных журналов redo:

connect target;
backup archivelog all;
delete noprompt archivelog all backed up 1 times to device type disk;
quit;

Данные файлы необходимо поместить в каталог /usr/local/PLATEX/scripts.
 

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