phpPgAdmin — дампы, безопасность и FAQ

ДЛЯ НОВИЧКОВ

Разработчику Инженеру

Четвёртая глава раздела phpPgAdmin — про резервное копирование, импорт дампов, безопасную эксплуатацию веб-админки и типичные сбои из истории проекта и практики администрирования PostgreSQL. Предполагается, что вы уже умеете выполнять SQL и работать со схемами из третьей статьи и настроили подключение по второй.

Дамп (dump) — файл с SQL-командами или бинарным снимком базы, из которого можно восстановить данные или перенести их на другой сервер. phpPgAdmin не реализует дамп на чистом PHP: он запускает внешние утилиты PostgreSQL — pg_dump и pg_dumpall — и отдаёт результат через браузер. Для очень больших объёмов надёжнее те же команды из psql или cron — см. резервное копирование PostgreSQL и практикум 8.11.

---

Экспорт и импорт

Как phpPgAdmin делает дамп

В отличие от phpMyAdmin, который формирует SQL внутри PHP, phpPgAdmin делегирует работу клиентским утилитам сервера PostgreSQL. Пути к ним задаются в config.inc.php — параметры pg_dump_path и pg_dumpall_path. Если утилита не найдена, экспорт падает с ошибкой "pg_dump not found" (разбор в разделе FAQ ниже).

Утилита	Область дампа	Глобальные объекты (роли, tablespaces)
pg_dump	Одна база, отдельная схема или таблица	Нет — только объекты внутри выбранной базы
pg_dumpall	Все базы кластера	Да — роли, tablespaces, настройки уровня кластера

pg_dump — основной инструмент бэкапа одной базы перед миграцией или экспериментом с DDL. pg_dumpall нужен при переносе всего кластера или когда важно сохранить определения ролей вне конкретной базы.

Форматы выгрузки

Формат	Расширение	Смысл	Восстановление
Plain SQL	.sql	Текстовый файл с CREATE и COPY/INSERT	psql -f backup.sql
Custom	.dump, .backup	Сжатый архив с метаданными	pg_restore -d dbname file.dump
Directory	каталог	Параллельный дамп в файлы	pg_restore -d dbname dir/
Tar	.tar	Архив tar	pg_restore

В интерфейсе phpPgAdmin (зависит от версии) обычно доступны:

• только структура (DDL без строк);
• только данные (без CREATE TABLE);
• структура и данные;
• выбор SQL или custom format.

Custom format удобен для частичного восстановления отдельных таблиц и параллельного pg_restore на многоядерных серверах — подробнее в Резервное копирование и восстановление PostgreSQL.

extra_float_digits и точность float

PostgreSQL передаёт значения типа float / double precision с учётом параметра сессии extra_float_digits. При дампе через старые версии phpPgAdmin в SQL могли попадать лишние знаки или, наоборот, округление, если datestyle и настройки сессии в веб-клиенте не совпадали с теми, что использовал pg_dump.

На практике:

• для критичных финансовых данных предпочитайте тип numeric, а не float;
• перед сравнением дампов сверяйте выгрузку через psql и через phpPgAdmin на тестовой базе;
• на современных связках PostgreSQL 12+ и phpPgAdmin 7.13 проблема встречается реже, но при миграции со старых стендов её стоит помнить.

Пример экспорта из консоли

Эквивалент "структура + данные одной базы" в SQL:

pg_dump -h 127.0.0.1 -U postgres -d shop --format=plain --file=shop_backup.sql

Только схема public без данных:

pg_dump -h 127.0.0.1 -U postgres -d shop --schema=public --schema-only

Custom format со сжатием:

pg_dump -h 127.0.0.1 -U postgres -d shop --format=custom --file=shop.dump

Разбор флагов:

• -h / -p — хост и порт (те же, что в config.inc.php);
• -d shop — имя базы, выбранной в дереве phpPgAdmin;
• --format=plain — текст, читаемый в редакторе; custom — для pg_restore;
• --schema-only / --data-only — аналог галочек "только структура" / "только данные" в UI.

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

pg_dumpall -h 127.0.0.1 -U postgres --file=cluster.sql

---

Импорт SQL и восстановление

Импорт в phpPgAdmin — загрузка .sql через вкладку Import (название может отличаться в переводе). PHP принимает файл методом POST и передаёт содержимое в PostgreSQL — те же ограничения, что у phpMyAdmin при импорте.

Лимиты PHP

Директива	Смысл	Практическое правило
upload_max_filesize	Максимальный размер одного файла	Поднимайте под размер дампа
post_max_size	Лимит всего тела POST	Должен быть больше upload_max_filesize
max_execution_time	Время работы скрипта	Большой дамп упирается в 30–60 с по умолчанию
memory_limit	Память процесса PHP	Крупный SQL может требовать сотни мегабайт

Пример для локальной разработки (значения подстраивайте под объём):

upload_max_filesize = 128M
post_max_size = 130M
max_execution_time = 600
memory_limit = 256M

После правки php.ini перезапустите PHP-FPM или Apache — см. настройку веб-сервера для PHP.

Импорт plain SQL через psql

Когда форма в браузере не справляется, используйте консоль — тот же файл, что скачали из phpPgAdmin:

psql -h 127.0.0.1 -U postgres -d shop -f backup.sql

Пошагово:

1. psql — интерактивный клиент PostgreSQL (PostgreSQL — практическая работа и API);
2. -d shop — целевая база (создайте пустую заранее, если в дампе нет CREATE DATABASE);
3. -f backup.sql — выполнить все команды из файла подряд.

Внутри уже открытой сессии psql то же самое:

\c shop
\i /path/to/backup.sql

Восстановление custom format

Файлы .dump нельзя просто скормить psql — нужен pg_restore:

pg_restore -h 127.0.0.1 -U postgres -d shop --verbose backup.dump

Полезные опции:

• --clean — перед созданием объектов выполнить DROP (осторожно на проде);
• --no-owner — не пытаться назначить владельца из дампа (удобно при переносе между серверами);
• -j 4 — параллельное восстановление (для directory/custom format).

Большие дампы и open_basedir

Проблема	Решение
Таймаут HTTP / 504	Импорт через psql или pg_restore, увеличение max_execution_time
Нехватка памяти PHP	CLI-клиенты не держат весь файл в RAM веб-процесса
open_basedir	Каталог загрузки и временные файлы PHP должны лежать в разрешённых путях — аналог TempDir в phpMyAdmin
Дамп на гигабайты	Разбить по схемам, использовать custom format + сжатие, автоматизировать через Wal-G / pgBackRest

Перед DROP или массовым DELETE

Сделайте экспорт базы или хотя бы затронутых таблиц — из phpPgAdmin или через pg_dump. Откат "из головы" после ошибочного DROP SCHEMA … CASCADE из третьей статьи возможен только из бэкапа.

---

Безопасность установки

phpPgAdmin не добавляет отдельный слой авторизации — любой, кто открыл URL и знает роль/пароль PostgreSQL, получает те же права, что эта роль в СУБД. Рекомендации пересекаются с информационной безопасностью и настройкой pg_hba.conf.

Мера	Зачем
Require local / VPN / firewall	Не публиковать /phppgadmin в открытый интернет
HTTPS	Защита пароля и cookie сессии — HTTP и HTTPS
SCRAM в pg_hba	Сильные пароли ролей вместо устаревшего md5
Отдельная роль приложения	Повседневная работа без SUPERUSER и BYPASSRLS
Минимальные права на config	config.inc.php не должен отдаваться как статический файл
Актуальный PHP и phpPgAdmin	В 7.12 закрывали Reflected XSS — следите за релизами
Ограничение по IP в pg_hba	Разрешать подключение только с хоста веб-сервера

На shared-хостинге (идеи из ветки 3.0-beta phpPgAdmin):

• скрытие админ-разделов для ролей без суперправ;
• фильтр "только свои базы" (owned databases only);
• запрет смены пароля на слишком короткий.

phpPgAdmin ≠ firewall

Даже идеально настроенный веб-клиент не компенсирует открытый порт 5432 в интернет и роль postgres с простым паролем. Сначала pg_hba и сеть, потом удобный UI.

---

phpPgAdmin и pgAdmin 4

Оба инструмента решают задачу графического администрирования PostgreSQL, но архитектура разная.

	phpPgAdmin	pgAdmin 4
Стек	PHP + Apache/nginx	Python, Electron; есть веб-режим
Включение в XAMPP / Open Server	Редко "из коробки"	Часто идёт с PostgreSQL
Активность проекта	Релизы реже после 2020	Основной GUI от сообщества PG
Дампы	Вызов pg_dump / pg_dumpall	Встроенный мастер + те же утилиты
Мониторинг, ERD, графики	Базово	Расширенно
Зависимости	Расширение PHP pgsql	Отдельный сервис / приложение

В Open Server для PostgreSQL документация панели обычно указывает pgAdmin и psql. phpPgAdmin имеет смысл, когда уже развёрнут PHP-стек и нужен лёгкий веб-клиент без установки pgAdmin — см. вводную главу.

Для сравнения с экосистемой MySQL — phpPgAdmin исторически шёл параллельно phpMyAdmin (история веб-админок), но сегодня для PostgreSQL чаще выбирают pgAdmin, DBeaver или CLI-практику.

---

FAQ — типичные ситуации

PHP does not support PostgreSQL

Симптом: белый экран или сообщение при открытии phpPgAdmin.

Причина: расширение PHP pgsql не загружено.

Что сделать:

1. Установить пакет php-pgsql (Linux) или включить DLL в Windows;
2. Раскомментировать extension=pgsql в php.ini;
3. Проверить: php -m | grep pgsql;
4. Перезапустить веб-сервер.

Подробнее — требования и установка.

Could not connect to server

Симптом: форма входа или главная страница сообщает, что сервер недоступен.

Чеклист:

• служба PostgreSQL запущена (pg_ctl status / services.msc);
• в config верны host и port;
• в pg_hba.conf разрешён IP машины, где выполняется PHP (не только 127.0.0.1, если PHP на другом хосте);
• firewall не блокирует 5432;
• listen_addresses в postgresql.conf включает нужный интерфейс — 8.11/3.

pg_dump not found

Симптом: экспорт из UI падает сразу после нажатия кнопки.

Причина: PHP-процесс не находит бинарник в PATH.

Решение: полные пути в config (Windows — .exe в каталоге установки PostgreSQL):

$conf['servers'][0]['pg_dump_path'] = 'C:/PostgreSQL/16/bin/pg_dump.exe';
$conf['servers'][0]['pg_dumpall_path'] = 'C:/PostgreSQL/16/bin/pg_dumpall.exe';

Проверьте права: пользователь веб-сервера должен выполнять эти файлы.

Cannot connect to template1

Симптом: ошибка при первом подключении к серверу.

Причина: phpPgAdmin по умолчанию может использовать template1 как defaultdb, а хостинг блокирует доступ к шаблонным базам.

Решение:

$conf['servers'][0]['defaultdb'] = 'postgres';

Исправление описано в HISTORY 3.0-rc-2; см. также config.inc.php.

Пустая страница или ошибки после входа

Симптом: HTTP 500, пустой HTML, Fatal error в логе PHP.

Что проверить:

• лог PHP и лог PostgreSQL на момент запроса;
• совместимость PHP 8 со старой веткой phpPgAdmin без патчей — community-форк или переход на pgAdmin;
• включены ли mbstring и pgsql (7.12+ требует mbstring);
• не остался ли синтаксис PHP 5 в локальных правках config.

Сортировка сбрасывает на структуру таблицы

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

Решение: обновить phpPgAdmin до 7.13.0+, где баг исправлен.

bytea и бинарные поля

Симптом: "кракозябры" при просмотре, порча данных после UPDATE через UI.

Контекст: в старых релизах были ошибки кодирования bytea. Для критичных бинарных данных проверяйте чтение/запись через psql или приложение на PDO; храните большие файлы в объектном хранилище, а в БД — путь или hash.

phpPgAdmin и MySQL

Вопрос: можно ли подключить phpPgAdmin к MySQL?

Ответ: нет. Для MySQL — phpMyAdmin; для PostgreSQL — phpPgAdmin, pgAdmin или psql. Протоколы и диалекты SQL разные (889 MySQL vs 888 PostgreSQL).

---

См. также

• phpPgAdmin — о разделе
• SQL, DDL и DML в phpPgAdmin
• Требования, установка и подключение
• История phpMyAdmin и phpPgAdmin
• phpMyAdmin — импорт и FAQ
• PostgreSQL — установка и pgAdmin
• Резервное копирование SQL
• Бэкапы и Wal-G — 8.11
• Практикум PostgreSQL — о разделе

---