Восстановление базы postgresql: Как восстановить данные PostgreSQL из резервной копии — Effector Saver

Содержание

Резервное копирование и восстановление СУБД PostgreSQL / Хабр

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

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

Сколько терять и за сколько восстанавливать

Итак, вспомним такие понятия как RPO и RTO.

Recovery Point Objective – максимально допустимый интервал за который мы можем позволить себе потерять данные. Например, если у нас RPO равно двум часам, то в случае сбоя мы потеряем данные максимум за последние два часа.

Recovery Time Objective — промежуток времени, в течение которого БД может оставаться недоступной в случае сбоя. То есть это то время за которое мы обязуемся восстановить наши данные из бэкапа.

На картинке расстояние до сбоя это RPO (обычно измеряется в часах) а RTO это то расстояние-время, которое у нас останется на восстановление.

Однако, RTO и RPO нельзя назвать чисто техническим понятиями, в определенной степени это характеристики, позволяющие обеспечивать непрерывность бизнес процессов. Значения величин RTO и RPO должны указываться владельцами бизнес систем, а ИТ специалисты должны в ответ выдвинуть свои требования относительно оборудования и программного обеспечения для выполнения этих требований. Например, если бизнесу необходимо, чтобы в случае аварии данные были потеряны не более чем за час, а процесс восстановления должен занимать не более 30 минут, то админы в ответ должны сказать хранилища какого размера им необходимы, с какими характеристиками по скорости работы дисков и каналов передачи данных. То есть ИТ готовит спецификацию на необходимое оборудование и ПО с ценами, а бизнес посмотрев на все это понимает, что может быть два или даже три часа простоя это не так уж и страшно, да и восстанавливаться можно подольше. В результате согласовываются новые значения RTO и RPO и стоимость спецификации снижается. Такой подход позволяет разделить ответственность между всеми сторонами. Однако очень часто присутствует другой подход к политике резервного копирования, когда ИТ сами устанавливают значения RTO и RPO и сами пытаются их выполнять без согласования с бизнесом, что является в корне неверным.

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

Штатные возможности бэкапа

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

Если для нас критичны данные только в какой-то конкретной таблице, то мы можем сделать бэкап только ее с помощью ключа -t.

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

Опция -U это имя пользователя, под которым мы подключаемся, а -W обязывает ввести пароль при подключении. Естественно, у пользователя otus должны быть права на запись в каталог /tmp.

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

В таком случае проще всего воспользоваться командой pg_dumpall

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

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

Конечно, для выполнения резервного копирования на регулярной основе необходимо использование скриптов. Я не буду засорять статью примерами скриптов и вместо этого предлагаю воспользоваться рекомендациями с официальной wiki PostgreSQL где приводятся примеры нескольких скриптов для бекапа и ротации файлов резервных копий https://wiki.postgresql.org/wiki/Automated_Backup_on_Linux. На просторах сети имеется множество других примеров, как правило дополненных различными механизмами уведомления администратора о результатах выполнения бэкапа.

Физика против логики

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

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

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

В приведенном ниже примере мы создаем полную копию для локального сервера с сохранением в /tmp/ph_backup.bak.

Физический бэкап в отличии от логического выполняется быстрее, также может использоваться для создания базовой резервной копии работающего кластера базы данных PostgreSQL. Резервная копия создается, не затрагивая других клиентов базы данных, и может использоваться как для восстановления на определенный момент времени. Также резервное копирование выполняется через обычное соединение PostgreSQL, использующее протокол репликации. Подробнее о репликации в PostgreSQL мы будем говорить в следующей статье.

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

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

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

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

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

Можно также воспользоваться командой pg_restore.

pg_restore -U username -d dbname -1 filename. dump

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

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

Так как физический бэкап представляет собой по сути набор файлов, которые просто объединены и заархивированы в одном файле нам необходимо скопировать эти файлы в нужные каталоге нашей новой БД.

Для этого необходимо прежде всего остановить СУБД.

Далее необходимо удалить (или хотя бы переместить) все файлы из каталога в котором размещаются базы /var/lib/postgresql/номер_версии/main/* и заменить их теми файлами и каталогами, которые мы получили после восстановления из бэкапа.

Перед запуском СУБД нам необходимо еще создать файл конфига восстановления recovery.conf. Этот файл создается в каталоге /var/lib/postgresql/номер_версии/main/ и содержит следующую строку.

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

Далее необходимо сменить владельца и выдать необходимые права на этот файл, иначе после запуска базы у нас будут проблемы.

Затем запускаем СУБД и смотрим логи, что получилось после бэкапа.

Здесь уже возможны различные варианты развития событий в зависимости от того, каких именно файлов не хватает СУБД для корректного запуска. После запуска СУБД обнаружит файл recovery.conf СУБД войдет в режим восстановления и начнет заново применять содержимое файлов журналов предзаписи (WAL-файлов). По окончании файл recovery.conf будет переименован в recovery.done и PostgreSQL будет готов к работе.

Заключение

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

В конце хочу пригласить всех на бесплатный вебинар курса «PostgreSQL для администраторов баз данных и разработчиков» посвященный маленьким хитростям GROUP BY. На вебинаре вспомним, как устроен GROUP BY и рассмотрим его на наглядных примерах, оптимизируем работу группировки в связке с индексами, разберемся с особенностями группировки строк в PostgreSQL, а также изучим несколько полезных приемов для работы с GROUP BY.

Зарегистрироваться на бесплатный вебинар

Дампы в PostgreSQL: резервное копирование и восстановление

Важным моментом в администрировании любой базы данных является вопрос сохранности данных от воздействия внешних и внутренних факторов: физическая неисправность сервера, взлом БД или ошибка пользователя. Резервное копирование занимает особое место в вопросе сохранности информации. В postgresql это реализуется встроенными и сторонними инструментами, о которых сегодня и пойдет речь.

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

pg_dump

В postgresql резервное копирование одной конкретной базы данных можно осуществить с помощью pg_dump. Во работы этой утилиты пользователь может обращаться к БД: записывать или читать данные.

Формат дампа пользователь определяет сам. Это может быть архив или скрипт. Скрипт — это текстовый файл с перечнем SQL команд. Восстановление БД с помощью скрипта реализуется несколькими путями:

выполнение скрипта в консольном клиенте PostgreSQL;
выполнение такой psql-команды:

psql [имя БД] < [SQL скрипт postgresql dump database]

Восстановления БД с помощью архива реализуется утилитой pg_restore.

Что выбрать: скрипт или архив? Зависит от вашей БД и цели резервного копирования. Если вы хотите перенести БД на другую машину в PostgreSQL, то подойдет скрипт. Архивы же устроены таким образом, что их можно переносить на другие платформы. Помимо прочего, восстановление с помощью pg_restore предоставит вам возможность настраивать сам процесс за счет параметров утилиты.

Важно не забывать: pg_dump создает дамп только одного экземпляра БД. При наличии глобальных объектов PostgreSQL необходимо использовать утилиту pg_dumpall, речь о которой пойдет дальше.

Синтаксис

pg_dump [параметры для подключения] [параметры дампа] [имя БД*] > [каталог, куда необходимо сохранить backup postgres database]

* Если не задать имя БД, то вместо него будет использоваться значение переменной окружения PGDATABASE. А если PGDATABASE не присвоено какое-либо значение, то pg_dump воспользуется именем пользователя, инициирующего утилиту.

Параметры для подключения

-d [name] или —dbname=[name]: имя БД. Равнозначно [имя базы данных].
-h [name] или —host=[name]: имя сервера. По умолчанию host = PGHOST.
-p [port] или —port=[port]: порт. По умолчанию port = PGPORT.
-U [name] или —username=[name]: имя пользователя.

Параметры создания резервной копии

-a или —data-only: сохраняем только данные. Например, при использовании этого параметра связи между таблицами не сохраняются.
-b или —blobs: добавляем в дамп большие объекты. Этот параметр используется по умолчанию.
-B или —no-blobs: не сохраняем большие объекты.
-c или —clean: добавляем в скрипт команды DROP. Может понадобится при наличии объектов с одинаковыми именами. Применим только к SQL скриптам.
-C или —create: добавляем в скрипт команды для создания БД и подключения к ней. Применимо только к SQL скриптам.
-E кодировка или —encoding=кодировка: устанавливаем определенную кодировку дампа.
-f [catalog] или —file=[catalog]: каталог, куда сохраняем дамп. Параметр равнозначен указанному в синтаксисе [каталог, куда необходимо сохранить дамп БД]
-F [format] или —format=[format]: формат дампа. В postgresql format может принимать следующие значения:
- p или plain: SQL скрипт. Значение по умолчанию.
- c или custom: архив.
- d или directory: каталог.
- t или tar: формат .tar
-j [count] или —jobs=[count]: выполняем утилиту в многопоточном формате (количество потоков = [count]).
-n [schema] или —schema=[schema]: сохраняем схемы, удовлетворяющие шаблону.
-N [schema] или —exclude-schema=[schema]: не сохраняем схемы, удовлетворяющие шаблону.
-o или —oids: сохраняем OID.
-O или —no-owner: не добавляем в скрипт команды, связанные с установкой владельцев.
-s или —schema-only: сохраняем только схемы.
-t [schema] или —table=[schema]: сохранить таблицы, удовлетворяющие шаблону.
-T [schema] или —exclude-table=[schema]: не сохраняем таблицы, удовлетворяющие шаблону.
-x или —no-privileges или —no-acl: не сохраняем права доступа.
-Z [0..9] или —compress=[0..9]: выбираем уровня сжатия (0 — не сжимать, 9 — максимальный).

pg_dumpall

Pg_dumpall создает бэкап целого кластера или инстанса. Результат работы утилиты — SQL скрипт. Во многих аспектах эта утилита похожа на pg_dump.

Синтаксис

pg_dumpall [параметры для подключения] [параметры дампа] > [каталог, куда необходимо сохранить дамп]

Параметры для подключения

-d [connection string] или —dbname=[connection string]: задаем строку подключения.
-h [name] или —host=[name]: имя сервера. По умолчанию host = PGHOST.
-p [port] или —port=[port]: порт. По умолчанию port = PGPORT.
-U [name] или —username=[name]: имя пользователя.
-l [name] или —database=[name]: выбираем БД, через которую загрузим глобальные объекты.

Параметры создания резервной копии

-a или —data-only: сохраняем только данные. Например, при использовании этого параметра связи между таблицами не сохраняются.
-c или —clean: добавляем в дамп команды DROP перед CREATE. Может понадобится при наличии объектов с одинаковыми именами.
-f [catalog] или —file=[catalog]: каталог, куда сохраняем дамп. Параметр равнозначен указанному в синтаксисе [каталог, куда необходимо сохранить дамп]
-g или —globals-only: сохраняем только глобальные объекты.
-o или —oids: сохранять OID.
-O или —no-owner: не добавляем в скрипт команды, связанные с установкой владельцев.
-r или —roles-only: сохраняем только роли.
-s или —schema-only: сохраняем только схемы.
-t или —tablespaces-only: сохраняем только табличные пространства.
-x или —no-privileges или —no-acl: не сохраняем права доступа.

pg_basebackup

Pg_basebackup — это утилита для создания бэкапа всего инстанса или кластера. Результат работы — дамп в бинарном формате. Сам процесс нельзя настроить: вы сохраняете кластер (инстанс) целиком. В postgresql список пользователей, обладающих правом создания дампа с помощью pg_basebackup, ограничен. Для этого необходимо быть суперпользователем или обладать правом REPLICATION.

Синтаксис

pg_basebackup [параметры для подключения] [параметры создания резервной копии]

Параметры для подключения

-d [connection string] или —dbname=[connection string]: задаем строку подключения.
-h [name] или —host=[name]: имя сервера. По умолчанию host = PGHOST.
-p [port] или —port=[port]: порт. По умолчанию port = PGPORT.
-U [name] или —username=[name]: имя пользователя.

Параметры создания резервной копии

-D [catalog] или —pgdata=[catalog]: каталог, каталог, куда сохраняем дамп.
-F [format] или —format=[format]: формат дампа. Может иметь следующие значения:
- p или plain: обычные файлы;
- t или tar: формат . tar;
-r [speed]или —max-rate=[speed]: задаем максимальную скорость передачи данных в Кб/с
-Z [0..9] или —compress=[0..9]: выбираем уровня сжатия (0 — не сжимать, 9 — максимальный).

pg_restore

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

Синтаксис

pg_restore [параметры для подключения] [параметры восстановления] [дамп базы данных]

Параметры для подключения

-h [name] или —host=[name]: имя сервера. По умолчанию host = PGHOST.
-p [port] или —port=[port]: порт. По умолчанию port = PGPORT.
-U [name] или —username=[name]: имя пользователя.
-w или —no-password: отключаем запрос пароля.
-W или —password: принудительно включаем запрос пароля.
—role=[name]: задаем имя роли.

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

-a или —data-only: восстанавливаем только данные.
-c или —clean: удаляем одноименные объекты перед восстановлением.
-C или —create: создаем БД перед восстановлением.
-d [name] или —dbname=[name]: подключаемся к [name] БД и восстанавливаем данные в неё.
-e или —exit-on-error: завершаем восстановление в случае ошибки.
-j [count] или —jobs=[count]: осуществляем восстановление в многопоточном режиме ([count]=количество потоков)
-n [schema] или —schema=[schema]: восстанавливаем объекты только этой схемы.
-N [schema] или —exclude-schema=[schema]: не восстанавливаем объекты этой схемы.
-O или —no-owner: не восстанавливаем права на владение объектами.
-s или —schema-only: восстанавливаем только схему
-t таблица или —table=таблица: восстанавливаем только указанную таблицу.
-x или —no-privileges или —no-acl: не восстанавливаем права доступа.

wal-g

Wal-g — это сторонняя утилита для выгрузки дампов в хранилища и восстановления БД. Её действие распространяется не только на PostgreSQL, но и на другие СУБД. Wal-g поддерживает работу с несколькими типами хранилищ. Мы сосредоточимся на работе с S3.

Загрузка и установка

Wal-g работает в linux-системах, для работы на Win 10 необходимо использовать сервисы наподобие WSL. Работа с wal-g начинается с github, где расположены файлы утилиты. На вкладке releases размещены версии для различных систем и СУБД. Для установки последней версии wal-g на Ubuntu 20.04 выполняем эти команды:

wget https://github.com/wal-g/wal-g/releases/download/v1.1/wal-g-pg-ubuntu-20.04-amd64.tar.gz
tar -zxvf wal-g-pg-ubuntu-20.04-amd64.tar.gz -C /usr/local/bin/wal-g

Настройка

Для настройки wal-g можно воспользоваться как переменными окружения, так и конфигурационным файлом. Мы создадим конфигурационный файл для хранилища S3 по такому шаблону bash:

cat > /var/lib/postgresql/.walg.json << EOF
{
"AWS_ENDPOINT": "https://s3.

timeweb.com",
"WALG_S3_PREFIX": "s3://имя_бакета",
"AWS_ACCESS_KEY_ID": "Ключ доступа к хранилищу (логин)",
"AWS_SECRET_ACCESS_KEY": "Секретный ключ",
"WALG_COMPRESSION_METHOD": "Алгоритм сжатия:brotli, LZ4 или LZMA.",
"WALG_DELTA_MAX_STEPS": "количество дельт*",
"PGDATA": "путь к данным БД",
"PGHOST": "имя хоста"
}
EOF

chown postgres: /var/lib/postgresql/.walg.json #меняем имя владельца скрипта на postgres

*Дельта-бэкап — это бэкап разницы между текущим состоянием системы и последним полным бэкапом. Такой подход позволяет экономить пространство в хранилище. Количество дельт — это количество таких бэкапов.

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

За создание бэкапов в wal-g отвечает функция backup_push. Её можно использовать прямо в консоли следующим образом:

su postgres -c ’/usr/local/bin/wal-g/wal-g backup_push *путь к данным БД или PGDATA*’

pgAdmin

pgAdmin — это утилита с графическим интерфейсом для создания дампов. Для начала работы переходим на сайт pgAdmin и загружаем подходящую версию программы:

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

Восстановление базы данных PostgreSQL

Резюме : в этом руководстве вы узнаете, как восстановить базу данных с помощью инструментов восстановления PostgreSQL, включая pg_restore и psql .

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

Использование psql для восстановления простого файла сценария SQL, созданного 9Инструменты 0007 pg_dump и pg_dumpall .
Использование pg_restore для восстановления файла tar и формата каталога, созданного инструментом pg_dump .

Как восстановить базы данных с помощью psql

Инструмент psql позволяет восстанавливать файл сценария SQL, созданный с помощью pg_dump , pg_dumpall или любых других инструментов, которые создают совместимые резервные копии файлов. Используя инструмент psql , вы можете выполнить весь сценарий в файле дампа.

Чтобы восстановить полную резервную копию и игнорировать любые ошибки, возникшие в процессе восстановления, используйте следующую команду:

 psql -U имя пользователя -f backupfile.sql  Язык кода: CSS (css)

Если вы хотите остановить при восстановлении БД в случае ошибок добавляется --set ON_ERROR_STOP=on option :

 psql -U username --set ON_ERROR_STOP=on -f backupfile  Язык кода: JavaScript (javascript)

Если вернуться объектов в определенной базе данных, вы можете восстановить их с помощью следующей команды:

 psql -U имя пользователя -d имя_базы_данных -f objects.sql  Язык кода: CSS (css)

Как восстанавливать базы данных с помощью pg_restore

Помимо инструмента psql , вы можете использовать программу pg_restore для восстановления баз данных с помощью инструментов pg_dump или pg_dumpall . Программа pg_restore предоставляет различные варианты восстановления баз данных, например:

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

Давайте создадим новую базу данных с именем newdvdrental для практики с помощью инструмента pg_restore .

 СОЗДАТЬ БАЗУ ДАННЫХ newdvdrental;  Язык кода: SQL (язык структурированных запросов) (sql)

Вы можете восстановить базу данных dvdrental в формате файла tar , сгенерированном инструментом pg_dump в руководстве по резервному копированию базы данных PostgreSQL, используя следующую команду:

 pg_restore --dbname=newdvdrental --verbose c:\pgbackup\dvdrental. tar

Если вы восстанавливаете базу данных, которая совпадает с той, для которой вы сделали резервную копию, вы можете использовать следующую команду:

 pg_restore --dbname=dvdrental --create --verbose c:\pgbackup\dvdrental.tar

Начиная с PostgreSQL 9.2, вы можете использовать параметр --section только для восстановления структуры таблицы. Это позволяет использовать новую базу данных в качестве шаблона для создания других баз данных.

Сначала создайте новую базу данных с именем dvdrental_tpl .

 СОЗДАТЬ БАЗУ ДАННЫХ dvdrental_tpl;  Язык кода: SQL (язык структурированных запросов) (sql)

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

 >pg_restore --dbname=dvdrental_tpl --section =pre-data c:\pgbackup\dvdrental.tar

Дополнительная литература

https://www.postgresql.org/docs/current/app-pgrestore. html — документация по инструменту pg_restore

Было ли это руководство полезным?

PostgreSQL: Документация: 8.0: Резервное копирование и восстановление

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

Идея метода SQL-дампа заключается в создании текстового
файл с командами SQL, которые при возврате на сервер будут
воссоздать базу данных в том же состоянии, в котором она была в то время
свалки. PostgreSQL
для этой цели предусмотрена утилита pg_dump. Основное использование
этой команды:

pg_dump имя_базы > исходящий файл

Как видите, pg_dump пишет
его результаты на стандартный вывод. Ниже мы увидим, как это
может быть полезным.

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

Чтобы указать, к какому серверу базы данных должен обращаться pg_dump, используйте команду
параметры строки -h host и -p
порт. Хост по умолчанию
локальный хост или любой другой ваш PGHOST
переменная окружения указывает. Точно так же порт по умолчанию
указывается средой PGPORT
переменная или, в противном случае, скомпилированная по умолчанию.
(Удобно, сервер обычно будет иметь один и тот же
компилируется по умолчанию.)

Как и любой другой PostgreSQL
клиентское приложение, pg_dump
по умолчанию будет подключаться с именем пользователя базы данных, которое
равно текущему имени пользователя операционной системы. Переопределить
это либо укажите параметр -U, либо
установите переменную среды PGUSER.
Помните, что pg_dump
соединения подлежат обычной аутентификации клиента
механизмы (которые описаны в главе 19).

Дампы, созданные pg_dump
внутренне непротиворечивы, то есть обновления в базе данных
во время работы pg_dump будет
не оказаться на свалке. pg_dump
не блокирует другие операции с базой данных, пока она
работающий. (Исключениями являются те операции, которые должны выполняться
с эксклюзивным замком, например ВАКУУМ
ПОЛНЫЙ.)

Важно: Когда ваша схема базы данных опирается на
OID (например, как внешние ключи), которые вы должны проинструктировать
pg_dump для сброса OID
также. Для этого используйте -o
вариант командной строки. «Большой
объекты» также не сбрасываются по умолчанию. См.
справочная страница pg_dump, если
вы используете большие предметы.

Текстовые файлы, созданные pg_dump, предназначены для чтения
программа psql.
общая форма команды для восстановления дампа

psql имя_базы_данных < infile

где infile это то что вы
используется как выходной файл для
Команда pg_dump.
база данных dbname не будет
созданный этой командой, вы должны создать его самостоятельно из
template0 перед выполнением
psql (например, с createdb -T template0 dbname). psql поддерживает параметры, подобные
pg_dump для управления
местоположение сервера базы данных и имя пользователя. См. psql
справочная страница для получения дополнительной информации.

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

После восстановления целесообразно запустить ANALYZE для каждой базы данных, чтобы
оптимизатор имеет полезную статистику. Простой способ сделать это -
запустите Vacuumdb -a -z, чтобы ВАКУУМНО ПРОАНАЛИЗИРОВАТЬ все базы данных; Это
эквивалентно запуску VACUUM ANALYZE
вручную.

Возможность pg_dump
и psql для записи или чтения
from pipe позволяет выгружать базу данных непосредственно из
одного сервера на другой; например:

pg_dump -h хост1 имя_базы_данных | psql -h host2 имя_базы_данных

Важно: Дампы, создаваемые pg_dump, относятся к template0. Это означает, что любые языки,
процедуры и т. д., добавленные в template1, также будут сброшены
pg_dump. Как результат,
при восстановлении, если вы используете настраиваемый шаблон1, необходимо создать пустой
база данных из template0, как в
пример выше.

Для получения рекомендаций по загрузке больших объемов данных в
PostgreSQL эффективно,
см. Раздел 13.4.

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

pg_dumpall > выходной файл

Полученный дамп можно восстановить с помощью psql:

psql -f входной файл шаблон1

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

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

Использовать сжатые дампы. Вы можете использовать свой любимый
программа сжатия, например gzip.

pg_dump имя_базы | gzip > имя файла.gz

Перезагрузить с помощью

createdb имя_базы_данных
gunzip -c имя_файла.gz | psql имя_базы_данных

или

кошка имя файла.gz | оружейный | psql имя_базы_данных

Использовать раздельно.
Команда split позволяет разделить
выход на куски, приемлемые по размеру для
базовая файловая система. Например, чтобы сделать куски 1
мегабайт:

pg_dump имя_базы | split -b 1m - имя файла

Перезагрузить с помощью

createdb имя_базы_данных
имя файла кота* | psql имя_базы_данных

Использовать пользовательский формат дампа. Если PostgreSQL был построен на системе с
сжатие zlib
установленная библиотека, пользовательский формат дампа будет сжимать
данные по мере их записи в выходной файл. Это произведет
размеры файла дампа аналогичны использованию gzip, но у него есть дополнительное преимущество, заключающееся в том, что
таблицы могут быть восстановлены выборочно. Следующая команда
дамп базы данных с использованием пользовательского формата дампа:

pg_dump -Fc имя базы данных > имя файла

Дамп пользовательского формата не является сценарием для psql, а вместо этого должен быть восстановлен
с pg_restore. См.
Справочные страницы pg_dump и pg_restore для
подробности.

Из соображений обратной совместимости pg_dump не создает дамп больших объектов путем
по умолчанию. Чтобы сбросить большие
объектов вы должны использовать либо пользовательский вывод, либо вывод tar
формат и используйте параметр -b в
pg_dump.