Бэкап базы данных postgresql: PostgreSQL : Документация: 9.6: Глава 25. Резервное копирование и восстановление : Компания Postgres Professional

PostgreSQL : Документация: 9.6: 25.2. Резервное копирование на уровне файлов : Компания Postgres Professional

RU

EN

RU EN

Альтернативной стратегией резервного копирования является непосредственное копирование файлов, в которых PostgreSQL хранит содержимое базы данных; в Разделе 18.2 рассказывается, где находятся эти файлы. Вы можете использовать любой способ копирования файлов по желанию, например:

tar -cf backup.tar /usr/local/pgsql/data

Однако существуют два ограничения, которые делают этот метод непрактичным или как минимум менее предпочтительным по сравнению с pg_dump:

1. Чтобы полученная резервная копия была годной, сервер баз данных должен быть остановлен. Такие полумеры, как запрещение всех подключений к серверу, работать не будут (отчасти потому что tar и подобные средства не получают мгновенный снимок состояния файловой системы, но ещё и потому, что в сервере есть внутренние буферы). Узнать о том, как остановить сервер, можно в Разделе 18.5. Необходимо отметить, что сервер нужно будет остановить и перед восстановлением данных.

2. Если вы ознакомились с внутренней организацией базы данных в файловой системе, у вас может возникнуть соблазн скопировать или восстановить только отдельные таблицы или базы данных в соответствующих файлах или каталогах. Это не будет работать, потому что информацию, содержащуюся в этих файлах, нельзя использовать без файлов журналов транзакций, pg_clog/*, которые содержат состояние всех транзакций. Без этих данных файлы таблиц непригодны к использованию. Разумеется также невозможно восстановить только одну таблицу и соответствующие данные pg_clog, потому что в результате нерабочими станут все другие таблицы в кластере баз данных. Таким образом, копирование на уровне файловой системы будет работать, только если выполняется полное копирование и восстановление всего кластера баз данных.

Ещё один подход к резервному копированию файловой системы заключается в создании «целостного снимка» каталога с данными, если это поддерживает файловая система (и вы склонны считать, что эта функциональность реализована корректно). Типичная процедура включает создание «замороженного снимка» тома, содержащего базу данных, затем копирование всего каталога с данными (а не его избранных частей, см. выше) из этого снимка на устройство резервного копирования, и наконец освобождение замороженного снимка. При этом сервер базы данных может не прекращать свою работу. Однако резервная копия, созданная таким способом, содержит файлы базы данных в таком состоянии, как если бы сервер баз данных не был остановлен штатным образом; таким образом, когда вы запустите сервер баз данных с сохранёнными данными, он будет считать, что до этого процесс сервера был прерван аварийно, и будет накатывать журнал WAL. Это не проблема, просто имейте это в виду (и обязательно включите файлы WAL в резервную копию). Чтобы сократить время восстановления, можно выполнить команду CHECKPOINT перед созданием снимка.

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

Если одновременные снимки невозможны, остаётся вариант с остановкой сервера баз данных на время, достаточное для получения всех замороженных снимков. Другое возможное решение — получить базовую копию путём непрерывного архивирования (см. Подраздел 25.3.2), такие резервные копии не могут пострадать от изменений файловой системы в процессе резервного копирования. Для этого требуется включить непрерывное архивирование только на время резервного копирования; для восстановления применяется процедура восстановления из непрерывного архива (Подраздел 25.3.4).

Ещё один вариант — копировать содержимое файловой системы с помощью rsync. Для этого rsync запускается сначала во время работы сервера баз данных, а затем сервер останавливается на время, достаточное для запуска rsync --checksum. (Ключ --checksum необходим, потому что rsync различает время только с точностью до секунд.) Во второй раз rsync отработает быстрее, чем в первый, потому что скопировать надо будет относительно немного данных; и в итоге будет получен согласованный результат, так как сервер был остановлен. Данный метод позволяет получить копию на уровне файловой системы с минимальным временем простоя.

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

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

Резервное копирование PostgreSQL необходимая процедура для обеспечения сохранности важных данных.
Effector Saver — удобное и надежное решение для защиты баз данных PostgreSQL. Программа позволяет автоматически выполнять бэкап неограниченного количества баз данных.

Как сделать автоматический бэкап PostgreSQL с помощью Effector Saver?

Откройте Effector Saver и создайте новую задачу. В главном окне «Задачи» — «Добавить задачу».

Выберите тип новой задачи — «Резервное копирование файлов и баз данных».

На первой вкладке «Основные параметры» установите флаг «Включить в архив бэкап базы SQL» ниже в выпадающем списке выберите «PostgreSQL».

Переключитесь на вкладку «База PostgreSQL».

В поле «Сервер:» укажите имя SQL-сервера.
В поле «Порт:» укажите порт подключения к SQL-серверу, по умолчанию 5432.
В поле «Пользователь:» укажите пользователь для подключения к серверу SQL, по умолчанию postgres.
В поле «Пароль:» укажите пароль пользователя к серверу SQL.
В поле «База:» выберите базу данных SQL-сервера которую необходимо сохранить. Доступные базы отображаются в выпадающем списке.

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

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

• custom archive
• tar archive
• plain-text SQL script

Если нужно в поле «Опции:» введите опции, дополнительные сведения см. в документации к утилите pg_dump.exe, ключ -F format.
В поле «pg_dump» укажите путь к утилите pg_dump.exe, утилита входит в состав сервера PostgreSQL и расположена в каталоге bin установленного сервера PostgreSQL.

Переключитесь на вкладку «Хранилище архива» и выберите необходимое хранилище для архива PostgreSQL. Предположим, что вам необходимо сохранять архив базы SQL в облачном хранилище Google Диск. Для этого нажмите кнопку и выберите «Создать новое хранилище» — «Google Диск».

Нажмите на кнопку «Авторизация».

Войдите в ваш аккаунт и разрешите работу Effector Saver с хранилищем Google Диск.

После, увидим сообщение «Все в порядке! Теперь Вы можете вернуться в Effector Saver.».

Далее, нажмите кнопку и выберите подходящую папку для вашего архива.

Обратите внимание: Effector Saver имеет доступ только к тем файлам и папкам Google Диска, которые были созданы в программе. Доступ к другим данным пользователя на Google Диске у Effector Saver отсутствует.

Проведите тест подключения. Нажмите на кнопку «Тест», программа проверит успешность соединения с облаком Google Диск.

Установите флаг «Автоматически удалять устаревшие резервные копии», и заполните параметр «Хранить количество копий».

Переключитесь на вкладку «Файл архива».
В разделе «Правило формирования имени архива» задайте имя вашего архива.
В разделе «Архивирование» задайте параметры сжатия и шифрования.

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

Переключитесь на вкладку «Расписание автозапуска» для автоматического бэкапа PostgreSQL установите флаг «Запускать по расписанию», и задайте расписание. Установите периодичность и время задачи бэкапа. Нажмите «Сохранить».

На этом создание задачи завершено. Резервное копирование PostgreSQL будет осуществляться Effector Saver автоматически в соответствии с заданным расписанием.

Рекомендация: после завершения задачи, восстановите созданный бэкап, чтобы убедиться, что восстановление в дальнейшем будут работать.
О том как восстановить базу PostgreSQL из полученного бэкапа вы можете узнать в материале: «Как восстановить данные PostgreSQL из резервной копии».

Другие базы данных:

Почему вам нужно делать резервную копию вашей базы данных Postgres и как это сделать

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

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

Зачем необходимо резервное копирование баз данных

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

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

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

Однако сделать резервную копию базы данных не так просто, как подключить жесткий диск и перенести все ваши данные.

Что, где и как создавать резервные копии базы данных

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

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

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

Обязанности администратора баз данных

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

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

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

О чем следует помнить

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

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

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

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

В PostgreSQL у вас есть утилита под названием pg_dump , которые могут выполнять резервное копирование. Чтобы создать резервную копию базы данных в текстовом файле SQL, просто войдите на сервер базы данных. Затем переключитесь на учетную запись Postgres и выполните команду.

pg_dump имя_базы_данных > имя_файла.sql

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

Для файлов любого другого типа можно использовать спецификатор формата -F . Если вам нужно, чтобы резервная копия сохранялась в виде пользовательского файла архива, добавьте -F c перед именем базы данных. Для каталога или архива в формате tar используйте алфавит d и t соответственно. pg_restore может восстанавливать резервные копии баз данных в любом формате. Таким образом, это не должно быть проблемой, когда вы решаете, какой формат использовать.

 pg_dump -F c имя_базы_данных > имя_файла.dump
pg_dump -F t имя_базы_данных > имя_файла.tar 

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

pg_dump -F d имя_базы_данных -f каталог

pg_dump может создавать дамп только одной базы данных. Но не слишком ли утомительно запускать такие команды для каждой из ваших баз данных? Если вы хотите мгновенно создать их резервные копии, используйте инструмент pg_dumpall .

pg_dumpall > alldbdump.sql

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

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

Если вы сделали резервную копию в текстовом файле, утилита plsql может восстановить эти файлы.

plsql имя_базы_данных < имя_файла.sql

pg_restore может восстанавливать резервные копии файлов в пользовательском формате, формате каталога или формате tar.

 pg_restore -d имя_базы_данных имя_файла.dump
pg_restore -d имя_базы_данных имя_файла.tar
pg_restore -d имя_базы_данных каталог_дампов 

pg_restore имеет несколько других аргументов командной строки, которые можно использовать для указания определенных операций. Например, -a восстанавливает только данные, а не их определения. Аналогично, -c удаляет объекты базы данных перед их новым созданием, и вы можете использовать -t для восстановления определенной таблицы.

Вы можете проверить все аргументы командной строки здесь.

Резервное копирование больших баз данных

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

Pg_dump имя_базы_данных | gzip > dumpname.gz

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

pg_dump -F d -j 5 -f каталог дампа

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

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

Инструмент pg_dump в PostgreSQL упрощает резервное копирование удаленных серверов баз данных с помощью параметров командной строки. Все, что вам нужно сделать, это использовать -h и -p, чтобы указать удаленный хост и удаленный порт, на котором работает прослушиватель базы данных, соответственно.

pg_dump -U роль -h 20.20.20.20 -p 7777 имя_базы_данных

Флаг -U используется для указания роли для подключения к вашей базе данных. Это важно, чтобы убедиться, что у вас есть надлежащие привилегии для доступа к содержимому базы данных. Если у вас все еще есть проблемы с доступом к нему, вы можете проверить, настроены ли методы аутентификации базы данных на сервере базы данных.

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

pg_dump -U роль -h 10.10.10.10 база данных | plsql -U роль -h 20.20.20.20 имя_базы_данных

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

Вы можете запланировать резервное копирование своих баз данных через определенные промежутки времени с помощью заданий cron в PostgreSQL. Чтобы настроить одно такое задание, войдите в систему через суперпользователя и введите следующие команды:

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

 mkdir -p /srv/резервные копии/базы данных
crontab -e 

В конце crontab скопируйте и вставьте следующее:

pg_dump -U postgres имя_базы_данных > /srv/backups/postgres/имя_базы_данных.sql

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

Заключение

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

Теперь, когда вы узнали, как сделать резервную копию базы данных PostgreSQL, попробуйте сделать это на своей базе данных!

ПРИСОЕДИНЯЙТЕСЬ к новостной рассылке Arctype

Истории по программированию, руководства и советы по работе с базами данных каждые 2 недели

Резервное копирование и восстановление базы данных PostgreSQL: инструменты и шаги

Содержание

• Что такое PostgreSQL?
• Зачем нужно делать резервную копию базы данных?
• Как сделать резервную копию и восстановить базу данных PostgreSQL?
• Резервное копирование и восстановление PostgreSQL с помощью профессионального решения
• Заключение

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

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

Что такое PostgreSQL?

PostgreSQL или Postgres — это расширяемая система управления реляционными базами данных (RDBMS) с открытым исходным кодом, которая поддерживает запросы SQL и JSON. База данных работает в нескольких широко используемых операционных системах, таких как Linux, Windows, Mac OS, FreeBSD и OpenBSD. Точки данных хранятся в строках со столбцами, действующими как различные свойства данных.

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

Зачем нужно делать резервную копию базы данных?

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

Предотвращение потери данных:  Регулярное резервное копирование базы данных сводит к минимуму потерю данных в случае атак программ-вымогателей, сбоев системы или других аварий.

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

Непрерывность бизнеса:  Будучи нематериальным основным активом компании, частое резервное копирование базы данных обеспечивает доступность данных и, следовательно, непрерывность бизнеса.

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

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

Миграция базы данных: Иногда нам просто нужно сделать резервную копию и экспортировать данные для миграции. Мы можем перенести Oracle DB, MySQL и SQL Server на PostgreSQL и наоборот.

Как сделать резервную копию и восстановить базу данных PostgreSQL?

Обычно существует несколько инструментов PostgreSQL для резервного копирования и восстановления базы данных: pg_dump /pg_dumpall и plsql, pg_restore.

Что такое pg_dump?

Pg-dump — это утилита для резервного копирования базы данных PostgreSQL, даже если база данных используется одновременно, и она не препятствует доступу к базе данных других пользователей. Команда pg-dump выгружает только одну базу данных за раз, и информация о ролях и табличных пространствах не включается.

Что такое pg_dumpall?

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

Как создать резервную копию базы данных PostgreSQL ?

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

su – postgres

Резервное копирование одна база данных PostgreSQL с pg-dump:

pg_dump -U имя пользователя -h имя хоста -p номер порта -F имя базы данных > имя_файла.sql

Дополнительные форматы файлов (-F):

-p: текстовый файл сценария SQL (по умолчанию).

-c: архив произвольного формата для ввода в pg-restore.

-d: архив в формате каталога.

-t: архив в формате tar.

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

pg_dumpall > имя файла

Резервное копирование больших баз данных PostgreSQL :

Сжать большой дамп сначала файл и сохраните с помощью -gzip.

Pg_dump имя_базы_данных | gzip > dumpname.gz

Или параллельный дамп с помощью pg_dump для одновременного резервного копирования файлов формата архива нескольких каталогов.

pg_dump -j num -F d -f out.dir имя_базы_данных

Резервное копирование удаленных баз данных PostgreSQL с помощью pg_dump:

имя.бак

Автоматическое резервное копирование PostgreSQL с запланированными заданиями cron:

1. Создайте каталог для резервных копий.

mkdir -p /suv/backups/databases

2. Отредактируйте crontab, чтобы создать новую задачу.

кронтаб -е

3. Скопируйте сценарий резервного копирования в конец crontab.

pg_dump -U postgres имя_базы_данных > /suv/backups/postgres/database_name.sql

Задание запланировано на каждое воскресенье, и вы можете изменить время и частоту.

Как восстановить базу данных PostgreSQL?

Psql:  Восстановить данные из простого текстового файла сценария SQL, созданного pg-dump.

Pg_restore:  Восстановление данных из файла tar, каталога или файла пользовательского формата, созданного с помощью pg-dump. Вот несколько вариантов:

-c:  удалять объекты базы данных до их воссоздания.

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

-e: выйти, если возникнут проблемы.

Восстановить текстовых файлов с помощью psql:

plsql -U имя_пользователя имя_базы_данных < имя_файла.sql

Восстановить пользовательских файлов, каталогов, форматов tar с помощью pg-restore:

p g_restore -d имя_базы_данных путь_файла_дампа. tar/-c/ -U имя пользователя

Восстановить удаленную базу данных с помощью psql:

psql -h имя хоста -p номер порта имя_базы_данных < database.sql

Резервное копирование и восстановление PostgreSQL с помощью профессионального решения восстановление

Oracle Database, MySQL, SQL Server, PostgreSQL, Postgres Pro и MariaDB на физических и виртуальных машинах, 12 виртуализаций, таких как VMware, Hyper-V, Xen, RHEV/oVirt и т. д. ., 2 физических сервера, NAS.

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

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

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

Простое резервное копирование PostgreSQL:

1. Перейдите к Физическое резервное копирование> Резервное копирование базы данных> Резервное копирование и выберите установленный агент резервного копирования базы данных и источник резервной копии базы данных.

2. В раскрывающемся списке выберите узел резервного копирования и хранилище на узле для задания.

3. При необходимости настройте стратегии резервного копирования.

4. Проверить и закончить.

Простое восстановление PostgreSQL:

1. Перейдите к «Физическое резервное копирование»> «Резервное копирование базы данных»> «Восстановить» и выберите установленный агент резервного копирования базы данных и источник резервного копирования.