Резервное копирование PostgreSQL 12 и восстановление на определенный момент времени

11.08.21

База данных - Архивирование (backup)

Непрерывное архивирование базы данных PostgreSQL на 12ой версии и восстановление на определенный момент времени.

Предисловие 

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

В интернете инфы мало, да есть записи вебинаров и статьи, НО либо они подходят на старую версию Postgres, либо написаны сложным языком (непонятны новичку).

Приступим

Для начала у вас должен быть установлен Postgres 12 версии и выше, возможно в 14 версии они опять что то переделают, но это будет не особо отличаться.

Создаем каталоги для WAL файлов и полного бэкапа 

sudo -H -u postgres mkdir /var/lib/postgresql/pg_log_archive

sudo -H -u postgres mkdir /var/lib/postgresql/db_file_backup

Переходим в конфиг Postgres`a 

sudo nano /etc/postgresql/12/main/postgresql.conf

Раскомментироваем и редактируем следующие параметры 

archive_mode = on 

archive_command = 'test ! -f /var/lib/postgresql/pg_log_archive/%f && cp %p /var/lib/postgresql/pg_log_archive/%f'

archive_timeout = 1800 (указываем значение в секундах)((Принудительно переключается на новый файл сегмента WAL))

Перезапускаем кластер чтобы изменения вступили в силу

sudo systemctl restart postgresql@12-main

После перезапуска в каталоге /var/lib/postgresql/pg_log_archive/ появляются первые WAL журналы 000000010000000000000081
000000010000000000000082 ; 00000001 - ветка времени (немного подробнее тут ) 
Делаем бэкап или же контрольную точку от пользователя postgres

su postgres
cd ~
#Простая копия кластера в каталог
 pg_basebackup -D /var/lib/postgresql/db_file_backup
#Бэкап в архиве tar
pg_basebackup -Ft -D /var/lib/postgresql/db_file_backup
#Бэкап в сжатом архиве 
pg_basebackup -Ft -X none -D - | gzip > /var/lib/postgresql/db_file_backup.tar.gz

Восстановление 

Перед восстановлением свапаем на новую стенку дабы не потерять данные которые не успели записаться

su postgres 
cd ~
psql -c "select pg_switch_wal();"

Выключаем Postgres 

sudo systemctl stop postgresql@12-main
#Проверяем статус
sudo systemctl status postgresql@12-main

Удаляем данные кластера 

sudo rm -rf /var/lib/postgresql/12/main

Восстанавливаем кластер из контрольной точки ( pg_basebackup) 

#Простой бэкап
sudo cp -a /path/to/database_backup/. /var/lib/postgresql/12/main/ 
#Извлечение из архива
tar xvf /var/lib/postgresql/db_file_backup/base.tar -C /var/lib/postgresql/12/main/
#Сжатый архив 
tar xvfz /var/lib/postgresql/db_file_backup.tar.gz -C /var/lib/postgresql/12/main/

После восстановления даем права на каталог пользователю postgres 

sudo chown postgres:postgres /var/lib/postgresql/12/main

sudo chmod 700 /var/lib/postgresql/12/main

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

sudo nano /etc/postgresql/12/main/postgresql.conf

#Раскомментить и прописать путь, где лежат WAL журналы
restore_command = 'cp /var/lib/postgresql/pg_log_archive/%f %p'

#Восстановление на определенный момент времени
##Раскомментить и прописать дату 
recovery_target_time = 'yyyy-mm-dd hh:mm:ss.ss' ('2021-08-10 15:20:00')

#Восстановление на определенную ветку времени
##Раскомментить и прописать значение 
recovery_target_timeline = 'latest' - до последней ветки
recovery_target_timeline = '1' - до указанной

Остальные параметры восстановления и их описание (клик)

Чтобы запустить сервер в режиме восстановления, создадим в корнем каталоге файл recovery.signal 

sudo touch /var/lib/postgresql/12/main/recovery.signal

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

Запускаем postgres

sudo systemctl start postgresql@12-main
sudo systemctl status postgresql@12-main

#Получим что то подобное 

`79; postgresql@12-main.service - PostgreSQL Cluster 12-main
Loaded: loaded (/lib/systemd/system/postgresql@.service; disabled; vendor preset: enabled)
Active: active (running) since Tue 2021-08-10 14:07:34 MSK; 3s ago
Process: 29045 ExecStop=/usr/bin/pg_ctlcluster —skip-systemctl-redirect -m fast 12-main stop (code=exited, status=0/SUCCESS)
Process: 29052 ExecStart=/usr/bin/pg_ctlcluster —skip-systemctl-redirect 12-main start (code=exited, status=0/SUCCESS)
Main PID: 29059 (postgres)
Tasks: 6 (limit: 4915)
CGroup: /system.slice/system-postgresql.slice/postgresql@12-main.service
_00;^72;29059 /usr/lib/postgresql/12/bin/postgres -D /var/lib/postgresql/12/main -c config_file=/etc/postgresql/12/main/postgr
_00;^72;29060 postgres: 12/main: logger
_00;^72;29061 postgres: 12/main: startup recovering 00000002000000000000008A
_00;^72;29065 postgres: 12/main: checkpointer
_00;^72;29066 postgres: 12/main: background writer
^92;^72;29068 postgres: 12/main: stats collector

авг 10 14:07:31 astra systemd[1]: Stopped PostgreSQL Cluster 12-main.
авг 10 14:07:31 astra systemd[1]: Starting PostgreSQL Cluster 12-main...
авг 10 14:07:34 astra systemd[1]: Started PostgreSQL Cluster 12-main.

В будущем хочу научиться потоковой репликации wal журналов, чтобы обеспечить полную отказоустойчивую систему
Так что ждите новых мануалов)

Администрирование Postgresql Непрерывное архивирование WAL журналы

См. также

Журнал изменений с восстановлением состояния ссылочных объектов и архивацией по HTTP / COM (расширение + конфигурация, 8.3.14+, ЛЮБАЯ конфигурация)

Архивирование (backup) Журнал регистрации Поиск данных Платформа 1С v8.3 Управляемые формы Конфигурации 1cv8 1С:Управление торговлей 11 Платные (руб)

База данных «сама» меняет данные в документах/справочниках? Тогда данный журнал изменений для Вас! Практически не влияет на скорость записи объектов за счет быстрого алгоритма! Скорость работы почти в 2 раза выше типового механизма "История изменений"! Позволяет следить за изменениями и удалением в любых ссылочных объектах конфигурации, с возможностью архивации по HTTP(!) или COM, и сверткой данных. А так же, может восстановить состояние реквизитов (значения) до момента изменения или удаления объекта из базы. Есть ДЕМО-база где можно самостоятельно протестировать часть функционала! Работает на любых платформах выше 8.3.14+ и любых конфигурациях! Версия 3.1 от 24.08.2023!

21600 руб.

15.05.2017    42647    10    24    

38

BackUPv8 - система резервного копирования баз 1С

Архивирование (backup) Платформа 1С v8.3 Конфигурации 1cv8 Платные (руб)

Автоматическое создание копий файловых и серверных информационных баз 1С Предприятие 8 и размещение копий в облаке Яндекс.Диск, локальном или сетевом ресурсе.

1200 руб.

03.09.2014    14835    15    6    

18

Автоматическое резервное копирование любой клиент-серверной базы 1С в формате DT с удалением сеансов, архивацией, изменением расширения (8.3.14+, расширение)

Архивирование (backup) Инструменты администратора БД Платформа 1С v8.3 Управляемые формы Конфигурации 1cv8 Платные (руб)

Данная разработка позволит решить вопрос с резервным копированием Ваших баз в автоматическом режиме, расположенных на сервере 1С. Система умеет ставить блокировки на вход, блокировать фоновые задания, принудительно отключать сеансы пользователей. И все это система делает в автоматически при создании бэкапа (или через команду). Выгрузка происходит в родной формат 1С - .dt. Так же система умеет архивировать данные выгрузки с установкой пароля. Умеет менять расширение файла zip или dt на любое указанное вами, что позволит сохранить выгрузки от шифровальщика. Может удалять старые копии выгрузок, оставляя указанное количество резервных копий, начиная с самой поздней.

6000 руб.

06.11.2012    70237    622    44    

80

Резервное копирование журнала транзакций, наконец-то!

Архивирование (backup) Администрирование СУБД Россия Бесплатно (free)

Постараюсь объяснить, зачем нужно резервное копирование именно журнала транзакций, а не только базы данных, и почему я словно сбросил груз, настроив его - как, покажу, естественно. Кстати, будут скрипты T-SQL (с подробными комментариями) - отличный способ сделать администрирование базы более уютным.

04.12.2023    6284    n_mezentsev    15    

26

Резервное копирование и восстановление 1С баз на PostgreSQL в Windows с помощью pgAdmin, bat-файлов и планировщика

Архивирование (backup) Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

В данной инструкции будет описано, как с помощью pgAdmin, bat-файлов и планировщика заданий Windows организовать резервное копирование, восстановление и хранение копий баз данных.

07.10.2022    20574    sapervodichka    36    

143

Архивирование базы в dt и дамп postgres

Архивирование (backup) Платформа 1С v8.3 Конфигурации 1cv8 Россия Абонемент ($m)

Захотелось клиентам выгрузку архива баз, и выгрузку в дт, готовые скрипты с сети не заработали. Может, кому-то поможет. Релиз 8.3.18.1741.

1 стартмани

25.08.2022    4813    2    Gnom-Gluck    6    

7
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. baracuda 2 14.08.21 20:44 Сейчас в теме
Спасибо за мануал! Думаю много кому пригодится.
2. al.semenenko88 16.08.21 14:44 Сейчас в теме
свапаем на новую стенку

Можно расшифровку этой фразы?
3. Vismut 52 16.08.21 15:58 Сейчас в теме
Переключаемся на новую стенку. Некоторые транзакции возможно не успели записаться перед восстановлением, хотя после выключения Postgres`a он может их сохранить. Вы заметите это когда будете поэкспериментировать на виртуалке
4. KlSergey 29 17.08.21 13:43 Сейчас в теме
(3)
Перед восстановлением свапаем на новую стенку дабы не потерять данные которые не успели записаться

su postgres
cd ~
psql -c "select pg_switch_wal();"

Правда не совсем понятно.
Мы же вроде хотим восстановится по времени назад , на ранее созданный бекап все нужные данные в нём ?
Зачем эта операция ?
А если сервер упал или база "развалилась", без этой команды не получится восстановиться ?
5. Vismut 52 18.08.21 12:47 Сейчас в теме
Мы можем откатываться назад по определенным причинам,вдруг после отката мы захотим вернуться обратно
Ее не обязательно прописывать при восстановлении, это просто рекомендация
6. Feelthis 38 14.04.23 19:04 Сейчас в теме
Не совсем понятно и не описано в статье один момент: нужно ли cron настраивать на периодическое обновление полной копии pg_basebackup?
Если мы повторно сделали pg_basebackup - получается обновили полную копию, что произойдет с директорией pg_log_archive? Там будут появляться новые файлы WAL ? Нужно ли чистить старые? Не сломается ли восстановление? Нужен ли рестарт сервера и изменение конфига?

Я так понимаю обновлять нужно, если нам не требуется восстановление старше месяца (в целях экономии места), то есть храним полный бекап месячной давности остальное WAL собираем, так?
Опишите пожалуйста процесс обновления полного бекапа pg_basebackup и как сделать вручную и поместить в cron.
kozhakinav; +1 Ответить
7. user2007519 30.10.23 16:02 Сейчас в теме
Виталий, прочитав вашу статью захотел повторить это у себя. Результат - отрицательный. Как с вами связаться, чтобы получить консультацию? Пробовал через Телеграмм, там послали к вам.
Оставьте свое сообщение