МИНИСТЕРСТВО ЦИФРОВОГО РАЗВИТИЯ,

СВЯЗИ И МАССОВЫХ КОММУНИКАЦИЙ РОССИЙСКОЙ ФЕДЕРАЦИИ

ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ОБРАЗОВАНИЯ

«САНКТ-ПЕТЕРБУРГСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ ТЕЛЕКОММУНИКАЦИЙ ИМ. ПРОФ. М.А. БОНЧ-БРУЕВИЧА» (СПбГУТ)

Факультет: Кибербезопасности Кафедра: Защищенных систем связи

Дисциплина: Основы построения сертифицированных защищенных БД РФ

ОТЧЕТ ПО ЛАБОРАТОРНОЙ РАБОТЕ №4

РЕЗЕРВНОЕ КОПИРОВАНИЕ ВСТРОЕННЫМИ СРЕДСТВАМИ

(тема отчета)

Направление/специальность подготовки 10.03.01 Информационная безопасность

(код и наименование направления/специальности)

Выполнили работу:

Травкина Е.А., ИКБ-14

(Ф.И.О., № группы) (подпись)

Федченко А.С., ИКБ-14

(Ф.И.О., № группы) (подпись)

Ящук А.А., ИКБ-14

(Ф.И.О., № группы) (подпись)

Принял работу:

к.т.н., доцент, Пестов И.Е.

(должность, Ф.И.О.) (подпись)

Санкт-Петербург

Оглавление Цель 3

Задачи 3

Ход работы 3

1. Подготовка директорий, настройка конфигурационного файла 3

2. Резервное копирование базы данных и табличных пространств 4

3. Конфигурация резервной копии, запуск сервера резервной базы данных и проверка работоспособности 6

Вывод 9

Цель

Изучение процесса резервного копирования базы данных в СУБД PostgreSQL встроенными средствами.

Задачи

В ходе выполнения работы будут решаться следующие задачи:

1. Подготовка директорий, настройка конфигурационного файла;

2. Резервное копирование базы данных, табличных пространств;

3. Конфигурация резервной копии, запуск сервера резервной базы данных и проверка работоспособности.

Ход работы

Приступим к выполнению задач:

Подготовка директорий, настройка конфигурационного файла

Для выполнения резервного копирования создадим четыре директории в домашнем каталоге пользователя.

1. new_tablespace – место расположения табличных пространств для резервной базы данных.

2. Pg_backup – основная директория для размещения резервной копии.

3. Backup_files – директория для хранения файлов базы данных в формате архива.

4. Archive - содержит архивированные журналы WAL.

Write-Ahead Log, WAL – это метод ведения журнала транзакций в базах данных для обеспечения надежности данных. WAL фиксирует все изменения, которые вносятся в базу данных, в журнале перед тем, как эти изменения применяются к самой базе данных. Это означает, что даже в случае сбоя (например, аварийного завершения работы системы) база данных может восстановиться, используя записи из журнала.

Настраиваем необходимые права доступа и владельца для оснвной директории и табличных пространств – владелец postgres, права – 700 (рис. 1).

Рис. 1. Подготовка директорий

В конфигурационном файле в разделе Archiving включаем архивацию и указываем директорию archive (рис. 2).

Рис. 2. Настройка архивации WAL

Резервное копирование базы данных и табличных пространств

Выполним команду для создания бэкапа базы данных PostgreSQL. Вот разбор параметров:

• -D указывает директорию для сохранения резервной копии.

• -Ft определяет формат резервной копии, в данном случае tar.

• -Xs включает резервное копирование WAL, что помогает обеспечить согласованность данных.

• -z сжимает архив для экономии места.

• -P показывает прогресс выполнения.

Результат указывает, что резервная копия была успешно создана и в процессе использовано два табличных пространства (рис.3).

Рис. 3. Резервное копирование

В результате выполнения операции, в директории backup_files появляются архивы в формате .tar. В archive же копируются журналы WAL для последующего восстановления базы данных в виде резервного сервера (рис. 4-5).

Рис. 4. Содержимое резервной копии

Рис. 5. Содержимое архивов WAL

Далее инициализировали новый кластер PostgreSQL, используя команду initdb, и установили его конфигурации. Путь к базе данных указан как /home/user/pg_backup. После инициализации PostgreSQL предлагает команду для запуска сервера: (рис. 6).

Рис. 6. Создание нового кластера

После выполнения следующей команды (рис. 7) резервная копия базы данных будет распакована в директорию /home/user/pg_backup. tar -xvf — распаковывает (-x) архив, отображая процесс распаковки (-v) и указывая имя файла архива (-f).

Рис. 7. Разархивирование

Конфигурация резервной копии, запуск сервера резервной базы данных и проверка работоспособности

Переходим к настройке резервной копии. От имени пользователя postgres переходим в pg_backup. В эту директорию уже распакованы файлы резервной БД (рис. 8).

Рис. 8. Содержимое pg_backup

Заходим в tablespace_map и указываем новый путь до табличных пространств (рис. 9).

Рис. 9. Редактирование tablespace_map

Открываем файл конфигурации резервной БД и меняем значение порта на отличное от порта оригинальной БД. В данном случае порт будет 5435 (рис. 10).

Рис. 10. Конфигурация порта

Указываем команду восстановления в файле recovery.conf – этот файл управляет процессом восстановления из резервных копий и журналов WAL (рис. 11).

Рис. 11. Создание recovery.conf

Чтобы настроить процесс восстановления, нужно отредактировать recovery.conf и добавить параметры для управления восстановлением (рис. 12).

restore_command = 'cp /path/to/archive/%f %p'

recovery_target_time = 'YYYY-MM-DD HH:MM:SS' # необязательно, если необходимо восстановиться до определенного времени

Объяснение команд:

• restore_command указывает команду для восстановления сегментов WAL из архива. %f — имя файла в архиве, %p — целевой путь.

• recovery_target_time — время, до которого необходимо восстановить базу данных, в нашем случае этого делать необязательно.

Рис. 12. Указание команды восстановления

После выполненных настроек запускаем сервер с помощью pg_ctl (рис. 13).

Рис. 13. Запуск сервера

Для проверки корректности выполненного резервирования подключаемся к резервному серверу и выполняем команду show data_directory (рис. 14).

Рис. 14. Проверка работоспособности

Вывод

В процессе работы была проведена комплексная процедура резервного копирования и восстановления базы данных PostgreSQL с использованием механизмов Write-Ahead Logging (WAL) и инструментов архивации. На начальном этапе была выполнена резервная копия базы данных с помощью команды `pg_basebackup`, которая позволяет создать полную копию текущего состояния базы данных, включая файлы данных и журналы транзакций. Данная резервная копия была сохранена в сжатом формате, что оптимизировало использование дискового пространства и позволило упростить дальнейшее управление архивом.

Следующим шагом стало распаковывание архивного файла в целевую директорию, которая была подготовлена для размещения восстановленных данных. Команда `tar` позволила извлечь все файлы и структуры базы данных, необходимые для корректной работы системы, что обеспечило целостность данных и готовность системы к дальнейшему восстановлению. Особое внимание было уделено правильной организации структуры данных в целевой директории, что гарантировало совместимость с установленной конфигурацией PostgreSQL.

Для инициирования процесса восстановления и перехода базы данных в режим восстановления был создан специальный файл конфигурации

`recovery.conf`. Этот файл используется PostgreSQL для задания параметров восстановления, таких как команда для восстановления сегментов WAL, а также целевого времени восстановления, если необходимо откатиться к определенному моменту в прошлом. Настройка `recovery.conf` позволяет системе автоматически применять архивные журналы транзакций, восстанавливая состояние базы данных до последней зафиксированной транзакции или до указанного момента времени, что делает процесс восстановления более гибким и контролируемым.

2024