Postgresql не восстанавливает базу данных из файла резервной копии
Обновлено: 22.11.2024
Резервная копия — это копия данных из вашей базы данных, которую можно использовать для восстановления этих данных. Резервные копии — это резервные копии физических файлов, используемых для хранения и восстановления ваших баз данных, таких как файлы данных, управляющие файлы и другие. Каждая физическая резервная копия — это копия файлов, хранящих информацию базы данных, в другом месте, будь то на диске или в автономном хранилище, например на ленте.
Преимущества резервного копирования:
С действительными резервными копиями базы данных вы можете восстановить данные после многих сбоев, таких как:
- Сбой носителя. Сбой носителя – это сбой чтения или записи файла на диске, необходимого для запуска базы данных, из-за физической проблемы с диском, например, из-за поломки головки.
- Сбои оборудования, например, поврежденный диск.
- Ошибки пользователя, например, случайное удаление таблицы.
- Стихийные бедствия.
Компонент резервного копирования и восстановления сервера PostgreSQL обеспечивает необходимую защиту важных данных, хранящихся в базах данных сервера. Чтобы свести к минимуму риск потери данных, вам необходимо регулярно создавать резервные копии ваших баз данных, чтобы сохранять изменения в ваших данных. Хорошо спланированная стратегия резервного копирования и восстановления помогает защитить базы данных от потери данных. Проверьте свою стратегию, восстановив набор резервных копий, а затем восстановив базу данных.
Оглавление
Резервное копирование базы данных PostgreSQL
pg_dump — это утилита для резервного копирования базы данных PostgreSQL. Он делает согласованные резервные копии, даже если база данных используется одновременно. pg_dump не блокирует доступ других пользователей к базе данных (читателей или записывающих устройств).
Вы можете использовать программу командной строки pg_dump или использовать phpPgAdmin для резервного копирования базы данных PostgreSQL в файл.
Откройте командную строку на компьютере, где хранится база данных. Если у вас есть физический доступ к компьютеру, вы можете открыть окно DOS или терминала для доступа к командной строке.
Введите следующую команду и нажмите клавишу ВВОД. Замените USERNAME на ваше имя пользователя, а DBNAME на имя базы данных, которую вы хотите экспортировать:
Синтаксис:
Введите пароль в строке пароля.
Файл Mybackup.pgsql теперь содержит все данные для базы данных DBNAME. Если файл Mybackup.pgsql находится на удаленном компьютере, загрузите его на локальный компьютер.
Полный синтаксис и другие параметры pg_dump
Синтаксис:
Опция | Описание |
---|---|
имя_базы_данных | Имя базы данных для дампа. td> |
-a --data-only | Выгружать только данные (табличные данные, большие объекты и значения последовательности), а не схему ( определения данных) Эта опция аналогична, но по историческим причинам не идентична указанию --section=data. |
-b -- blobs | Включить в дамп большие объекты (поведение по умолчанию). |
-c --clean | Вывод команды для очистки (удаления) объектов базы данных перед выводом команд для их создания. Эта опция имеет смысл только для текстового формата. |
-C --create | Начните вывод с команда для создания самой базы данных и повторного подключения к созданной базе данных. Эта опция имеет значение только для обычного текстового формата. |
-E encoding --encoding=encoding | Создать дамп в указанной кодировке набора символов (по умолчанию, кодировка базы данных). |
-f файл --file=file | Отправить вывод в указанный файл. |
-F format --format=format | Выбирает формат вывода. Формат может быть одним из следующих: p plain: вывод файла сценария SQL в виде обычного текста (по умолчанию). c custom : Вывод архива пользовательского формата, пригодного для ввода в pg_restore. каталог d : вывод архива в формате каталога, подходящего для ввода в pg_restore. t tar : выводит архив в формате tar, подходящий для ввода в pg_restore. |
-j njobs --jobs =njobs | Выполнить дамп параллельно, одновременно выгружая таблицы njobs. |
-n schema --schema=schema | Дамп только схем, соответствующих схеме; это выбирает как саму схему, так и все содержащиеся в ней объекты. Если этот параметр не указан, все несистемные схемы в целевой базе данных будут выгружены. |
-N schema --exclude-schema=schema td> | Не сбрасывайте никакие схемы, соответствующие шаблону схемы. Если заданы и -n, и -N, дамп выполняется только для тех схем, которые соответствуют хотя бы одному параметру -n, но не соответствуют параметру -N. Если -N появляется без -n, то схемы, соответствующие -N, исключаются из обычного дампа. |
-o --oids | Идентификаторы объектов дампа (OID) как часть данных для каждой таблицы. |
-O --no-owner | Не выводить команды для установки прав собственности на объекты в соответствии с исходной базой данных. Эта опция имеет значение только для обычного текстового формата. Для форматов архива можно указать параметр при вызове pg_restore. |
-R --no-reconnect | Этот параметр устарела, но все еще принимается для обратной совместимости. |
-s --schema-only | Выводить только определения объектов (схему), а не data. |
-S username --superuser=username | Укажите имя суперпользователя, которое будет использоваться при отключении триггеров. Это имеет значение, только если используется --disable-triggers. |
-t table --table=table | Дамп только таблиц ( или представления, или последовательности, или сторонние таблицы) соответствующая таблица. Можно выбрать несколько таблиц, написав несколько ключей -t. |
-T table --exclude-table=table | Не создавать дамп любые таблицы, соответствующие шаблону таблицы. Если заданы и -t, и -T, дамп выполняется только для тех таблиц, которые соответствуют хотя бы одному ключу -t, но не соответствуют ключу -T. |
-v --verbose | Указывает подробный режим. Это приведет к тому, что pg_dump выведет подробные комментарии к объекту и время начала/остановки в файл дампа, а также сообщения о ходе выполнения со стандартной ошибкой. |
-V --version< /td> | Распечатайте версию pg_dump и выйдите. |
-x --no-привилегии --no-acl | Предотвратить сброс привилегий доступа (команды предоставления/отзыва). |
-Z 0..9 --compress=0..9 td> | Укажите используемый уровень сжатия. Ноль означает отсутствие сжатия. |
--binary-upgrade | Эта опция предназначена для использования утилитами обновления на месте. |
--column-inserts --attribute-inserts | Выгружать данные в виде команд INSERT с явными именами столбцов (INSERT INTO table (column, . ) VALUES . ). Это сделает восстановление очень медленным; это в основном полезно для создания дампов, которые могут быть загружены в базы данных, отличные от PostgreSQL. |
--disable-dollar-quoting | Эта опция отключает использование долларовых кавычек для тел функций и заставляет их заключать в кавычки с использованием стандартного синтаксиса строк SQL. |
--disable-triggers | Эта опция актуальна только при создании дампа только данных. Эта опция имеет значение только для обычного текстового формата. Для форматов архива вы можете указать опцию при вызове pg_restore. |
--exclude-table-data=table | Эта опция полезна, когда вам нужно определение конкретной таблицы, даже если вам не нужны данные в ней. Чтобы исключить данные для всех таблиц в базе данных, см. --schema-only. |
--if-exists | Используйте условные команды (т.е. добавить предложение IF EXISTS) при очистке объектов базы данных. Эта опция недействительна, если не указан параметр --clean. |
--inserts | Выгружать данные как команды INSERT (а не COPY). td> |
--lock-wait-timeout=timeout | Не ждите целую вечность, чтобы получить общие блокировки таблиц в начале дампа. | tr>
--no-security-labels | Не сбрасывать метки безопасности. |
--no-synchronized-snapshots< /td> | Эта опция позволяет запускать pg_dump -j на сервере до версии 9.2, дополнительные сведения см. в документации по параметру -j. |
--no- tablespaces | Не выводить команды для выбора табличных пространств. С этой опцией все объекты будут созданы в любом табличном пространстве, используемом по умолчанию во время восстановления. Эта опция имеет значение только для обычного текстового формата. Для форматов архива вы можете указать опцию при вызове pg_restore. |
--no-unlogged-table-data | Не выгружать содержимое незарегистрированных таблиц. |
--quote-all-identifiers | Принудительно заключать в кавычки все идентификаторы. Это может быть полезно при создании дампа базы данных для переноса на будущую версию, в которой могут быть введены дополнительные ключевые слова. |
--section = sectionname | Дампировать только именованный раздел (по умолчанию дамп всех разделов). |
--serializable-deferrable | Используйте сериализуемую транзакцию для дампа, чтобы убедиться, что моментальный снимок used согласуется с более поздними состояниями базы данных. Этот вариант не подходит для дампа, предназначенного только для аварийного восстановления. |
--use-set-session-authorization | Выводить стандартные для SQL команды SET SESSION AUTHORIZATION вместо команд ALTER OWNER для определения принадлежности объекта. |
-? --help | Показать справку об аргументах командной строки pg_dump и выйти. |
Следующие параметры командной строки управляют параметрами подключения к базе данных
Опция | Описание |
---|---|
-d dbname --dbname=dbname | Указывает имя базы данных для подключения. |
-h host --host=host | Указывает имя хоста машины, на которой работает сервер. |
-p port --port=port | Указывает TCP-порт или расширение файла сокета локального домена Unix, на котором сервер прослушивает подключения ( по умолчанию используется переменная среды PGPORT). |
-U имя пользователя --username=имя пользователя | Имя пользователя. | tr>
-w --no-password | Никогда не запрашивать пароль. |
-W --password | Заставить pg_dump запрашивать пароль перед подключением к базе данных. Этот параметр никогда не является обязательным, так как pg_dump автоматически запросит пароль, если сервер потребует аутентификации по паролю. |
--role=rolename | Указывает имя роли, которое будет использоваться для создания дампа. |
Восстановить базу данных PostgreSQL
Текстовые файлы, созданные pg_dump, предназначены для чтения программой psql. Введите следующую команду и нажмите клавишу ВВОД. Замените USERNAME на ваше имя пользователя и DBNAME на имя базы данных, в которую вы хотите восстановить данные
Синтаксис:
где Mybackup.pgsql — это файл, выводимый командой pg_dump. Эта команда не будет создавать базу данных dbname, поэтому вы должны создать ее самостоятельно из template0 перед выполнением psql (например, с помощью createdb -T template0 dbname). psql поддерживает параметры, аналогичные pg_dump, для указания сервера базы данных для подключения и используемого имени пользователя. Дампы нетекстовых файлов восстанавливаются с помощью утилиты pg_restore.
Примечание. Перед восстановлением дампа SQL все пользователи, владеющие объектами или получившие права доступа к объектам в базе данных дампа, должны уже существовать. В противном случае при восстановлении не удастся воссоздать объекты с первоначальным владельцем и/или разрешениями.
pg_restore — это утилита для восстановления базы данных PostgreSQL из архива, созданного с помощью pg_dump, в одном из форматов, отличных от простого текста.
pg_restore может работать в двух режимах. Если указано имя базы данных, pg_restore подключается к этой базе данных и восстанавливает содержимое архива непосредственно в базу данных. В противном случае сценарий, содержащий команды SQL, необходимые для перестроения базы данных, создается и записывается в файл или в стандартный вывод. Этот вывод скрипта эквивалентен формату вывода обычного текста pg_dump. Таким образом, некоторые параметры, управляющие выводом, аналогичны параметрам pg_dump.
Синтаксис:
pg_restore принимает в таблицу следующие аргументы командной строки.
Параметры | Описание |
---|---|
имя файла | Расположение файла архива (или директория, для архив в формате каталога) для восстановления. Если не указано, используется стандартный ввод. |
-a --data-only | Восстановить только данные, а не схему (определения данных). Эта опция аналогична, но по историческим причинам не идентична указанию --section=data. |
-c --clean td> | Очистить (удалить) объекты базы данных перед их воссозданием. |
-C --create | Создать базу данных перед восстановлением внутрь. Если также указано --clean, удалите и заново создайте целевую базу данных перед подключением к ней. При использовании этого параметра база данных с параметром -d используется только для выполнения начальных команд DROP DATABASE и CREATE DATABASE. Все данные восстанавливаются в имя базы данных, которое появляется в архиве. |
-d dbname --dbname=dbname | Подключение к базе данных dbname и восстановить непосредственно в базу данных. |
-e --exit-on-error | Выйти, если при отправке возникла ошибка SQL-команды к базе данных. По умолчанию следует продолжить и отобразить количество ошибок в конце восстановления. |
-f имя_файла --file=имя_файла | < td>Укажите выходной файл для сгенерированного скрипта или для листинга при использовании с -l. По умолчанию используется стандартный вывод. |
-F format --format=format | Укажите формат архива. Нет необходимости указывать формат, так как pg_restore определит формат автоматически. Если указано, может быть одним из следующих: c custom : Архив имеет пользовательский формат pg_dump. каталог d: Архив является архивом каталога. t tar : Архив представляет собой архив tar. |
-I index --index=index | Восстановить определение только именованный индекс. |
-j количество заданий --jobs=число заданий | Выполнять больше всего времени- использование частей pg_restore — тех, которые загружают данные, создают индексы или создают ограничения — с использованием нескольких параллельных заданий. Этот параметр может значительно сократить время восстановления большой базы данных на сервер, работающий на многопроцессорной машине. |
-l --list td> | Перечислите содержимое архива. |
-L list-file --use-list=list-file | Восстанавливать только те элементы архива, которые перечислены в list- файл и восстановить их в том порядке, в котором они появляются в файле. файл-список обычно создается путем редактирования вывода предыдущей операции -l. Строки можно перемещать или удалять, а также можно закомментировать, поставив точку с запятой (;) в начале строки. |
-n namespace -- schema=schema | Восстановить только объекты, находящиеся в именованной схеме. Это можно комбинировать с опцией -t для восстановления только определенной таблицы. |
-O --no-owner | Не команды вывода, чтобы установить право собственности на объекты в соответствии с исходной базой данных. По умолчанию pg_restore выдает операторы ALTER OWNER или SET SESSION AUTHORIZATION, чтобы установить владельца созданных элементов схемы. |
-P имя-функции(argtype [, . ]) --function=function-name(argtype [, . ]) | Восстановить только названную функцию. |
-R --no -reconnect | Эта опция устарела, но по-прежнему принимается для обратной совместимости. |
-s --schema-only | < td>Восстановить только схему (определения данных), а не данные, в той степени, в которой записи схемы присутствуют в архиве. |
-S username --superuser=username | Указать имя суперпользователя, используемое при отключении триггеров. Это имеет значение, только если используется --disable-triggers. |
-t table --table=table | Восстановить определение и/ или данные только именованной таблицы. Это можно комбинировать с параметром -n для указания схемы. |
-T trigger --trigger=trigger | Восстановить только именованный триггер. |
-v --verbose | Указывает подробный режим. |
-V --version | Распечатать версию pg_dump и выйти. |
-x --no -привилегии --no-acl | Запретить восстановление прав доступа (команды предоставления/отзыва). |
-1 --single-transaction | Выполнить восстановление как единую транзакцию. |
--disable-triggers | Этот параметр актуально при выполнении восстановления только данных. |
--no-data-for-failed-tables | По умолчанию данные таблицы восстанавливаются, даже если команда создания для таблица не удалась (например, потому что она уже существует). С этой опцией данные для такой таблицы пропускаются. Такое поведение полезно, если целевая база данных уже содержит требуемое содержимое таблицы. Эта опция эффективна только при восстановлении непосредственно в базу данных, а не при создании выходных данных сценария SQL. |
--no-security-labels | Не выводить команды для восстановления меток безопасности, даже если они есть в архиве. |
--no-tablespaces | Не выводить команды для выбора табличных пространств . С этой опцией все объекты будут созданы в любом табличном пространстве, используемом по умолчанию во время восстановления. |
--section=sectionname | Восстанавливать только именованный раздел. |
--use-set-session-authorization | Выводить стандартные для SQL команды SET SESSION AUTHORIZATION вместо команд ALTER OWNER для определения принадлежности объекта. тд> | Показать справку об аргументах командной строки pg_restore и выйти. |
Следующие параметры командной строки управляют параметрами подключения к базе данных
Как и все, что содержит ценные данные, базы данных PostgreSQL следует регулярно создавать резервные копии. Хотя процедура по существу проста, важно иметь общее представление о лежащих в ее основе методах и предположениях.
Существует три принципиально разных подхода к резервному копированию данных PostgreSQL:
Резервное копирование на уровне файловой системы
У каждого есть свои сильные и слабые стороны.
Идея метода SQL-dump заключается в создании текстового файла с командами SQL, которые при отправке обратно на сервер воссоздают базу данных в том же состоянии, в каком она была во время создания дампа. PostgreSQL предоставляет для этой цели служебную программу pg_dump. Основное использование этой команды:
Как видите, pg_dump записывает результаты в стандартный вывод. Ниже мы увидим, как это может быть полезно.
pg_dump — это обычное клиентское приложение PostgreSQL (хотя и очень умное). Это означает, что вы можете выполнить эту процедуру резервного копирования с любого удаленного хоста, имеющего доступ к базе данных. Но помните, что pg_dump не работает со специальными разрешениями. В частности, у него должен быть доступ для чтения ко всем таблицам, резервные копии которых вы хотите создать, поэтому на практике вам почти всегда приходится запускать его от имени суперпользователя базы данных.
Чтобы указать, к какому серверу базы данных должен обращаться pg_dump, используйте параметры командной строки -h хост и -p порт тт>.Хост по умолчанию — это локальный хост или любой другой, указанный в переменной среды PGHOST. Точно так же порт по умолчанию указывается переменной среды PGPORT или, в противном случае, скомпилированным значением по умолчанию. (Для удобства сервер обычно будет иметь такое же скомпилированное значение по умолчанию.)
Как и любое другое клиентское приложение PostgreSQL, pg_dump по умолчанию подключается к базе данных с именем пользователя, совпадающим с текущим именем пользователя операционной системы. Чтобы переопределить это, либо укажите параметр -U, либо задайте переменную среды PGUSER. Помните, что на соединения pg_dump распространяются обычные механизмы аутентификации клиента (описанные в главе 20).
Дампы, созданные pg_dump, внутренне непротиворечивы, то есть обновления базы данных во время работы pg_dump не будут в дампе. pg_dump не блокирует другие операции с базой данных во время работы. (Исключениями являются операции, требующие монопольной блокировки, такие как VACUUM FULL.)
Важно: если схема вашей базы данных зависит от OID (например, от внешних ключей), вы должны указать pg_dump, чтобы он также сбрасывал OID. Для этого используйте параметр командной строки -o.
23.1.1. Восстановление дампа
Текстовые файлы, созданные pg_dump, предназначены для чтения программой psql. Общая форма команды для восстановления дампа:
где infile — это то, что вы использовали в качестве outfile для команды pg_dump. База данных dbname не будет создана этой командой, вы должны создать ее самостоятельно из template0 перед выполнением psql (например, с помощью createdb -T template0 dbname ). psql поддерживает параметры, аналогичные pg_dump, для управления расположением сервера базы данных и именем пользователя. Дополнительную информацию см. на справочной странице psql.
Перед запуском восстановления должна уже существовать не только целевая база данных, но и все пользователи, которым принадлежат объекты в созданной базе данных или которым предоставлены разрешения на доступ к этим объектам. В противном случае при восстановлении не удастся воссоздать объекты с первоначальным владельцем и/или разрешениями. (Иногда это то, что вам нужно, но обычно это не так.)
После восстановления целесообразно запустить ANALYZE для каждой базы данных, чтобы оптимизатор получил полезную статистику. Простой способ сделать это — запустить vacuumdb -a -z для VACUUM ANALYZE всех баз данных; это эквивалентно запуску VACUUM ANALYZE вручную.
Способность pg_dump и psql записывать в каналы или читать из них позволяет создавать дамп базы данных непосредственно с одного сервера на другой; например:
Важно: Дампы, создаваемые pg_dump, относятся к template0. Это означает, что любые языки, процедуры и т. д., добавленные в template1, также будут выгружены pg_dump. В результате при восстановлении, если вы используете настроенный template1, вы должны создать пустую базу данных из template0, как в примере выше.
цитата>Чтобы узнать, как эффективно загружать большие объемы данных в PostgreSQL, обратитесь к Разделу 13.4.
23.1.2. Использование pg_dumpall
Описанный выше механизм громоздкий и неуместный при резервном копировании всего кластера базы данных. По этой причине предусмотрена программа pg_dumpall. pg_dumpall создает резервную копию каждой базы данных в данном кластере, а также сохраняет данные всего кластера, такие как пользователи и группы. Основное использование этой команды:
Полученный дамп можно восстановить с помощью psql :
(На самом деле вы можете указать имя любой существующей базы данных для начала, но если вы перезагружаетесь в пустой кластер, то обычно следует использовать postgres.) Всегда необходимо иметь доступ суперпользователя к базе данных при восстановлении дампа pg_dumpall, так как это необходимо для восстановления информации о пользователе и группе.
23.1.3. Работа с большими базами данных
Поскольку PostgreSQL позволяет использовать таблицы большего размера, чем максимальный размер файла в вашей системе, может быть проблематично записать дамп такой таблицы в файл, поскольку результирующий файл, скорее всего, будет больше, чем максимальный размер, разрешенный вашей системой. Поскольку pg_dump может записывать в стандартный вывод, вы можете просто использовать стандартные инструменты Unix, чтобы обойти эту возможную проблему.
Используйте сжатые дампы. Вы можете использовать свою любимую программу сжатия, например gzip .
Используйте разделить. Команда split позволяет разделить вывод на части, размер которых приемлем для базовой файловой системы. Например, чтобы сделать куски по 1 мегабайту:
Используйте пользовательский формат дампа. Если PostgreSQL был собран в системе с установленной библиотекой сжатия zlib, пользовательский формат дампа будет сжимать данные при их записи в выходной файл. Это создаст размер файла дампа, аналогичный использованию gzip, но имеет дополнительное преимущество, заключающееся в том, что таблицы можно восстанавливать выборочно.Следующая команда создает дамп базы данных, используя пользовательский формат дампа:
Дамп пользовательского формата не является сценарием для psql , вместо этого его необходимо восстановить с помощью pg_restore . Дополнительные сведения см. на справочных страницах pg_dump и pg_restore.
При работе над разными проектами и в разных средах нам часто приходится экспортировать дамп из одной базы данных, а затем импортировать его в другую. Некоторое время назад Slobodan написал, как экспортировать и импортировать дамп mySQL, и вот руководство, как сделать резервную копию и восстановить базу данных PostgreSQL.
Экспорт дампа базы данных PostgreSQL
Чтобы экспортировать базу данных PostgreSQL, нам потребуется инструмент pg_dump, который выгрузит все содержимое выбранной базы данных в один файл.
Нам нужно запустить pg_dump в командной строке на компьютере, где хранится база данных. Таким образом, если база данных хранится на удаленном сервере, вам потребуется подключиться к этому серверу по SSH, чтобы выполнить следующую команду:Здесь мы использовали следующие параметры:
- -U, чтобы указать, какой пользователь будет подключаться к серверу базы данных PostgreSQL.
- -W или --password заставит pg_dump запрашивать пароль перед подключением к серверу.
- -F используется для указания формата выходного файла, который может быть одним из следующих:
Форматы
- p — простой текстовый SQL-скрипт
- c — архив пользовательского формата
- d – архив в формате каталога
- t – архив в формате tar
custom, каталог и tar подходят для ввода в pg_restore.
Чтобы просмотреть список всех доступных параметров, используйте pg_dump -? .
С заданными параметрами pg_dump сначала запросит пароль для пользователя базы данных db_user, а затем подключится от имени этого пользователя к базе данных с именем db_name. После успешного подключения > запишет вывод, созданный pg_dump, в файл с заданным именем, в данном случае dump_name.tar .
Файл, созданный в этом процессе, содержит все SQL-запросы, необходимые для репликации вашей базы данных.
Импорт дампа базы данных PostgreSQL
Есть два способа восстановить базу данных PostgreSQL:
- psql для восстановления из простого файла сценария SQL, созданного с помощью pg_dump,
- pg_restore для восстановления из файла .tar, каталога или пользовательского формата, созданного с помощью pg_dump.
1. Восстановить базу данных с помощью psql
Если ваша резервная копия представляет собой обычный текстовый файл, содержащий скрипт SQL, вы можете восстановить базу данных с помощью интерактивного терминала PostgreSQL и выполнив следующую команду:
где db_user — пользователь базы данных, db_name — имя базы данных, а dump_name.sql — имя вашего файла резервной копии.
2. Восстановите базу данных с помощью pg_restore
Если при создании файла резервной копии вы выберете пользовательский формат, формат каталога или архива, вам потребуется использовать pg_restore для восстановления базы данных:
Если вы используете pg_restore, вам доступны различные варианты, например:
- -c, чтобы удалить объекты базы данных перед их повторным созданием,
- -C для создания базы данных перед восстановлением в нее,
- -e выйти, если произошла ошибка,
- -F формат, чтобы указать формат архива.
Использовать pg_restore -? чтобы получить полный список доступных опций.
Дополнительную информацию об использовании упомянутых инструментов можно найти, запустив man pg_dump , man psql и man pg_restore .
В производственной среде, независимо от того, насколько велика или мала ваша база данных PostgreSQL, регулярный возврат является важным аспектом управления базой данных. В этой статье вы узнаете, как сделать резервную копию и восстановить базу данных PostgreSQL.
Мы предполагаем, что у вас уже есть рабочая установка системы баз данных PostgreSQL. Если нет, прочитайте наши следующие статьи, чтобы установить PostgreSQL в вашем дистрибутиве Linux.
Приступим…
Резервное копирование одной базы данных PostgreSQL
PostgreSQL предоставляет утилиту pg_dump, помогающую создавать резервные копии баз данных. Он создает файл базы данных с командами SQL в формате, который можно легко восстановить в будущем.
Для резервного копирования базы данных PostgreSQL сначала войдите на сервер базы данных, затем переключитесь на учетную запись пользователя Postgres и запустите pg_dump следующим образом (замените tecmintdb на имя базы данных, резервную копию которой вы хотите создать). По умолчанию выходным форматом является простой текстовый файл сценария SQL.
pg_dump поддерживает и другие выходные форматы. Вы можете указать выходной формат с помощью параметра -F, где c означает файл архива пользовательского формата, d означает архив формата каталога, а t означает файл архива формата tar: все форматы подходят для ввода в pg_restore.
Чтобы вывести выходные данные в формате вывода каталога, используйте флаг -f (который используется для указания выходного файла), чтобы указать целевой каталог вместо файла. Каталог, который будет создан pg_dump, не должен существовать.
Для резервного копирования всех баз данных PostgreSQL используйте инструмент pg_dumpall, как показано ниже.
Вы можете восстановить дамп с помощью psql, как показано ниже.
Восстановление базы данных PostgreSQL
Для восстановления базы данных PostgreSQL можно использовать утилиты psql или pg_restore. psql используется для восстановления текстовых файлов, созданных pg_dump, тогда как pg_restore используется для восстановления базы данных PostgreSQL из архива, созданного pg_dump, в одном из форматов, отличных от простого текста (пользовательский, tar или каталог).
Вот пример того, как восстановить дамп обычного текстового файла:
Как упоминалось выше, дамп пользовательского формата не является сценарием для pgsql, поэтому его необходимо восстановить с помощью pg_restore, как показано.
Резервное копирование больших баз данных PostgreSQL
Если база данных, которую вы создаете резервную копию, велика и вы хотите создать выходной файл довольно меньшего размера, вы можете запустить сжатый дамп, в котором вы должны отфильтровать вывод pg_dump с помощью инструмента сжатия, такого как gzip, или любой из ваших избранное:
Если база данных очень велика, вы можете создать дамп параллельно, одновременно выгружая таблицы number_of_jobs с помощью флага -j, как показано ниже.
Важно отметить, что параметр параллельного дампа сокращает время создания дампа, но, с другой стороны, также увеличивает нагрузку на сервер базы данных.
Резервное копирование удаленных баз данных PostgreSQL
pg_dump — это обычный клиентский инструмент PostgreSQL, он поддерживает операции на удаленных серверах баз данных. Чтобы указать удаленный сервер базы данных, с которым pg_dump должен связаться, используйте параметры командной строки -h для указания удаленного хоста, а -p указывает удаленный порт, который прослушивает сервер базы данных. Кроме того, используйте флаг -U, чтобы указать имя роли базы данных для подключения.
Не забудьте заменить 10.10.20.10 и 5432 и tecmintdb IP-адресом или именем вашего удаленного хоста, портом базы данных и именем базы данных соответственно.
Убедитесь, что пользователь, подключающийся удаленно, имеет необходимые привилегии для доступа к базе данных, а на сервере базы данных настроен соответствующий метод аутентификации базы данных, в противном случае вы получите сообщение об ошибке, подобное показанному на следующем снимке экрана.
Также можно создать дамп базы данных напрямую с одного сервера на другой, используя утилиты pg_dump и psql, как показано ниже.
Автоматическое резервное копирование базы данных PostgreSQL с помощью задания Cron
Вы можете выполнять резервное копирование через регулярные промежутки времени, используя задания cron. Задания Cron часто используются для планирования выполнения различных задач на сервере.
Вы можете настроить задание cron для автоматического резервного копирования базы данных PostgreSQL следующим образом. Обратите внимание, что вам необходимо выполнить следующие команды от имени суперпользователя PostgreSQL:
Затем выполните следующую команду, чтобы отредактировать crontab и добавить новое задание cron.
Скопируйте и вставьте следующую строку в конец crontab. Вы можете использовать любой из описанных выше форматов дампа.
Сохраните файл и выйдите.
Служба cron автоматически запустит это новое задание без перезапуска. И это задание cron будет запускаться каждый день в полночь, это минимальное решение задачи резервного копирования.
Дополнительную информацию о планировании заданий cron см. в статье Создание заданий Cron и управление ими в Linux
Пока все! Рекомендуется сделать резервное копирование данных частью вашей процедуры управления базой данных. Чтобы связаться с нами по любым вопросам или комментариям, используйте форму обратной связи ниже. Дополнительные сведения см. на справочных страницах pg_dump и pg_restore.
Если вам понравилась эта статья, подпишитесь на уведомления по электронной почте о руководствах по Linux. Если у вас есть вопросы или сомнения? обратитесь за помощью в разделе комментариев.
Если вы цените то, что мы делаем здесь, в TecMint, вам следует подумать о следующем:
TecMint – это самый быстрорастущий и пользующийся наибольшим доверием сайт сообщества, где можно найти любые статьи, руководства и книги по Linux в Интернете. Миллионы людей посещают TecMint! для поиска или просмотра тысяч опубликованных статей, доступных всем БЕСПЛАТНО.
Если вам нравится то, что вы читаете, купите нам кофе (или 2) в знак признательности.
Читайте также: