Бэкап и восстановление PostgreSQL через pgAdmin 4

В pgAdmin 4 можно сделать бэкап PostgreSQL через меню Backup и восстановить базу через Restore. При этом pgAdmin не изобретает отдельный способ резервного копирования: под капотом он использует стандартные инструменты PostgreSQL, прежде всего pg_dump и pg_restore. Поэтому важно понимать форматы дампов, права пользователя и настройку binary path.

Какие форматы backup есть в pgAdmin

Формат	Когда использовать	Чем восстанавливать
Custom	Основной вариант для рабочих дампов: компактный, поддерживает выборочное восстановление	pg_restore или Restore в pgAdmin
Tar	Архивный формат, если нужен один файл без plain SQL	pg_restore или Restore в pgAdmin
Plain	SQL-текст, который можно открыть и читать	psql или Query Tool, если файл небольшой

Для большинства задач через pgAdmin выбирайте Custom. Plain SQL удобен для маленьких баз и учебных примеров, но для больших баз он быстро становится тяжелым и менее гибким.

Как сделать Backup через pgAdmin 4

1. Подключитесь к серверу PostgreSQL в pgAdmin.
2. Раскройте Databases.
3. Нажмите правой кнопкой по нужной базе.
4. Выберите Backup.
5. В поле Filename укажите путь и имя файла, например shop.backup.
6. В Format выберите Custom.
7. При необходимости включите Verbose messages, чтобы видеть подробный лог.
8. Нажмите Backup.

CLI-эквивалент такой операции:

pg_dump -h localhost -p 5432 -U postgres -Fc -d shop -f shop.backup

Если backup завершился без ошибок, это еще не означает, что резервная копия проверена. Проверенным бэкап становится только после успешного тестового восстановления.

Как восстановить базу через Restore

Безопасная схема восстановления — не поверх рабочей базы, а в новую пустую базу. Так вы проверяете дамп и не рискуете текущими данными.

1. Создайте новую пустую базу, например shop_restored.
2. Нажмите по ней правой кнопкой.
3. Выберите Restore.
4. В Filename выберите файл shop.backup.
5. Убедитесь, что формат соответствует файлу.
6. Запустите Restore.
7. После восстановления откройте Query Tool и проверьте ключевые таблицы.

createdb -h localhost -p 5432 -U postgres shop_restored
pg_restore -h localhost -p 5432 -U postgres -d shop_restored shop.backup

Минимальная проверка после восстановления:

SELECT current_database();

SELECT table_name
FROM information_schema.tables
WHERE table_schema = 'public'
ORDER BY table_name;

Как импортировать plain SQL

Если у вас файл backup.sql, это plain SQL. Его можно выполнить через psql. В pgAdmin маленький SQL-файл можно открыть в Query Tool и выполнить, но для больших дампов надежнее использовать командную строку.

psql -h localhost -p 5432 -U postgres -d shop_restored -f backup.sql

Если plain SQL содержит команды создания базы, подключайтесь к служебной базе postgres. Если файл содержит только таблицы и данные, подключайтесь к целевой базе.

Binary path: почему pgAdmin не видит pg_dump

pgAdmin вызывает внешние утилиты PostgreSQL. Если в настройках не указан путь к этим утилитам, Backup или Restore может завершиться ошибкой вроде Utility file not found. Это означает, что pgAdmin не нашел pg_dump, pg_restore или похожую программу.

Решение: открыть настройки pgAdmin, найти раздел Binary paths / Paths и указать папку, где установлены PostgreSQL-утилиты. На Windows это может быть папка вида C:\Program Files\PostgreSQL\17\bin. На Linux путь часто определяется пакетной установкой, но при нестандартной установке его тоже приходится задавать явно.

Чем pgAdmin отличается от командной строки

pgAdmin удобен для разового backup и восстановления в учебной или небольшой рабочей базе. Командная строка лучше подходит для регулярной автоматизации: cron, планировщик задач, хранение логов, ротация файлов, проверка восстановления. В продакшне backup обычно автоматизируют, а pgAdmin используют для контроля и разовых операций.

Нормальная практика такая: pgAdmin помогает понять процесс, но регулярный backup должен быть воспроизводимым скриптом. И обязательно должна быть проверка restore.

Типичные ошибки backup и restore

Utility file not found. Настройте binary path к папке PostgreSQL bin.

Версии PostgreSQL не совпадают. Обычно дамп лучше делать утилитой той же или более новой major-версии, чем сервер-источник. При переносе между версиями заранее тестируйте восстановление.

Не хватает прав. Пользователь должен иметь права читать объекты при backup и создавать объекты при restore. Для полного восстановления часто нужен владелец базы или суперпользователь.

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

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

Чек-лист перед созданием backup

• Понятно имя базы, которую нужно копировать.
• Понятно, кто владелец базы и объектов.
• Проверен размер базы: хватит ли места для файла backup.
• Выбран формат: обычно Custom.
• Понятно, где будет храниться файл после создания.
• Есть доступ к утилитам PostgreSQL, а binary path в pgAdmin настроен.
• Есть план тестового восстановления.

SELECT
  pg_size_pretty(pg_database_size(current_database())) AS current_db_size,
  current_database() AS database_name,
  current_user AS connected_user;

Если база весит десятки гигабайт, не запускайте backup «наугад» с рабочего ноутбука. Сначала оцените место на диске, скорость сети и окно работ. Для больших баз лучше заранее согласовать регламент и хранение копий.

Чек-лист после восстановления

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

SELECT table_schema, COUNT(*) AS tables_count
FROM information_schema.tables
WHERE table_type = 'BASE TABLE'
GROUP BY table_schema
ORDER BY table_schema;

SELECT schemaname, relname, n_live_tup
FROM pg_stat_user_tables
ORDER BY n_live_tup DESC
LIMIT 20;

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

Как вести историю резервных копий

Даже если backup сделан через pgAdmin вручную, сохраняйте понятное имя файла: имя базы, дата, время и формат. Например: shop_2026-05-18_2300.custom.backup. Так проще понять, какая копия последняя и откуда она взялась.

shop_2026-05-18_2300.custom.backup
shop_2026-05-19_2300.custom.backup
shop_2026-05-20_2300.custom.backup

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

Минимальный регламент для небольшой базы

• Ежедневный backup в Custom-формате.
• Хранение минимум нескольких последних копий.
• Отдельная копия вне сервера базы данных.
• Тестовое восстановление по расписанию.
• Лог результата backup и restore.
• Понятный ответственный за проверку.

Главная ошибка — считать backup задачей «создать файл». На практике задача звучит иначе: иметь возможность восстановить базу до нужной точки и доказать это до аварии.

Какие параметры Restore трогать осторожно

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

Clean before restore удаляет объекты перед восстановлением. Это опасно для базы, где уже есть нужные данные. Для тестового восстановления безопаснее создать новую пустую базу. No owner может помочь, если на новом сервере нет старых владельцев объектов, но тогда нужно заранее понимать, кто станет владельцем после restore. Only data и Only schema подходят для частичных сценариев, но не для полного восстановления базы.

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

Backup в Docker-сценарии

Если PostgreSQL работает в Docker, pgAdmin может быть установлен на хосте или поднят отдельным контейнером. В первом случае pgAdmin на хосте подключается к localhost и проброшенному порту. Во втором случае pgAdmin внутри Compose-сети подключается к имени сервиса, например postgres.

# Если pgAdmin и PostgreSQL в одной compose-сети:
Host name/address: postgres
Port: 5432

# Если pgAdmin установлен на хосте, а порт проброшен:
Host name/address: localhost
Port: 5432

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

Как понять, что backup пора автоматизировать

Если вы сделали backup один раз для учебного переноса, pgAdmin достаточно. Если вы делаете backup каждую неделю или каждый день, ручной процесс уже является риском. Человек может забыть, выбрать не ту базу, сохранить файл на локальный диск или не проверить restore.

• Backup повторяется по расписанию.
• База важна для приложения или бизнеса.
• Нужно хранить историю копий.
• Нужно получать уведомление об ошибке.
• Нужно периодически проверять restore.
• Копии должны уходить на отдельное хранилище.

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

Пример журнала backup

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

Дата	База	Файл	Размер	Restore проверен
2026-05-18	shop	shop_2026-05-18.custom.backup	1.2 GB	да, на shop_restore_test

Если в журнале несколько дней подряд нет проверенного restore, это сигнал исправить процесс. Резервные копии ценны только тогда, когда вы знаете, как и за сколько их восстановить.

Как тренировать восстановление

Тестовый restore лучше выполнять по простому сценарию: создать отдельную базу, восстановить последнюю копию, выполнить контрольные запросы, записать результат, удалить тестовую базу. Это занимает меньше времени, чем кажется, и заранее показывает проблемы с ролями, расширениями, путями и форматом backup.

-- После восстановления проверить размер:
SELECT pg_size_pretty(pg_database_size(current_database()));

-- Проверить расширения:
SELECT extname, extversion
FROM pg_extension
ORDER BY extname;

-- Проверить последние пользовательские таблицы:
SELECT schemaname, relname, n_live_tup
FROM pg_stat_user_tables
ORDER BY relname
LIMIT 50;

Если проверка выполняется регулярно, держите отдельный файл с контрольными SQL-запросами. Тогда восстановление проверяется одинаково каждый раз, а не по памяти.

Для команды удобно договориться о целевом времени восстановления. Например: маленькая база должна восстанавливаться за 15 минут, средняя — за час. Если тестовый restore внезапно занимает намного больше, это повод пересмотреть формат backup, место хранения, скорость диска или процедуру восстановления.

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

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

Что читать дальше

Связанные материалы из базы:

Бэкап PostgreSQL — подробный разбор pg_dump, pg_restore и автоматизации.

pgAdmin 4 — подключение к серверу и базовая работа.

Пользователи и права в PostgreSQL — роли, GRANT и REVOKE.

PostgreSQL в Docker — backup в контейнерном окружении.

Часто задаваемые вопросы

Можно ли считать файл backup проверенным сразу после создания?

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

Можно ли восстановить custom backup через Query Tool?

Нет. Custom, Tar и Directory-форматы восстанавливают через Restore в pgAdmin или через pg_restore. Query Tool подходит для SQL-текста, но не для бинарных dump-файлов.

Что лучше выбрать: Custom или Plain?

Для рабочих резервных копий чаще выбирают Custom: он компактнее и гибче при восстановлении. Plain удобен, когда нужен читаемый SQL-файл для небольшого примера или ручного просмотра.