Postgresql создание резервной копии windows

Создание бэкапа базы PostgreSQL для Windows

В PostgreSQL есть утилита, которая создает дамп базы данных и называется она pg_dump. Для того чтобы автоматизировать процесс создания бэкапов баз PostgreSQL нужно будет создать bat-файл, который будет вызывать утилиту pg_dump и вызывать его с помощью планировщика заданий. Результатом выполнения такого сценария будет ежедневное копирование базы данных PostgreSQL, ведение журнала с информацией о датах и результатах выполнения, сохранение подробных сведений о ходе выполнения каждой резервной копии в отдельный текстовый файл и в случае неудачи отображение диалогового окна с сообщением. Содержимое bat-файла следующее:

Справочную информацию о командах, испульзуемых в этом файле можно получить из командной строки набрав следующую команду: «[Имя команды] /?»
Многие использованные здесь команды достаточно распространены и известны, поэтому хочется акцентировать внимание на нескольких менее известных.

Строки 15, 16 выполняют переход в папку в которой находится файл «backup.bat». «%0» возвращает имя bat-файла; «%

dp0″ возвращают соответственно диск и путь к bat-файлу. Подробные сведения о работе с параметрами файла можно посмотреть по этой ссылке.

В строке 19 формируется строковое представление даты и времени в нужном формате. При формировании происходит обращение к переменным окружения DATE и TIME, которые хранят текстовое представление даты и времени соответственно. После имени переменной указывается строка вида «:

В строке 27 вызывается утилита резервного копирования pg_dump.exe. Вызов выполняется с применением команды CALL, это позволяет дождаться завершения утилиты и проанализировать результат выполнения. Вызов утилиты завершается строкой «2>%LOGPATH%». Эта строка означает что поток ошибок STDERR, номер которого 2, приложения pg_dump.exe перенаправляется в файл, имя которого сохранено в переменной окружения LOGPATH. Так как приложение pg_dump.exe выводит все сообщения в стандартный поток ошибок, то в файле LOGPATH будет сохранен подробный отчет о выполнении резервного копирования.

Проверяем как работает bat-файл. Если дампы базы создаются, то можно приступать к созданию задачи для планировщика заданий Windows.
Создаем задание, которое будет запускать bat-файл каждый день в ночное время.

Ежедневные бэкапы со временям породят проблему свободного пространства на жестком диске. Можно чистить ручками, но лучше уж автоматизацию сделать полной. Решается этот вопрос также созданием bat-файла и задачи в планировщике заданий Windows.

Содержимое bat-файла такое:

Здесь указана команда при выполнении которой будут удаляться файлы старше 5 дней.
В планировщике заданий можно создать задачу на исполнения этого bat-файла раз в неделю.

Источник

Резервное копирование PostgreSQL

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

Все команды, которые приводятся ниже, должны выполняться из командной строки. В Linux — это окно терминала, в Windows — командная строка (cmd.exe) с переходом в папку установки PostgreSQL.

Создание резервных копий

Базовая команда

pg_dump users > /tmp/users.dump

Пользователь и пароль

Если резервная копия выполняется не от учетной записи postgres, необходимо добавить опцию -U с указанием пользователя:

* где dmosk — имя учетной записи; опция W потребует ввода пароля.

Сжатие данных

Для экономии дискового пространства или более быстрой передачи по сети можно сжать наш архив:

pg_dump users | gzip > users.dump.gz

Скрипт для автоматического резервного копирования

Рассмотрим 2 варианта написания скрипта для резервирования баз PostgreSQL. Первый вариант — запуск скрипта от пользователя root для резервирования одной базы. Второй — запуск от пользователя postgres для резервирования всех баз, созданных в СУБД.

Для начала, создадим каталог, в котором разместим скрипт, например:

Вариант 1. Запуск от пользователя root; одна база.

PGPASSWORD=password
export PGPASSWORD
pathB=/backup
dbUser=dbuser
database=db

* где password — пароль для подключения к postgresql; /backup — каталог, в котором будут храниться резервные копии; dbuser — имя учетной записи для подключения к БУБД; pathB — путь до каталога, где будут храниться резервные копии.
* данный скрипт сначала удалит все резервные копии, старше 61 дня, но оставит от 15-о числа как длительный архив. После при помощи утилиты pg_dump будет выполнено подключение и резервирование базы db. Пароль экспортируется в системную переменную на момент выполнения задачи.

Для запуска резервного копирования по расписанию, сохраняем скрипт в файл, например, /scripts/postgresql_dump.sh и создаем задание в планировщике:

3 0 * * * /scripts/postgresql_dump.sh

* наш скрипт будет запускаться каждый день в 03:00.

Вариант 2. Запуск от пользователя postgres; все базы.

* где /backup — каталог, в котором будут храниться резервные копии; pathB — путь до каталога, где будут храниться резервные копии.
* данный скрипт сначала удалит все резервные копии, старше 61 дня, но оставит от 15-о числа как длительный архив. После найдет все созданные в СУБД базы, кроме служебных и при помощи утилиты pg_dump будет выполнено резервирование каждой найденной базы. Пароль нам не нужен, так как по умолчанию, пользователь postgres имеет возможность подключаться к базе без пароля.

Необходимо убедиться, что у пользователя postgre будет разрешение на запись в каталог назначения, в нашем примере, /backup/postgres.

Зададим в качестве владельца файла, пользователя postgres:

chown postgres:postgres /scripts/postgresql_dump.sh

Для запуска резервного копирования по расписанию, сохраняем скрипт в файл, например, /scripts/postgresql_dump.sh и создаем задание в планировщике:

* мы откроем на редактирование cron для пользователя postgres.

3 0 * * * /scripts/postgresql_dump.sh

* наш скрипт будет запускаться каждый день в 03:00.

Права и запуск

Разрешаем запуск скрипта, как исполняемого файла:

chmod +x /scripts/postgresql_dump.sh

Единоразово можно запустить задание на выполнение резервной копии:

. или от пользователя postgres:

На удаленном сервере

* необходимо убедиться, что сама СУБД разрешает удаленное подключение. Подробнее читайте инструкцию Как настроить удаленное подключение к PostgreSQL.

Дамп определенной таблицы

Запускается с опцией -t или —table= :

* где students — таблица; users — база данных.

Размещение каждой таблицы в отдельный файл

* где /tmp/folder — путь до каталога, в котором разместяться файлы дампа для каждой таблицы.

Только схемы

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

Только данные

Использование pgAdmin

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

В открывшемся окне выбираем путь для сохранения данных и настраиваемый формат:

При желании, можно изучить дополнительные параметры для резервного копирования:

Не текстовые форматы дампа

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

Источник

Резервное копирование и восстановление БД 1С 8.3 на PostgreSQL 11.5

Столкнулся с проблемой резервирования и восстановления бэкпапа на PostgreSQL (оказалось все не так просто как MSSQL). На просторах нашей не объятой сети, найти что то дельное и работающее из коробки очень проблемно, поэтому все пришлось собирать по кусочкам из разных источников, методом проб и ошибок чтобы получить действительно рабочую схему. Также решение проблем, с которыми можно столкнуться.

Подробнее о командах резервирование и восстановление, а также их параметрах, можно прочесть в документации офф. сайте postgrespro.ru

1. Резервирование базы 1с 8.3 на базе PostgreSQL.

Пример Bat-файла с командами для резервирования (выделенные строки надо убрать)

REM УКАЗАНИЕ ПЕРЕМЕННЫХ СРЕДЫ POSTGRESQL
SET PGBIN=C:\Program Files\PostgreSQL\11.5-7.1C\bin\
SET PGDATABASE=bdpostgre — Имя базы на Postgre сервере
SET PGHOST=localhost
SET PGPORT=5432
SET PGUSER=postgres — Имя пользователя Postgre сервера
SET PGPASSWORD=password — Пароль пользователя Postgre сервера

REM ПЕРЕХОД В КАТАЛОГ С bat-ФАЙЛОМ (ОТКУДА ЗАПУЩЕН ФАЙЛ)
%

REM ФОРМИРОВАНИЕ ИМЕНИ ФАЙЛА ДЛЯ РЕЗЕРВНОЙ КОПИИ И LOG ФАЙЛА ОТЧЕТА
SET DAT=%date:

6,4% — Получаем текущую дату для имени файла
SET DUMPFILE=D:\1C BackUp\%DAT%-sibek.pgsql.backup — Бэкап файл базы
SET LOGFILE=D:\1C BackUp\%DAT%-sibek.pgsql.log — лог файл процесса
SET DUMPPATH=»%DUMPFILE%»
SET LOGPATH=»%LOGFILE%»

REM ВЫПОЛНЕНИЕ КОМАНДЫ (ПРОГРАММЫ) ЗАВЕРШЕНО, ЕСЛИ ОШИБОК НЕТ ТО КОНЕЦ
IF NOT %ERRORLEVEL%==0 GOTO Error
GOTO Successfull
REM ПРИ ВОЗНИКНОВЕНИИ ОШИБОК УДАЛЯЕТСЯ ПОВРЕЖДЕННЫЙ ФАЙЛ КОПИИ И СООТВЕТСТВУЮЩАЯ ЗАПИСЬ В ЖУРНАЛЕ О ЕЕ СОЗДАНИИ
:Error
DEL %DUMPPATH%
MSG * «Ошибка при создании резервной копии базы данных. Смотрите backup_sibek.log.»
ECHO %DATETIME% Ошибки при создании резервной копии базы данных %DUMPFILE%. Смотрите отчет %LOGFILE%. >> backup_sibek.log
GOTO End

REM ЕСЛИ КОПИЯ СДЕЛАНА БЕЗ ОШИБОК ДЕЛАЕТСЯ ЗАПИСЬ В ЖУРНАЛЕ РЕГИСТРАЦИИ
:Successfull
ECHO %DATETIME% Успешное создание резервной копии %DUMPFILE% >> backup_sibek.log
GOTO End
:End

ВАЖНО! Убрать все пробелы после параметров (чтобы сразу был перенос строки) иначе работать не будет т.к. пробелы будут считаться как символы.

Если несколько БД то можно сделать для каждой БД отдельный bat-файл, либо скопировать полностью код и вставить в один bat-файл (2-3 раза) в зависимости от количества баз, изменяя только имя базы и имена файлов бэкапа и логов.

2. Автоматическое резервирование по расписанию

Заходим в раздел Триггеры там настраиваем расписание выполнения задания

В разделе Действия указываем какое действие выполнять (в нашем случае указываем наш bat-файл), где прописаны все необходимые команды

После выполнения команды в указанной папке будет создан бэкап и лог файлы процесса выполнения.

На этом этап резервирование закончен, переходим в этапу восстановления БД из резервной копии.

3. Восстановление копии БД 1С 8 на PostgreSQL

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

Первая проблема. При попытка восстановить БД может возникнуть ошибка:

Не какие регистрации данной DLL (regsvr32), обновление и прочее не помогу, надо данную DLL скопировать в System32 и все заработает как часы.

DLL находится: C:\Program Files\PostgreSQL\11.5-7.1C\pgAdmin 4\bin\python36.dll

DLL скопировать: C:\Windows\System32\python36.dll

Вторая проблема. При восстановление БД в PostgreSQL, она должна быть создана только на Postgre сервер, а в консоле 1С Севера ее быть не должно иначе будет куча ошибок проблем и результат отрицательный (в сравнении с MSSQL таких проблем нет). Так и не разобрался почему, но если настроена связь базы данные на 1с сервере и PostgreSQL сервере то база валится в ошибки (Сервер 1с и PostgreSQL находятся на одном ПК, возможно причина в этом).

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

После чего наживаем правой кнопкой на созданную БД выбираем пункт «Восстановить«

И указываем параметры:

Процесс восстановление займет какое то время.

После чего БД можно создавать на 1С Сервере и подключать к Postgre:

Читайте также:  8024400a ошибка обновления windows 7

После этого в базу можно заходить и работать, все работает корректно проблем в работе не было.

Во вложении Bat-файл для копирования 2 баз.

Источник

Записки IT специалиста

Технический блог специалистов ООО»Интерфейс»

Резервное копирование баз данных PostgreSQL.

Мы не будем напоминать о важности резервного копирования данных, об этом немало сказано, а поговорим о практической реализации одного из сценариев. Сегодня в фокусе нашего внимания будет популярная бесплатная СУБД PostgreSQL. Актуальности данному вопросу добавляет тот факт, что PostgreSQL активно используется для хранения информационных баз системы 1С:Предприятие.

В данном материале мы рассмотрим реализацию резервного копирования на примере сервера баз данных для 1С:Предприятия, который мы описывали в данной статье. Также заметим, что всё, о чем пойдет речь ниже одинаково применимо как к платформе Linux, так и к платформе Windows, за незначительными уточнениями.

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

Итак, в нашем распоряжении имеется сервер СУБД на базе Ubuntu Server, где расположены базы 1С:Предприятия, наша задача обеспечить автоматическое резервное копирование в соответствии с заданными условиями.

Прежде всего настроим авторизацию для СУБД. Так как основные операции должны будут производится из скрипта, то имеет смысл разрешить локальный доступ к СУБД без авторизации. Учитывая, что доступ к серверу БД имеет ограниченный круг лиц и расположен он в периметре сети, безопасность пострадает слабо.

Откроем файл pg_hba.conf, он находится в /var/lib/pgsql/data и приведем к следующему виду строку:

На платформе Windows данный файл находится в C:\Program Files\PostgreSQL\Версия_СУБД\data и строка будет иметь несколько иное содержание:

Для создания резервной копии воспользуемся утилитой pg_dump, которая позволяет создать дамп для указанной БД. Создание дампа происходит без блокирования таблиц и представляет снимок БД на момент выполнения команды. Т.е. вы можете создавать дампы во время работы пользователей, в то время как для создания резервной копии средствами 1С вам нужен монопольный доступ к базе.

Синтаксис pg_dump предельно прост, нам нужно указать имя базы и расположение и название файла дампа. Просмотреть список баз можно командой:

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

Теперь, уточнив наименование баз на сервере создадим резервную копию базы unf14:

результатом выполнения команды будет файл дампа в домашней директории. Расширение файла мы рекомендуем указывать таким образом, чтобы по нему было понятно назначение данного файла и оно может быть любым. В нашем случае мы используем pgsql.backup, глянув на такой файл сразу станет понятно о его назначении, это может быть важно, если поиском дампов будут заниматься ваши коллеги. Также мы не рекомендуем использовать расширение .bak, потому что многие утилиты «для оптимизации» удаляют такие файлы.

При необходимости можем создать сжатый дамп:

Сжатие позволяет уменьшить размер дампов примерно вдвое, поэтому следует его использовать при передаче резервных копий по сети интернет или при ограниченном размере хранилища.

Теперь рассмотрим процедуру восстановления. Для примера будем использовать сервер под управлением Windows. Никаких существенных особенностей по работе с PostgreSQL на разных платформах нет. Однако под Windows следует вместо psql использовать psql.bat и указывать полный путь к утилитам C:\Program Files\PostgreSQL\Версия_СУБД\bin, либо добавить этот путь в системную переменную PATH.

Еще одно важное замечание. Кодировка исходного и целевого серверов должна совпадать, иначе вы после восстановления получите нерабочую базу. На платформе Linux СУБД обычно работает в кодировке UTF8, в то время как сборка PostgreSQL от 1С на Windows по умолчанию устанавливается в кодировке WIN1251.

Для 1С:Предприятия типичным симптомом того, что вы залили UTF8 базу на сервер с WIN1251 является невозможность авторизоваться в ИБ.

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

Теперь зальем полученный дамп в только что созданную базу unf14:

На платформе Линукс эта команда будет выглядеть так:

В нашем примере файл дампа находится в C:\backup и домашней директории соответственно.

Все что теперь остается, это через оснастку Администрирование сервера 1С:Предприятия создать новую ИБ или изменить настройки существующей, указав на новый сервер СУБД и новую базу.

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

Начнем с Linux, в нашем случае это Ubuntu Server. Создадим файл скрипта:

и поместим в него следующее содержимое:

Скрипт довольно прост и мы не будем разбирать его подробно. Сохраним его и дадим права на выполнение:

Также не забудем создать каталог /root/backup

Проверив работоспособность скрипта, зададим его регулярное выполнение через cron.

Для платформы Windows все несколько сложнее, так как встроенный архиватор отсутствует, то следует воспользоваться сторонним решением, в нашем случае будет использоваться 7zip, также нужно указывать полные пути к бинарным файлам или добавить их в переменную PATH, мы будем задавать эту переменную динамически в скрипте. Еще одна сложность связана с использованием встроенного ftp-клиента, набор команд для него необходимо подготовить в виде отдельного файла.

Создадим в Блокноте новый файл и разместим там нижеприведенный текст:

Скрипт также довольно прост для понимания и повторяет по структуре и логике скрипт для Ubuntu. Задаем переменные, устанавливаем рабочую директорию и выгружаем туда дамп, затем создаем архив. Следующим шагом формируем файл с командами для FTP-соединения, загружаем архив на FTP и делаем уборку.

Файл следует сохранить как pgsql-backup.bat и разместить в удобном месте. Затем настроить его выполнение по расписанию через Планировщик задач Windows. Также не забудьте создать директорию C:\backup (или любую другою, которую вы хотите использовать в качестве рабочей).

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

Помогла статья? Поддержи автора и новые статьи будут выходить чаще:

Или подпишись на наш Телеграм-канал:

Источник

Инструменты создания бэкапов PostgreSQL. Андрей Сальников (Data Egret)

Я из компании Luxoft.
Предлагаю ознакомиться с расшифровкой доклада Андрей Сальников из Data Egret «Инструменты создания бэкапов PostgreSQL» . В конце обновленная сводная таблица по инструментам

Данный доклад посвящен доступным инструментам бэкапирования PostgreSQL. Логические backup, бинарные backup, встроенные средства бэкапирования и сторонние инструменты. Нужны ли инкрементальные backup, когда они могут действительно помочь. Посмотрим, когда и какой инструмент уместнее использовать. Как лучше автоматизировать процесс бэкапирования и проверки целостности сделанного бэкапа. Посмотрим вблизи на инструменты, такие как pg_dump, pg_basebackup, barman, wal-e, wal-g, pgbackrest, BART и pg_probackup.

Меня зовут Сальников Андрей, я сотрудник компании Data Egret и этот доклад будет посвящён инструментам создания бэкапов в PostgreSQL.

Сначала о том, кто мы, моя компания. Основная наша деятельность: мы работаем как удалённые администраторы и у нас достаточно большое количество клиентов. Есть огромные базы, есть куча маленьких баз, есть всевозможные смеси, когда одна большая база или кучка маленьких. Также мы оказываем услуги консультирования и аудита – это случай если людям не нужна постоянная поддержка, но нужна какая-то экспертиза.
Так как PostgreSQL является открытым продуктом, то мы, естественно, учувствуем во всевозможных конференциях, в плане того, что делится своим опытом и всячески помогать продвижению PostgreSQL. Потому что база данных PostgreSQL действительно хорошая. И получается так, что мы видели довольно много профилей нагрузки: DWH нагрузки, и WEB нагрузки, и смеси нагрузок. И базы падали по-разному. Опыта достаточно много.

Это самая интересная часть доклада. Зачем нужны backup-ы? На самом деле они нужны, чтобы мы могли отдыхать спокойно, чтобы могли спать спокойно, чтобы мы могли тусоваться на концертах спокойно. Вот, это основная цель с точки зрения базы зачем нужны backup-ы. Чтобы все было спокойно в нашей жизни. Потому что, если есть backup-ы проверенные, то мы можем всем этим заниматься. А вот что там с базой произойдет это уже дело десятое.

Какой есть ассортимент инструментов для создания бэкапов в мире PostgreSQL? Это встроенный инструмент pg_dump, pg_dumpall или pg_restore для восстановления. Это единственный инструмент, который позволяет делать вам логическое бэкапирование. То есть pg_dump он вам может, как в SQL вывалить, так и в небольшом бинарном формате вывалить данные. И он идет из коробки с PostgreSQL.
Следующий инструмент (pg_basebackup) для создания бэкапов, который тоже идет из коробки и дальше начиная с этого инструмента, и дальше они все будут инструменты для создания бинарных бэкапов базы данных. Pg_basebackup тоже инструмент, идущий из коробки, который позволяет нам наливать реприки для PostgreSQL и снимать бинарную копию базы данных, снимать персистентную базу данных и, если мы хотим еще во времени иметь возможность архивироваться, то мы можем настроить PostgreSQL так, чтобы архивные логи его сваливать на какой-то диск. Это вот базовые инструменты. Они хорошие, они делают, выполняют свой функционал на 5, но они неудобные с точки зрения управления и какой-то массовости. Когда у вас 20 баз данных, это нужно будет вам заниматься шелскриптингом самостоятельно.
Следующие два инструмента специфичные, чисто облачные инструменты – это wal-e и wal-g. Разрабатывают их одни и те же ребята, но разработка wal-e закончилась, и они переключились на wal-g. Эти инструменты ориентированы для в основном для AWS и для хранения в S3. Wal-e еще умеет работать с Google Cloud, с Azure и с дисковой системой, просто вы можете указать какой-то удаленный диск. Wal-g работает только с AWS, только с S3. Ну или любым другим с S3 похожим интерфейсом. Мы их используем, хорошие штуки. Я дальше в деталях буду разбирать каждый инструмент.

Читайте также:  Battery limiter для windows

И на следующей пачке инструментов, это инструменты, которые опираются на pg_basebackup или используют его напрямую, или каким-то образом реализуют его функционал. Они все написаны разработчиками, которые коммитят в основной PostgreSQL и имеют свой форк коммерческий, который продвигают в своем кругу влияния.
Наиболее популярный инструмент barman, который у нас используется довольно широко в стране. Это по сути дела обертка на Python вокруг pg_basebackup. Еще он может работать по ssh протоколам. Очень интересный и очень многообещающий инструмент pgbackrest. разработчиками занимаются PostgreSQL и активно в него коммитят. Изначально он был написан на Python. Сейчас версия, которая используется — она написана на C для ускорения и возможности параллельного выполнения снятия бэкапов.
Pg_probackup – эта утилита от наших коллег российских в PostgreSQL Professional, которая позволяет делать инкрементальные backup-ы, такие достаточно небольшого размера.
И последняя утилита это backup and recover tool (BART) от компании EnterpriseDB. У нас она не очень популярна. Она в основном для CentOS и Red Hat. Для Ubuntu с ней, по-моему, тяжело. И в связи с малой популярностью BART у нас, ее (BART) почти нет нигде в инсталляциях.

Я бы попытался по этим инструментам разбить на какие-то вещи, которые важны.

Первое нам важно, как мы будем это хранить, на каких дисках и на каких сервисах. И там есть список характеристик, по которым мы пройдемся.

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

Насколько они поддерживают разные версии БД.

Какие режимы работы у них есть в плане параллельности, в плане какой-то автоматизации и тому подобное.

И сервисность это насколько мы можем их выделить в отдельный сервис, который сам будет ходить по базам данных и по какому-то расписанию снимать backup-ы.

Валидирование — хотелось чтобы бэкап еще проверялся в плане того, что мы из него гарантировано потом сможем восстановится и у нас будет нормальная, не поломанная база.

И теперь вот, по этим шести большим пунктам пройдемся более детально. И буду помечать там какой инструмент, что нам даст.

По хранению, в файловой системе хранить они могут все, то есть мы может перемонтировать диск наш к операционке и копировать туда backup-ы. Все инструменты это позволяют делать. Примонтированный сетевой диск — это в принципе тоже самое, потому что это в нашей локальной файловой системе получается.
В AWS (S3) у нас могут работать три инструмента — это wal-g, wal-e, pgbackrest. Потому что среди вот таких утилит: barman и так далее, он единственный, который умеет работать с AWS (S3).
С Azure только wal-e. Google Cloud только wal-e.

Теперь о том, какого размера у нас могут быть backup. Это всё пойдёт в контексте бинарных backup. Понятное дело, что бинарные backup — это сколько у нас база весит, столько мы и скопировали. Весит 8 ТБ, мы скопировали 8 ТБ. 1 МБ весит 1 МБ, скопировали. Как экономить место, когда мы хотим длинную цепочку backupов? Для этого придумали некоторые инструменты. То есть, база данных хранит данные в своих файлах. Если у нас есть длиная архивная база данных, то обычно мы меняем там небольшой % этих файлов. И для этого дела придумали дифференциальный backup.

Дифференциальный backup что из себя представляет? Мы смотрим какие файлики изменились и только копируем на хранилище, где хранить backup. А все остальные файлы мы хардлинком просто прилинкуем к этой базе данных. Получается, что мы тем самым экономим место. И при этом можем спокойно удалить старые backupы базы данных, не попортив более свежие.

Эта штука хорошая, но решили пойти дальше и придумали инкрементальные backup. Инкрементальные backupы есть два вида.

Дальше разделение данных. Тут подразумевается то, что, если нам нужно бекапировать не всё. Или восстанавливать не всё. Это возможно только при логических backup, и это нам позволяет делать только pg_dump. Утилиты довольно широкий функционал предоставляют. Pg_dump может позволить вам сдампить базу данных, структуру, если вам нужна. Можете конкретно одну таблицу сдампить или можете исключить одну таблицу из дампа или список таблиц сдампить, список исключить. Функционал довольно широкий в этом плане. Минус за это то, что при восстановлении с такого дампа, если у вас большая база данных, вам придется потратить достаточно много времени на чтобы восстановиться с него, потому что это всё нужно проигрывать на чистом instance PostgreSQL.
Очень удобны эти утилиты использовать случай, когда мы переоценили свои силы и на создавали кучу мелких баз данных. Мы можем их слить в один instance. Мы можем распилить так, если мы опять теперь оценили наши силы, у нас распухла база данных или меняем архитектуру там с монолита на сервисную и распиливаем данные. Pg_dump в этом случае единственная вещь, которая позволяет это делать безболезненно.

Ещё можно восстановить одну БД и вот тут вот указан pgbackrest. У него есть такая фишка, то что мы можем указать, что нам из бинарного backup нужна только одна база данных. Что он делает? Он восстанавливает база данных по умолчанию из backup, это template и postgres и ту базу данных, которую мы указали. Все остальные базы данных, он файлы обнуляет и делает нулевой длины. То есть у PostgreSQL прозрачная структура хранения баз данных в файлах, там можно на этом уровне, как бы сократить восстанавливаемую базу данных. Допустим нам нужно найти какие срочные данные из бинарника, не хочется 10 ТБ базу поднимать, у нас там две базы, и мы поднимаем одну, которая допустим 5ТБ всего занимает. В данном случае, конечно консистентность нарушается, но для каких-то быстрых решений, когда вам необходимо срочно кровь из носа поднять данные с большой базы данных, которых несколько, то это очень хорошие фичи, которые есть. Но как полноценную backup базы не стоит рассматривать при восстановлении. То есть, это именно для аварийных работ.

Как обстоит работа с множеством версий БД? Тут тоже всё достаточно интересно. Pg_dump очень хорош в плане того, что мы не привязаны к тому, в какую версию БД восстанавливаться. Там есть режим plain text и это просто чистый SQL, который описывает всю структуру базы данных, все данные. Вы можете в принципе оттуда восстановиться куда хотите, в MySQL, в MSSQL, в Oracle с небольшими правками этого дампа. Между мажорными версиями PostgreSQL тоже достаточно легко использовать эти дампы.
Мульти-версионность, что под этим подразумеваю? Это то, что насколько утилита может обрабатывать разные версии баз данных и работать одновременно с PostgreSQL 9.6, 10, 11. Все, кроме встроенных от pg_dump и pg_basebackup, потому что они привязаны к конкретной версии, с которой идут. Остальные ориентируется на эти утилиты. Им можно указывать где находится pg_basebackup, pg_dump разных версий. Они соответственно с версией PostgreSQL выбирают актуальную утилиту для снятия backup.
Для создания реплик, standby серверов подходят все утилиты, кроме pg_dump, потому что это логические backup-ы. Используя любую из этих утилит, вы можете, восстановить серверы и подключить к мастеру для работы, как реплика этого сервера.

Как могут сниматься backup-ы вообще, какие режимы существуют для снятия бэкапов. Можно просто копировать файлы стандартными средствами операционки: по ssh (rsync, scp) протоколу и возможно какие-то другие утилиты, которые есть. Почему такая возможность есть, потому что они позволяют параллелить копирование. Pgbackrest только так работает, barman он может работать так, а может работать по протоколу PostgreSQL.
Протокол PostgreSQL — когда утилита бэкапирования подключается к PostgreSQL и по протоколу репликации тянет все файлы и плюс еще архивные логи, которые возникают в процессе снятия бэкапа. Это умеют все остальные и barman.
Бэкап с реплики умеют в принципе все, это зависит от версии PostgreSQL. С PostgreSQL 10 и 11 мы можем с реплики снимать backup-ы. Но я этого не рекомендую делать, вообще никто из нашей компании не будет это рекомендовать делать. Потому что есть ситуации, когда проморгали по мониторингу, месяц снимали с реплики бэкап, которая отвалилась от мастер-сервера и не актуальна. То есть backup-ы в любом случае всегда нужно снимать с мастер-сервера. Только в таком случае вы будете уверены то, что у вас действительно актуальная бэкап база данных.
Многопоточность бэкапов — это умеют все, потому что все по разным причинам, кто-то через ssh протокол, кто-то реализовал на уровне копирования базы данных. Кроме pg_basebackup и BART, потому что BART операция только на pg_basebackup при снятии бэкапа и он, к сожалению, однопоточный и не будет многопоточный.

Пример многопоточности. Я восстанавливал 8 ТБ базу данных. Когда будете ориентироваться на выбор системы для снятия бэкапов, то знайте что wal-e написан на Python, wal-g написан на Golang. Мне 8 ТБ базу приходилось восстанавливать. Wal-e уперся в ограничение Python и тянул меня с AWS со скоростью 600 мбит/с. Когда я переключился на wal-g, то у него был ситуация, что он не мог работать с бэкапами wal-e, но мог тянуть wal файлы. Поэтому вот эта вот картина по середиине — это восстановление базы данных. Дальше накатывал wal, которые лежали там в S3 и к определенной точке во времени восстанавливался. Wal-e уперся в ограничение Python и параллелизм в Python она такой условный. A wal-g уперся в интерфейс S3, то есть насколько быстрый S3 каждый момент мог отдавать, настолько быстро он и забирал. В среднем это было 2 гбит/с, что достаточно хорошо. То есть с wal-e час изменений в базу получали за 45 минут накатывания бекапа. С wal-g получилось, что они час изменения базы данных накатывали где-то минут за 5.

Режимы работы, что тут есть у нас интересного в системе бэкапирования.

Сервисность, что тут у нас интересного по системам бэкапирования может быть.

Валидирование у backup. Хотелось бы, чтобы мы были уверены при снятии backup, потому что хороший backup это тот, который потом ещё поднят, поднят сервер и прогнали на нём теми тестами. Практика показывает, что среди наших клиентов никто не делает. Пока они мы не пришли, никто не делал. Потом начинают делать. Потому что на stage накатывают из дампа. Есть некоторые вещи, которые позволяют нам быть достаточно хорошо уверены, что у нас backup валидный. С помощью CLI можем посмотреть, что же там у нас сохранилось и валидный ли эти backup и как это проверяется.

Читайте также:  Snegabrakill для windows 10 64 bit

Первое что нам интересно то, что мы действительно скопировали все файлы, которые нужны. Эти системы бэкапирования после того как зальют все файлы, должны показать что backup валидный. Пока бекап заливается, он должен быть в прогрессе. Если отвалились, он должен быть фейл. В принципе, они все так умеют. Хочется ещё больше. Этот механизм checksum в PostgreSQL. Он работает только в том случае, если вы включили у себя checksum в PostgreSQL. Если у вас база данных без checksum, никак не провериться.

Утилиты pgbackrest и pg_probackup в процессе снятия backup вообще ругаются, что у нас нет checksum. Эти утилиты проверяют валидность файлов и блоков файлов по checksum.

Второй пункт, который валидность завершение backup, там в процессе копирования снимается checksum файла, он, когда скопирован checksum проверяется на хранилище. Это вот так мы валидируем.

Это ссылочки по всем этим утилитам. Эта тема короткая, но обзора полного не было. Цель доклада было дать представление о том, кто что из них умеет.

Вопрос: Вы сказали, что backup лучше снимать с мастера по причине, что реплика может там отстать, вывалиться из мониторинга, быть не актуальна. И соответственно уже есть даже такие методы, которые позволяют нам ограничить пропускную способность, чтобы не сильно нагружать мастера вовремя backup. А не лучше ли, как альтернативу, рассмотреть всё-таки бэкапирования реплики и одновременно, например, мониторить эту реплику, мониторить лак, отставание не реплики там, что ну как бы убеждаться, что она актуальна. Вот здесь есть какие-то может быть подводные камни?

Ответ: В таких случаях можно с реплики снимать, но в данном это если вы гарантированно уверены, что она не отстаёт и так далее. Большинстве случаев как настраивать бэкопирование. Настроили и забыли. Если что-то пошло не так, например, backup снимется с реплики, если она отвалилась, а качество настраиваемых мониторингов как жизнь показала, что она в большинстве случаев ужасна. И конкретно с базами данных на них довольно частенько плюют, чтобы мониторить в необходимом количестве и реагировать на алерты. Пришёл алерт лаг большой, один раз, второй, пришёл, реплика отвалилась, алерты перестали идти, потому что человек выключил алерты/настроил автоматическое прочтение писем от алертов. Человек забыл, а потом через месяц оказывается реплики отстает, особенно если она не участвует в нагрузке. Если она в нагрузке участвует читающей, да вы это сразу обнаружите. Если не участвуют, то лучше настраивать бекапирование на мастере. Просто не раз сталкивался с такими ситуациями, то что люди просто то как бы забили.

Вопрос: Сравнивали ли вы производительность, скорость, как они системы нагружают? Некоторые могут в несколько потоков забьют сеть.

Ответ: У нас есть только один проект на поддержки. У них на каждом сервере базы данных есть 4 интерфейса. В их случае действительно там забивается интерфейс. Есть один интерфейс для репликации. Есть один интерфейс для снятия backup. Два интерфейса для обслуживания нагрузки от приложений. Во всех остальных случаях, сетевых интерфейсов хватает как правило.

Вопрос: Скажите вашу любимую утилиту или вы выбираете под задачи?

Ответ: Это зависит от задач. Потому что в облаках особо вариантов нет. В амазоне wal-e, wal-g, pgbackrest. А так стандартно borman, pg_dump, в принципе basebackup. Всё зависит от того, что хочет у нас конкретно клиент, что он готов и какое оборудование предоставляет. Соответственно выбираем систему.

Вопрос: Скажите пожалуйста, могут ли возникнуть какие-то сложности при использовании расширения PostgreSQL, добавление типа данных, например, postgis или чего-нибудь такого-либо?

Ответ: Потенциально вряд ли возможно, потому что в случае бинарных backup мы копируем файлы, нам без разницы наполнение этих файлов. Если checksum мы включим, то PostgreSQL сам проверяет checksum, если кривой расширение, но она убьет вам базу и работающую. Это не postgis, а допустим вы сами как-то там с логической репликации неудачно игрались. Pg_dump он вообще шикарен в этом плане, потому что он вываливает, по сути дела, SQL команды. То есть его всегда можно развернуть в SQL команды. Надампил и вырезал ненужные вещи. Он, кстати, используется в этом плане как проверка возможности мажорного апгрейда. Когда мы снимаем dump, на катаем на новую версию базу данных.

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

Ответ: Это основная самая важная причина. От бекапа и dump нам важно, чтобы всегда были актуальные данные на момент снятие его. Если они не актуальны, ну то есть – это обычно как происходит, вот забили, потом что-то случилось, начали искать, а этого нету и все. Вот эта рекомендация снимать с мастера, это чисто человеческий фактор. Вот, просто она из-за человеческого фактора, потому что люди имеют тенденцию забивать.

Вопрос: Я правильно понимаю, что в инструментах бинарных бэкапов, весь транзакционный мусор, весь bloat в бэкап идет?

Вопрос: Все это многообразие — это хорошо, но в организациях бывает какая-то централизованная система резервного копирования. Например, Symantec, Veritas Backup Exec и другие. Умеют ли они работать с PostgreSQL?

Ответ: Ну, в принципе их можно научить работать, потому что можно просто скопировать файлы. PostgreSQL можно дать команду для бэкапирования, отправить им команду pg_start_backup. В общем, через скрипты. В принципе можно обучить систему.

Вопрос: Не слышно, чтобы какие-то системы Symantec, Veritas Backup Exec и другие пытались начать нативно взаимодействовать.

Ответ: Мы не сталкивались.

Вопрос: Расскажите, пожалуйста, по подробнее как вы валидируете бэкап. это только checksum или есть еще какие-то техники, типа развернуть бекап, какие-то тесты?

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

Вопрос: Если представить ситуацию, что наш бэкап восстанавливается из WAL логов, лежавших на S3. Если мы их будем тащить с помощью wal-e, wal-g или с помощью каких-нибудь awscli к примеру. Что из этого всего будет быстрее?

Ответ (Отвечает Андрей Бородин): Я разработчик wal-g. Поэтому скажу что быстрее wal-g. У меня доклад целый на 40 минут за счёт чего wal-g быстрее. Я не могу ответить одним словом. Можно сказать, мы долго работали. Да честный параллелизм, prefetch, мы закачиваем wal до того, как он тебе понадобился. Поэтому, когда вон там график был — это график, на самом деле упертый в накат wal. Но даже накат wal мы стараемся оптимизировать, подготавливая в page cache страницы базы данных, к тому, что к ним скоро подъедет wal, то есть там это не просто технология, которая заархивировала и поменьше данных унесла в сеть. Там мы наворотили космоса всякого, сложно коротко сказать.

Вопрос: У меня есть большая база данных 10 ТБ допустим. Я собираюсь делать массированные изменения в базе. Но в любой момент мне захочется вернутся обратно в точку до изменений. Причем сделать это быстро. Просто сделаю в бинарный дамп и wal соответствующие — это потом будет достаточно долго накатываться. Как быстро вернуся к этой точке?

Ответ: Это просто отдельный сервер поднимать для базы данных. Либо делаем реплику и останавливаем репликацию. Высе остальное упрется в копирование файлов. А тут у вас уже готовый инстас базы данных, куда вы просто перекинете нагрузку в случае проблемы.

Вопрос: Если у нас в принципе база сама по себе целостная, то если мы снимаем дамп через pg_dump, то очень небольшая вероятность что он будет битый. Верно?

Ответ: По-хорошему его нужно установить и проверить. Вообще, вероятность небольшая достаточно.

Вопрос: Если дамп битый, то скорее всего проблема в базе, а не в чем-нибудь еще?

Ответ: pg_dump не снимет дамп, если проблема в базе.

Вопрос: У меня просто снимал pg_dump, и он был битый, я не знаю, как это работало, но я не мог его накатить его после этого, он не писал ошибку.

Ответ: Вы могли не накатить его просто по причине того, что у вас не хватало расширения какого-нибудь, криво расширения были поставлены.

Вопрос: База чистая была, без всего вообще.

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

Дополнение: Дополнение к предыдущему вопросу. Почему дамп логически может побиться. К вашему вопросу дополнение могу сказать. Бывают такие случаи логический дамп останавливается. Например, у нас было пару случаев, когда был файл битый. Были поврежденные данные. Pg_dump внезапно останавливался, выдавал какую-то ошибку, но exit_code был нормальный. Все вроде нормально, а на самом деле дамп был битый, неполный. И не восстанавливался, и так что следите за этим.

P.S. №1 Сделал обновленную сводную таблицу с инстрментами кроме pg_dump, pg_basebackup.

barman wal-e wal-g pg_probackup pgbackrest BART
ssh (rsync, scp) + +
Сохранение на файловой системе + + + + + +
S3 + + +
Azure + +
Google Cloud + +
Управление табличным пространством + + + + +
Дифференциальные бэкапы + +
Инкрементальные бэкапы + +
barman wal-e wal-g pg_probackup pgbackrest BART
Инкрементальные по блоку + +
Инкрементальное восстановление (delta restore) + +
Восстановить выбранную БД +
Мульти-версионность + + + + + +
Многопоточный дамп + + + + +
Восстановление на момент времени (Point-in-Time Recovery) + + + + + +
Регулировка нагрузки на сеть + + +
Сжатие на лету + + + + +
CLI + + + + + +
Выделенный сервер + + +
barman wal-e wal-g pg_probackup pgbackrest BART
Структурированное хранение бэкапов + + + + + +
Политики хранения + cron cron + + +
CLI для мониторинга + + + + + +
Валидность завершения бэкапа + + + + + +
Checksum postgresql + +

P.S. №2 Ошибки, исправления по статье, добавления в сводную таблицу можно сделать через Pull request

P.S. №3 Wal-g приветствует волонтеров, которые бы помогли с документацией.

P.S. №4 Для установка wal-g используя rpm вы можете воспользоваться моим репозиторием: Github, Fedora COPR.

P.S. №5 Как сделать в создание и хранение в S3 полный бекап и инкрементальный бекап, а на ленту сохранение только полного бекапа? Если есть идеи, подскажите в коментариях или в личку.

Опрос: Каким инструментов для бекапов вы пользуетесь?

Источник

Поделиться с друзьями
Советы экспертов и специалистов
Adblock
detector