Как правильно сделать бекап базы данных : Oracle

Сейчас получил просто ворох проблем разнообразного толка из-за того, что клиент проигнорировал мои неоднократные рекомендации. Не смог найти тему, значит, неудачно ее назвал. Итак...

Люди делятся на тех, кто не делает бекапы и на тех, кто уже делает бекапы...




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

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

Необходимо делать образ системы, на которой работает база. И каждый раз после каких-то обновлений или внесения изменений в настройки или саму систему (я под этим понимаю операционку, СУБД и все сопутствующее), образ надо снимать заново. При этом удалять старый образ сразу после получения нового нельзя. Нужно подождать пару недель и несколько перезагрузок, чтобы убедиться, что текущий образ снят с боеспособной системы. Обратите внимание, что если вы устроили помойку и система у вас на куче дисков, то снимать образы надо со всех дисков. Как бы вам не хотелось "а наплевать, потом поставлю заново", поверьте, я вот конкретно сейчас трачу по нескольку часов в день, потому, что "поставлю заново" не получилось. Разные операционки, разные версии СУБД, разная их битность, непонятно, где что лежало, и все это на фоне достаточно увесистой пачки баз. Вместо того, чтобы развернуть минут за пять работы и спокойно курить, пока сервер молотит, спотыкаюсь о массу проблем, начиная с кривонаписанных пионерами конфигов и занятого хз чем диска, где должна быть база, и заканчивая выяснением, что дистрибутив не тот, уже после восстановления базы, занявшего не один час.

Теперь у вас образ системы и бекап самой базы данных. Полдела сделано. Надо теперь их хранить.

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

Забирать бекап надо с хранилки, а не класть на хранилку. То есть сервер хранилки подключается к серверу СУБД и эта учетка уникальная в сети. Если будет учетка неуникальная или сервер СУБД будет подключаться к хранилке, то можно получить вариант с шифрованием всех накопленных непосильным трудом бекапов вирусом-шифровальщиком, либо просто распространение вируса по сети с этой учеткой. Мониторинг свободного места и живости дисков на хранилке, надеюсь, догадались поставить сами. Обратите внимание на время создания файлов в директории backupset. Когда они создаются, забирать файлы бекапов не стоит, заберете непонятно что.

На ближайшую неделю сроки хранения базы можете определять сами, исходя из каких-то условий по восстановлению при условном взрыве сервера и других локальных обстоятельств. На длительные сроки политика хранения копий (и базы, и образов системы) определяется бизнесом. Т.е. необходимо выяснить, например, что первого числа каждого месяца бекап откладывается на хранение в полгода. А копия от 15 января хранится пять лет. Это я для примера, пальцем в небо. Решает бизнес, он и платит за диски, где все это будет лежать. Все это записывается на бумажке и бизнес всеми ответственными лицами эту бумажку подписывает. В противном случае, через пару лет от вас потребуют вернуть базу, которую вы стерли по их же просьбе, возразить будет нечего.

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

Бэкап Шрёдингера

☝️ Состояние любого бэкапа остаётся неизвестным до того, как его попробуют восстановить.

Услышал прикольную шутку. Даже любопытно стало почитать подробности оригинального мысленного эксперимента Шрёдингера с котом. Проникся. Для бэкапов этот эксперимент очень актуален. Бэкапы реально находятся в состоянии Шрёдингера до тех пор, пока не попытаешься выполнить восстановление. До этого они существуют и не существуют одновременно, так как если восстановить данные не получится, то это и не бэкап был.