Цель работы - настроить процедуру периодического резервного копирования базы данных, сконфигурированной в ходе выполнения лабораторной работы №2, а также разработать и отладить сценарии восстановления в случае сбоев.

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

Требования к отчёту

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

Этап 1. Резервное копирование

• Настроить резервное копирование с основного узла на резервный следующим образом:
  Периодические холодные полные копии.
  Полная копия (rsync) по расписанию (cron) раз в сутки. СУБД на время копирования должна останавливаться. На резервном узле хранить 14 копий, после успешного создания пятнадцатой копии, саму старую автоматически уничтожать.
• Подсчитать, каков будет объем резервных копий спустя месяц работы системы, исходя из следующих условий:
  • Средний объем новых данных в БД за сутки: 250МБ.
  • Средний объем измененных данных за сутки: 150МБ.
• Проанализировать результаты.

Этап 2. Потеря основного узла

Этот сценарий подразумевает полную недоступность основного узла. Необходимо восстановить работу СУБД на РЕЗЕРВНОМ узле, продемонстрировать успешный запуск СУБД и доступность данных.

Этап 3. Повреждение файлов БД

Этот сценарий подразумевает потерю данных (например, в результате сбоя диска или файловой системы) при сохранении доступности основного узла. Необходимо выполнить полное восстановление данных из резервной копии и перезапустить СУБД на ОСНОВНОМ узле.

Ход работы:

• Симулировать сбой:

  • удалить с диска директорию конфигурационных файлов СУБД со всем содержимым.

• Проверить работу СУБД, доступность данных, перезапустить СУБД, проанализировать результаты.

• Выполнить восстановление данных из резервной копии, учитывая следующее условие:

  • исходное расположение директории PGDATA недоступно - разместить данные в другой директории и скорректировать конфигурацию.

• Запустить СУБД, проверить работу и доступность данных, проанализировать результаты.

Этап 4. Логическое повреждение данных

Этот сценарий подразумевает частичную потерю данных (в результате нежелательной или ошибочной операции) при сохранении доступности основного узла. Необходимо выполнить восстановление данных на ОСНОВНОМ узле следующим способом:

• Восстановление с использованием архивных WAL файлов. (СУБД должна работать в режиме архивирования WAL, потребуется задать параметры восстановления).

Ход работы:

• В каждую таблицу базы добавить 2-3 новые строки, зафиксировать результат.
• Зафиксировать время и симулировать ошибку:
• перезаписать строки любой таблицы "мусором" (INSERT, UPDATE)
• Продемонстрировать результат.
• Выполнить восстановление данных указанным способом.
• Продемонстрировать и проанализировать результат.