Автор статьи: технический руководитель проектов внедрения 1С:ERP Внедренческого центра «Раздолье» Дмитрий Малышев.
Введение
pgAdmin — это интерфейс для администрирования баз данных PostgreSQL, в моём понимании это аналог MS SQL Management Studio. Ставится pgAdmin отдельно от PostgreSQL. Инструкцию установки найдите, пожалуйста, в интернет поисковиках. В данной инструкции будет описано как с помощью pgAdmin, bat-файлов и Планировщика заданий Windows организовать резервное копирование, восстановление и хранение копий баз данных.
Открытие pgAdmin
Через пуск или в проводнике открываем приложение.
«C:\Program Files\pgAdmin 4\v6\pgAdmin4.ico»
Вводим пароль доступа (за дается ранее пользователем).
Откроется интерфейс управления базами данных.
Создание резервной копии
Рассмотрим создание резервной копии из pgAdmin и командным bat-файлом.
2.1. С помощью pgAdmin
Выбираем базу в дереве, правой кнопкой мыши открываем контекстное меню, где выбираем создание резервной копии/Backup… Указываем полный путь для сохранения копии, формат Custom и жмем [Создать / Create].
***
***
2.2. С помощью командного файла *.bat
Запускаем двойным кликом мыши командный файл backup_pdadmin_UH_IMD_everyday.bat, в котором уже прописан вызов архиватора формат и путь файла копии.
Копии сохраняются сюда.
Содержимое командного файла:
REM СОЗДАНИЯ РЕЗЕРВНОЙ КОПИИ БАЗЫ ДАННЫХ POSTGRESQL
CLS
ECHO OFF
CHCP 1251
REM Установка переменных окружения
SET PGDATABASE=IMD_UH
SET PGHOST=localhost
SET PGPORT=5432
SET PGUSER=postgres
SET PGPASSWORD=ЗДЕСЬ_УКАЖИТЕ_ПАРОЛЬ_для_пользователя_postgres
REM Формирование имени файла резервной копии и файла-отчета
SET DATETIME=%DATE:~6,4%-%DATE:~3,2%-%DATE:~0,2% %TIME:~0,2%-%TIME:~3,2%-%TIME:~6,2%
SET DUMPFILE=%PGDATABASE% %DATETIME%.backup
SET LOGFILE=%PGDATABASE% %DATETIME%.log
SET DUMPPATH=»E:\UH_IMD\Backup\%DUMPFILE%»
SET LOGPATH=»E:\UH_IMD\Backup\%LOGFILE%»
REM Создание резервной копии
IF NOT EXIST Backup MD Backup
CALL «C:\Program Files\pgAdmin 4\v6\runtime\pg_dump.exe» —format=custom —verbose —file=%DUMPPATH% 2>%LOGPATH%
REM Анализ кода завершения
IF NOT %ERRORLEVEL%==0 GOTO Error
GOTO Successfull
REM В случае ошибки удаляется поврежденная резервная копия и делается соответствующая запись в журнале
:Error
DEL %DUMPPATH%
MSG * «ERROR to create backup!!! See the information E:\UH_IMD\Backup\backup.log.»
ECHO %DATETIME% Ошибка при создании резервной копии %DUMPFILE%. Смотрите %LOGFILE%. >> backup.log
GOTO End
REM В случае удачного резервного копирования просто делается запись в журнал
:Successfull
ECHO %DATETIME% Успешное создание резервной копии %DUMPFILE% >> backup.log
GOTO End
:End
Пояснения:
SET PGDATABASE=IMD_UH — здесь имя базы данных на СУБД равно IMD_UH, у вас будет свое поменяйте обязательно.
E:\UH_IMD\Backup — здесь путь хранения backup у вас будет свой, поменяйте.
C:\Program Files\pgAdmin 4\v6\runtime — папка утилиты pg_dump.exe для создания дампов, пусть может чуть отличаться, например, вместо v6 будет v4. И не забудьте pgAdmin установить, он ставится отдельно.
SET PGPASSWORD=ЗДЕСЬ_УКАЖИТЕ_ПАРОЛЬ_для_пользователя_postgres — тут укажите реальный пароль от пользователя postgres СУБД PostgreSQL
Восстановление резервной копии
Есть несколько способов: Из командной строки, из pgAdmin, заранее подготовленным командным файлом. Мы рассмотрим: pgAdmin.
3.1. С помощью pgAdmin
3.1.1. В существующую базу
Выбираем базу, вызываем правой кнопкой ее контекстное меню, где выбираем действие Восстановить / Restore.
Далее указываем путь к резервной копии, и в настройках ставим предварительно очищать существующую базу (иначе она не восстановится из-за конфликта таблиц).
***
***
***
3.1.2. В новую базу
3.1.2.1. Создаем новую базу в PostgreSQL
На корне дерева баз вызываем правой кнопкой мыши контекстное меню и действие Создать / Create – Базу данных / Database.
Задаем имя новой базы.
Выбираем обязательно схему создания template0 (иначе на следующем шаге база не развернется из backup из-за конфликта таблиц).
Для контроля смотрим итоговый запрос, и жмем кнопку [Сохранить]/[Save].
3.1.2.2. Восстанавливаем базу из архива в PostgreSQL
После создания пустой новой базы, её нужно восстановить из архива. Для этого смотрите пункт выше 3.1.1. Для восстановления в существующую базу, выполняем всё тоже самое только для базы с именем NewBaseName
3.1.2.3. Создаем новую базу 1С NewBaseName
После того как развернули базу на СУБД PostgreSQL её требуется опубликовать на сервере 1С, чтобы пользователи получили к ней доступ. Для этого выполним действия по созданию базы 1С и связывании её с существующей базой на СУБД.
***
***
***
***
Не забываем ставь флаг «Установить блокировку регламентных заданий», если это копия.
Удаление старых резервных копий
4.1. Вручную
Удаляем архивы старше 30 дней вручную. Затем чистим корзину на рабочем столе.
В проводнике папка E:\UH_IMD\Backup.
***
4.2. С помощью командного файла *.bat
Запускаем двойным щелчком мыши командный файл. В файле указана очистка в каталоге файлов старше 30 дней.
Его содержимое:
forfiles /p «E:\UH_IMD\Backup» /S /D -30 /C «cmd /c del /f /a /q @file»
Пояснения:
E:\UH_IMD\Backup — здесь путь хранения backup’ов, у вас будет свое поменяйте обязательно.
30 — срок в днях хранения backup’ов
Автоматическое выполнение резервного копирования
Использован стандартный планировщик заданий Windows каждый день в 5:00 утра запуск, выполнения командного файла (архив рабочей базы примерно 1 час создается).
***
***
***
***
***
***
Автоматическое выполнение очистки копий старше 30 дней
Использован стандартный планировщик заданий Windows каждую субботу в 10:00 утра запуск, выполнения командного файла.
***
***
***
***
***
***
Приложения
Пример содержимого общего файла логов backup.log.
Пример содержимого файла лога конкретной выгрузки UH_IMD 2022-10-07 5-00-00.log
P.S. Коллеги, сразу скажу, что я не системный администратор, а программист 1С. Системщик решил бы, может быть, элегантнее.
Хотя ситуация сложилась такая, что я делал настройки и эту инструкцию с bat-никами по просьбе системных администраторов (как бы странно это ни звучало). Нечасто такими настройками занимаюсь, поэтому не судите строго.
Добавил 2 батника, по обновлению статистики и реиндексации:
Они для регламентного обслуживания. 1С завершать для их работы не обязательно, но 1С будет притормаживать или пойдет блокировка на период реиндексации. В планировщик заданий Windows на эти батники добавьте задачи раз в неделю на свои базы, в Нерабочее время. Также есть служебная база postgres на нее тоже раз в неделю добавьте обслуживание.
Файл vacuumdb_BaseName.bat — обновление статистики.
Его содержимое:
vacuumdb -d UH_IMD -Z -v -j 1
Пояснения:
Обновление статистики базы с именем UH_IMD (тут поставьте свою) в 1 поток.
Можно поменять на обновление статистики во всех базах в 4 потока, тогда будет текст:
vacuumdb -a -Z -v -j 4
Файл reindexdb_BaseName.bat — реиндексация таблиц в базе.
Его содержимое:
reindexdb -d UH_IMD -v -j 1
Пояснения:
Обновление индексов в базе с именем UH_IMD (тут поставьте свою) в 1 поток.
Можно поменять на обновление статистики во всех базах в 4 потока, тогда будет текст:
reindexdb -a -v -j 4
Также обратите внимание на программу Effector Saver — программа резервного копирования 1С:Предприятия (поищите в инете).
Делает копии в MS и PostgreSQL, настройка хранения и удаления. Есть возможность подключать скрипты и выполнять тестирование исправление 1С. Есть бесплатная версия (которой должно хватить), и есть также платная с плюшками.
Ищите для работы вот этот материал с инструкциями для скачивания и использования:
-
backup_pgadmin_BaseName_everyday.bat
-
delete_backup_BaseName_older than 30 days.bat
-
Резервное копирование и восстановление баз PostgreSQL в Windows с помощью pgAdmin, bat-файлов и планировщика.docx
-
vacuumdb_BaseName.bat
-
reindexdb_BaseName.bat
Обновлено:
Опубликовано:
Тематические термины: PostgreSQL, SQL
В данной инструкции рассмотрены варианты и примеры создания резервных копий и восстановления баз СУБД PostgreSQL.
Создание копий
Базовая команда
Пользователь и пароль
Сжатие данных
Скрипт
На удаленном сервере
Дамп определенной таблицы
Каждая таблица в свой файл
Для определенной схемы
Только схемы
Только данные
pgAdmin
Не текстовые форматы
pg_basebackup
pg_dumpall (все базы данных)
Восстановление
Базовая команда
С авторизацией
Из файла gz
Определенную базу
Определенную таблицу
С помощью pgAdmin
pg_restore (бинарные бэкапы)
Работа с CSV
Возможные проблемы
Input file appears to be a text format dump. please use psql
No matching tables were found
Too many command-line arguments
Aborting because of server version mismatch
No password supplied
Неверная команда \
Все команды, которые приводятся ниже, должны выполняться из командной строки. В Linux — это окно терминала, в Windows — командная строка (cmd.exe) с переходом в папку установки PostgreSQL.
Создание резервных копий
Базовая команда
Синтаксис:
pg_dump <параметры> <имя базы> > <файл, куда сохранить дамп>
Пример:
pg_dump users > /tmp/users.dump
Также путь к файлу можно указать с помощью опции -f:
pg_dump users -f /tmp/users.dump
Пользователь и пароль
Если резервная копия выполняется не от учетной записи postgres, необходимо добавить опцию -U с указанием пользователя:
pg_dump -U dmosk -W users > /tmp/users.dump
* где dmosk — имя учетной записи; опция W потребует ввода пароля.
Сжатие данных
Для экономии дискового пространства или более быстрой передачи по сети можно сжать наш архив. Можно для этого использовать разные подходы — использовать опцию -Z с указанием уровня компрессии от 0 до 9 или передать результат архиватору gzip. Рассмотрим оба примера.
а) С помощью опции -Z:
pg_dump -Z9 users > users.sql.gz
б) С использованием gzip:
pg_dump users | gzip > users.sql.gz
В обоих случаях будет использоваться gzip и перед восстановлением данных необходимо будет извлечь архив с помощью gunzip. Подробнее об этом ниже.
Скрипт для автоматического резервного копирования
Рассмотрим 2 варианта написания скрипта для резервирования баз PostgreSQL в системах Linux, а также приведем пример скрипта для Powershell (Windows).
Linux (bash)
Первый вариант — запуск скрипта от пользователя root для резервирования одной базы. Второй — запуск от пользователя postgres для резервирования всех баз, созданных в СУБД.
Для начала, создадим каталог, в котором разместим скрипт, например:
mkdir /scripts
И сам скрипт:
vi /scripts/postgresql_dump.sh
Вариант 1. Запуск от пользователя root; одна база.
#!/bin/sh
PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
PGPASSWORD=password
export PGPASSWORD
pathB=/backup
dbUser=dbuser
database=db
find $pathB \( -name «*-1[^5].*» -o -name «*-[023]?.*» \) -ctime +61 -delete
pg_dump -U $dbUser $database | gzip > $pathB/pgsql_$(date «+%Y-%m-%d»).sql.gz
unset PGPASSWORD
* где password — пароль для подключения к postgresql; /backup — каталог, в котором будут храниться резервные копии; dbuser — имя учетной записи для подключения к БУБД; pathB — путь до каталога, где будут храниться резервные копии.
* данный скрипт сначала удалит все резервные копии, старше 61 дня, но оставит от 15-о числа как длительный архив. После при помощи утилиты pg_dump будет выполнено подключение и резервирование базы db. Пароль экспортируется в системную переменную на момент выполнения задачи.
Для запуска резервного копирования по расписанию, сохраняем скрипт в файл, например, /scripts/postgresql_dump.sh и создаем задание в планировщике:
crontab -e
3 0 * * * /scripts/postgresql_dump.sh
* наш скрипт будет запускаться каждый день в 03:00.
Вариант 2. Запуск от пользователя postgres; все базы.
#!/bin/bash
PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
pathB=/backup/postgres
find $pathB \( -name «*-1[^5].*» -o -name «*-[023]?.*» \) -ctime +61 -delete
for dbname in `echo «SELECT datname FROM pg_database;» | psql | tail -n +3 | head -n -2 | egrep -v ‘template0|template1|postgres’`; do
pg_dump $dbname | gzip > $pathB/$dbname-$(date «+%Y-%m-%d»).sql.gz
done;
* где /backup — каталог, в котором будут храниться резервные копии; pathB — путь до каталога, где будут храниться резервные копии.
* данный скрипт сначала удалит все резервные копии, старше 61 дня, но оставит от 15-о числа как длительный архив. После найдет все созданные в СУБД базы, кроме служебных и при помощи утилиты pg_dump будет выполнено резервирование каждой найденной базы. Пароль нам не нужен, так как по умолчанию, пользователь postgres имеет возможность подключаться к базе без пароля.
Необходимо убедиться, что у пользователя postgre будет разрешение на запись в каталог назначения, в нашем примере, /backup/postgres.
Зададим в качестве владельца файла, пользователя postgres:
chown postgres:postgres /scripts/postgresql_dump.sh
Для запуска резервного копирования по расписанию, сохраняем скрипт в файл, например, /scripts/postgresql_dump.sh и создаем задание в планировщике:
crontab -e -u postgres
* мы откроем на редактирование cron для пользователя postgres.
3 0 * * * /scripts/postgresql_dump.sh
* наш скрипт будет запускаться каждый день в 03:00.
Права и запуск
Разрешаем запуск скрипта, как исполняемого файла:
chmod +x /scripts/postgresql_dump.sh
Единоразово можно запустить задание на выполнение резервной копии:
/scripts/postgresql_dump.sh
… или от пользователя postgres:
su — postgres -c «/scripts/postgresql_dump.sh»
Windows (Powershell)
Данный скрипт создаст бэкапы для всех баз, кроме служебных:
$Env:PGPASSWORD = ‘password’;
$DateStr = (Get-Date).ToString(«yyyy-MM-dd»)
$BackupPath = ‘C:\TmpBackup’
psql -Atc «SELECT datname FROM pg_database;» | foreach {
if ($_ -notmatch ‘postgres|template1|template0’) {
pg_dump $_ > $BackupPath\$_.$DateStr.sql
}
}
* все резервные копии будут размещены в каталоге C:\TmpBackup.
На удаленном сервере
Если сервер баз данных находится на другом сервере, просто добавляем опцию -h:
pg_dump -h 192.168.0.15 users > /tmp/users.dump
* необходимо убедиться, что сама СУБД разрешает удаленное подключение. Подробнее читайте инструкцию Как настроить удаленное подключение к PostgreSQL.
Дамп определенной таблицы
Запускается с опцией -t <table> или —table=<table>:
pg_dump -t students users > /tmp/students.dump
* где students — таблица; users — база данных.
Если наша таблица находится в определенной схеме, то она указывается вместе с ней, например:
pg_dump -t public.students users > /tmp/students.dump
* где public — схема; students — таблица; users — база данных.
Размещение каждой таблицы в отдельный файл
Также называется резервированием в каталог. Данный способ удобен при больших размерах базы или необходимости восстанавливать отдельные таблицы. Выполняется с ипользованием ключа -d:
pg_dump -d customers > /tmp/folder
* где /tmp/folder — путь до каталога, в котором разместяться файлы дампа для каждой таблицы.
Для определенной схемы
В нашей базе может быть несколько схем. Если мы хотим сделать дамп только для определенной схемы, то используем опцию -n, например:
pg_dump -n public peoples > /tmp/peoples.public.sql
* в данном примере мы заархивируем схему public базы данных peoples.
Только схемы (структуры)
Для резервного копирования без данных (только таблицы и их структуры):
pg_dump —schema-only users > /tmp/users.schema.dump
Также, внутри каждой базы могут быть свои схемы с данными. Если нам нужно сделать дамп именно той схемы, которая внутри базы, используем ключ -n:
pg_dump —schema-only users -n production > /tmp/users.schema_production.dump
* в данном примере мы создадим дамп структуры базы данных users только для схемы production.
Или полный дамп с данными для схемы внутри базы данных:
pg_dump users -n production > /tmp/users.production.dump
Только данные
pg_dump —data-only users > /tmp/users.data.dump
Использование pgAdmin
Данный метод хорошо подойдет для компьютеров с Windows и для быстрого создания резервных копий из графического интерфейса.
Запускаем pgAdmin — подключаемся к серверу — кликаем правой кнопкой мыши по базе, для которой хотим сделать дамп — выбираем Резервная копия:
В открывшемся окне выбираем путь для сохранения данных и настраиваемый формат:
При желании, можно изучить дополнительные параметры для резервного копирования:
После нажимаем Резервная копия — ждем окончания процесса и кликаем по Завершено.
Не текстовые форматы дампа
Другие форматы позволяют делать частичное восстановление, работать в несколько потоков и сжимать данные.
Бинарный с компрессией:
pg_dump -Fc users > users.bak
Тарбол:
pg_dump -Ft users > users.tar
Directory-формат:
pg_dump -Fd users > users.dir
Использование pg_basebackup
Утилита pg_basebackup идет в комплекте с СУБД и позволяет создать резервную копию кластера PostgreSQL. При этом, с ее помощью нельзя снять дамп определенной базы — только целиком все данные и конфигурационные файлы. Для восстановления информации нужно будет разместить полученные файлы в рабочий каталог СУБД.
Пример команды:
pg_basebackup -D /backup
* в данном примере создается резервная копия локального сервера с сохранением данных в каталог /backup.
Если мы хотим забрать данные, подключившись к удаленному серверу, нам нужно обеспечить доступ с правами replication. Для этого в файл pg_hba.conf добавляем строку:
…
host replication all 192.168.0.15/32 trust
…
* где 192.168.0.15 — компьютер, на котором мы будем запускать pg_basebackup.
Не забываем перезапустить службу postgresql, например:
systemctl restart postgresql-14
Теперь можно снимать бэкап кластера:
pg_basebackup -d postgresql://postgres@node1 -D /backup
* в данном примере создается резервная копия для сервера node1 с сохранением ее в каталог /backup.
** обратите внимание, что у нас должен быть возможность подключения к серверу node1 под пользователем postgres с компьютера, где мы запускаем pg_basebackup (для этого мы и меняли настройку в файле pg_hba.conf).
pg_dumpall
Данная утилита делает выгрузку всех баз данных, в том числе системных. На выходе получаем файл для восстановления в формате скрипта.
pg_dumpall > cluster.bak
Утилиту удобно использовать с ключом -g (—globals-only) — выгрузка только глобальных объектов (ролей и табличных пространств).
Для создание резервного копирования со сжатием:
pg_dumpall | gzip > cluster.tar.gz
Восстановление
Нам может понадобиться удалить старую базу. Это можно сделать с помощью SQL-запроса:
=# DROP DATABASE users;
* в данном примере будет удалена база с именем users.
Убедитесь, что удаляете базу с нужным названием на правильном сервере.
Если получаем ошибку на подобие:
ERROR: database «users» is being accessed by other users
… значит база используется приложением. Либо останавливаем его, либо выполняем:
=# SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE datname = ‘users’; DROP DATABASE users;
Также может понадобиться создать базу данных (не потребуется, если делали дамп с опцией -C). Для этого используем SQL-запрос:
=# CREATE DATABASE users WITH ENCODING=’UTF-8′;
* где users — имя базы; UTF-8 — используемая кодировка.
Если мы получим ошибку:
ERROR: encoding «UTF8» does not match locale «en_US»
DETAIL: The chosen LC_CTYPE setting requires encoding «LATIN1».Указываем больше параметров при создании базы:
CREATE DATABASE users WITH OWNER ‘postgres’ ENCODING ‘UTF8’ LC_COLLATE = ‘ru_RU.UTF-8’ LC_CTYPE = ‘ru_RU.UTF-8’ TEMPLATE = template0;
Базовая команда
Синтаксис:
psql <имя базы> < <файл с дампом>
Пример:
psql users < /tmp/users.dump
С авторизацией
При необходимости авторизоваться при подключении к базе вводим:
psql -U dmosk -W users < /tmp/users.dump
* где dmosk — имя учетной записи; опция W потребует ввода пароля.
Из файла gz
Сначала распаковываем файл, затем запускаем восстановление:
gunzip users.sql.gz
psql users < users.sql
Или одной командой:
zcat users.sql.gz | psql users
Определенную базу
Если резервная копия делалась для определенной базы, запускаем восстановление:
psql users < /tmp/database.dump
Если делался полный дамп (всех баз), восстановить определенную можно при помощи утилиты pg_restore с параметром -d:
pg_restore -d users cluster.bak
Определенную таблицу
Если резервная копия делалась для определенной таблицы, можно просто запустить восстановление:
psql users < /tmp/students.dump
Если делался полный дамп, восстановить определенную таблицу можно при помощи утилиты pg_restore с параметром -t:
pg_restore -a -t students users.dump
С помощью pgAdmin
Запускаем pgAdmin — подключаемся к серверу — кликаем правой кнопкой мыши по базе, для которой хотим восстановить данные — выбираем Восстановить:
Выбираем наш файл с дампом:
И кликаем по Восстановить:
Использование pg_restore
Данная утилита предназначена для восстановления данных не текстового формата (в одном из примеров создания копий мы тоже делали резервную копию не текстового формата).
Из бинарника:
pg_restore -Fc users.bak
Из тарбола:
pg_restore -Ft users.tar
С созданием новой базы:
pg_restore -Ft -C users.tar
Мы можем использовать опцию d для указания подключения к конкретному серверу и базе, например:
pg_restore -d «postgresql://dmosk_user:dmosk_pass@localhost/dmosk_base» -Fc users.bak
* в данном примере мы подключимся к локальной базе (localhost) с названием dmosk_base от пользователя dmosk_user с паролем dmosk_pass.
Работа с CSV
Мы можем переносить данные с использованием файлов csv. Это нельзя назвать напрямую резервным копированием, но в рамках данной инструкции материал будет интересен.
Создание файла CSV (экспорт)
Пример запроса (выполняется в командной оболочке SQL):
> COPY (SELECT * FROM public.users WHERE name LIKE ‘А%’) TO ‘/tmp/users.csv’ WITH CSV DELIMITER ‘;’ HEADER;
* в данном примере мы выгрузим все данные для таблицы users в схеме public, где значение поля name начинается с буквы А. Результат будет сохранен в файл /tmp/users.csv. Также мы указываем, что в качестве разделителя данных нужно использовать точку с запятой и первой строкой сделать заголовок.
Также мы можем сделать выгрузку, но сделать вывод в оболочку и перенаправить его в файл:
psql -d «postgresql://pg_user:pg_pass@localhost:5432/pg_databasename» -c «COPY (SELECT * FROM public.users WHERE name LIKE ‘А%’) TO STDIN WITH CSV DELIMITER ‘;’ HEADER;» > /tmp/users.csv
Импорт данных из файла CSV
Также можно выполнить запрос в оболочке SQL:
> COPY public.users FROM ‘/tmp/test.csv’ DELIMITER ‘;’ CSV HEADER;
Или перенаправить запрос через STDOUT из файла:
psql -d «postgresql://pg_user:pg_pass@localhost:5432/pg_databasename» -c «COPY public.users FROM STDOUT DELIMITER ‘;’ CSV HEADER;» < /tmp/users.csv
* в нашем примере мы выполним импорт данных из ранее созданного файла /tmp/users.csv в таблицу users.
Возможные ошибки
Рассмотрим некоторые проблемы, с которыми можно столкнуться при работе с дампами PostgreSQL.
Input file appears to be a text format dump. please use psql.
Причина: дамп сделан в текстовом формате, поэтому нельзя использовать утилиту pg_restore.
Решение: восстановить данные можно командой psql <имя базы> < <файл с дампом> или выполнив SQL, открыв файл, скопировав его содержимое и вставив в SQL-редактор.
No matching tables were found
Причина: Таблица, для которой создается дамп не существует. Утилита pg_dump чувствительна к лишним пробелам, порядку ключей и регистру.
Решение: проверьте, что правильно написано название таблицы и нет лишних пробелов.
Too many command-line arguments
Причина: Утилита pg_dump чувствительна к лишним пробелам.
Решение: проверьте, что нет лишних пробелов.
Aborting because of server version mismatch
Причина: несовместимая версия сервера и утилиты pg_dump. Может возникнуть после обновления или при выполнении резервного копирования с удаленной консоли.
Решение: нужная версия утилиты хранится в каталоге /usr/lib/postgresql/<version>/bin/. Необходимо найти нужный каталог, если их несколько и запускать нужную версию. При отсутствии последней, установить.
No password supplied
Причина: нет системной переменной PGPASSWORD или она пустая.
Решение: либо настройте сервер для предоставление доступа без пароля в файле pg_hba.conf либо экспортируйте переменную PGPASSWORD (export PGPASSWORD или set PGPASSWORD).
Неверная команда \
Причина: при выполнении восстановления возникла ошибка, которую СУБД не показывает при стандартных параметрах восстановления.
Решение: запускаем восстановление с опцией -v ON_ERROR_STOP=1, например:
psql -v ON_ERROR_STOP=1 users < /tmp/users.dump
Теперь, когда возникнет ошибка, система прекратит выполнять операцию и выведет сообщение на экран.
Подготовка к созданию резервных копий при использовании СУБД PostgreSQL
Для того, чтобы резервные копии создавались по расписанию, необходимо выполнить настройку ОС Windows и СУБД PostgreSQL. Для настройки Windows необходимо перейти в Переменные среды. В Windows 10 находятся в разделе Изменение системных переменных среды:
В открывшемся диалоге переходим в окно Системные переменные, находим переменную Path
Нажимаем Изменить…, затем Обзор… и выбираем месторасположение папки bin c утилитами PostgreSQL (по умолчанию: C:\Program Files\PostgreSQL\14\bin):
На этом настройка ОС Windows завершена.
Для настройки PostgreSQL необходимо скачать и установить утилиту pgAdmin. Обычно утилита входит в стандартный дистрибутив postgreSQL и если при установке флажок не был снят, ничего скачивать не нужно. Достаточно перейти в меню «Пуск» в папку PostgreSQL и запустить ее из этой папки (ссылка на официальный сайт для скачивания: https://www.postgresql.org/ftp/pgadmin/pgadmin4/v6.20/windows/ ):
Открыть pgAdmin и перейти в настройки (Preferences):
В настройках находим Binary Paths и в специальном поле, в зависимости от версии PostgreSQL, вводим путь к утилитам PostgreSQL. В разных версия PostgreSQL вид окна может отличаться, но наименование PostgreSQL Binary Path
Нажимаем Save (Сохранить). На этом настройка PostgreSQL завершена.
Запускаем TDMS Фарватер Сервер Конфигуратор, для этого переходим в меню Пуск. Находим папку Csoft и запускаем TDMS Фарватер Сервер Конфигуратор
и переходим в окно Расписание
Добавляем задачу по расписанию. Триггер может быть разным, повторение после старта, ежедневный или резервная копия по дням недели в определённое время. Пример расписания еженедельного резервного копирования по определённым дням недели:
Обратите внимание, что время начала задавать обязательно, а время окончания можно не задавать, программа завершит выполнение автоматически.
Переходим на вкладку «Параметры». На этой вкладке присутствует параметр «fileName»
Адрес для хранения резервных копий по умолчанию может быть изменён. Так же можно добавить или удалить теги, содержащиеся в имени файла резервной копии. Папка в сети также может быть использована в качестве директории для хранения резервной копии.
Значение тегов входящих в наименование резервной копии базы данных:
{host} - хост сервера
{port} - порт сервера
{workfolder} - рабочая папка сервера
{serverId} - уникальный id сервера в БД TDMS
Текущий день:
{D} - один символ, 1, 31
{DD} - два символа, 01, 31
Текущий месяц:
{M} - один символ, 1, 12
{MM} - два символа, 01, 12
Текущий год:
{YY} - два символа 01, 99
{YYYY} - четыре символа, 2001, 1999
Текущий час:
{h} - один символ, 1, 14
{hh} - два символа, 01, 14Текущая минута:
{m} - один символ, 1, 14
{mm} - два символа, 01, 14
Текущая секунда:
{s} - один символ, 1, 14
{ss} - два символа, 01, 14
Текущая дата:
{date} - автоматически форматирует текущую дату по формату "ДД-ММ-ГГГГ-ЧЧ-ММ-СС" Рекомендуется настроить регулярное резервное копирование базы данных (на случай
аппаратных или программных сбоев), причем лучше всего с сохранением резервных копий за последние несколько дней,
например семь (за последнюю неделю).
Для этого в MS SQL Server можно использовать либо встроенный в SQL Server планировщик заданий –
«SQL Server Agent» (в бесплатную версию не входит), либо стандартный «Планировщик Windows» в сочетании с утилитой
SQLCMD.EXE, которая позволяет выполнять запросы к SQL Server из командной строки. В PostgreSQL можно использовать
стандартный «Планировщик Windows» в сочетании с утилитой pg_dump.exe. В планировщике необходимо создать как минимум
семь заданий (по одному на каждый день недели), каждое из которых будет (раз в неделю) заменять один из семи файлов,
содержащих соответствующую резервную копию базы данных.
Кроме того, файлы резервных копий рекомендуется хранить не только на жестком диске компьютера, где
установлен SQL Server, но и дублировать их на ленту или жесткий диск другого компьютера в сети. Для этого можно
использовать либо специальное ПО, которое позволяет делать резервные копии всего диска, либо с помощью того же
планировщика копировать файлы на ленту или другой компьютер (вторым шагом).
- С помощью «Планировщика Windows» (для бесплатной версии)
- С помощью «SQL Server Agent» (в бесплатную версию не входит)
С помощью «Планировщика Windows» (для бесплатной версии)
Чтобы создать задание в «Планировщике Windows» надо:
Запустить программу «Блокнот» (Пуск->Все программы->Стандартные->Блокнот) и
ввести следующие две строки, после чего сохранить их в виде командного файла (*.BAT):
Для MS SQL Server:
SQLCMD -S (local) -E -Q «BACKUP DATABASE AltaSVHDb TO DISK = ‘D:\BACKUP\AltaSVHDb_monday.bak’ WITH INIT, NOFORMAT, SKIP, NOUNLOAD»
XCOPY D:\BACKUP\AltaSVHDb_monday.bak\BACKUP_SERVER\Folder\*.* /Y
где (local) – имя сервера (в случае установки именованного
экземпляра SQL Server надо указать имя полностью: «ИМЯ_КОМПА\SQLEXPRESS»),
AltaSVHDb – имя базы данных, D:\BACKUP\AltaSVHDb_monday.bak – имя файла для создания в нем резервной копии (будет различаться по
дням недели), BACKUP_SERVER – имя компьютера, на который будет выполняться
дополнительное копирование, Folder – папка на этом компьютере (к ней должен
быть предоставлен общий доступ).
Для PostgreSQL:
SET PGPASSWORD=password
«C:\Program Files\PostgreSQL\12\bin\pg_dump.exe» —file=»C:\BACKUP\pg_gtd.backup» —dbname=»gtd»
—username=»username» —format=custom —port=5432 –w
где необходимо указать корректный путь к утилите pg_dump.exe, file – имя результирующего файла, dbname — имя архивируемой БД, username — имя пользователя и format – формат резервной копии.
Формат лучше указывать custom (специальный сжатый формат), так как он совместим с восстановлением базы командой pg_restore.
Пароль задается отдельно в переменной окружения PGPASSWORD (первая строка).
Запустить мастер планирования заданий (Панель управления->Назначенные задания->Добавить
задание) и нажать кнопку «Далее»:
Нажать кнопку «Обзор» и указать путь к командному файлу (*.BAT), созданному на шаге a):
Указать имя для задания, выбрать вариант запуска «еженедельно» и нажать кнопку
«Далее»:
Поставить галочку возле нужного дня недели, а в поле «Время начала» указать время,
когда должен запускаться процесс резервного копирования (обычно это делается ночью), затем нажать кнопку
«Далее»:
Ввести имя пользователя и пароль (дважды) учетной записи ОС, от имени которой будет выполняться
задание, и нажать кнопку «Далее»:
Внимание! Чтобы задание успешно выполнялось необходимо предоставить
указанной здесь учетной записи (домена или локального компьютера) права записи в вышеупомянутую папку
«\\BACKUP_SERVER\Folder», а также настроить доступ к самому SQL Server.
Нажать кнопку «Готово»
Примечание. Чтобы проверить работоспособность созданного задания,
необходимо в списке заданий (Панель управления->Назначенные задания) нажать правой кнопкой мыши на интересующем
задании и в контекстном меню выбрать пункт «Выполнить», затем убедиться, что файл резервной копии БД
успешно создался по тем путям, которые были указаны на шаге a).
С помощью «SQL Server Agent» (в бесплатную версию не входит)
Чтобы создать задание в «SQL Server Agent» надо:
Запустить утилиту SQL Server Management Studio и подключиться к серверу под учетной записью
администратора.
В левой части окна нажать правой кнопкой мыши на разделе «Объекты сервера/Устройства
резервного копирования» и в контекстном меню выбрать пункт «Создать устройство резервного
копирования»:
В поле «Имя устройства» ввести имя, которое будет ассоциироваться с файлом резервной
копии БД, при необходимости изменить путь в поле «Файл» и нажать «ОК»:
В левой части окна нажать правой кнопкой мыши на разделе «Агент SQL Server/Задания» и в
контекстном меню выбрать пункт «Создать задание»:
В поле «Имя» ввести имя задания:
На странице «Шаги» нажать кнопку «Создать»:
В появившемся окне ввести имя в поле «Имя шага», проверить, что в поле
«Тип» выбрано «Сценарий Transact-SQL (T-SQL)», а в поле «Команда» ввести строку:
BACKUP DATABASE AltaSVHDb TO AltaSVHDb_monday WITH INIT, NOFORMAT, SKIP, NOUNLOAD
где «AltaSVHDb» – имя базы данных,
«AltaSVHDb_monday» – имя устройства резервного копирования, созданного на шаге c)
(будет различаться по дням недели):
В предыдущем окне нажать кнопку «ОК», в результате на странице «Шаги»
должна появиться строка:
Чтобы файл резервной копии БД сразу копировался на другой компьютер в сети необходимо повторить
пункты f) – h), в окне «Создание шага задания» выбрав в поле «Тип» значение
«Операционная система (CmdExec)», а в поле «Команда» указав строку:
XCOPY D:\MSSQL\BACKUP\AltaSVHDb_monday.bak \\BACKUP_SERVER\Folder\*.* /Y
где «D:\MSSQL\BACKUP\AltaSVHDb_monday.bak» – путь, указанный на
шаге c) (будет различаться по дням недели), «BACKUP_SERVER» – имя компьютера, на
который будет выполняться копирование, «Folder» – папка на этом компьютере (к ней
должен быть предоставлен общий доступ):
Примечание. Чтобы копирование файла успешно выполнялось необходимо
запускать «SQL Server Agent» под учетной записью домена Windows, для которой предоставлены права записи
в вышеупомянутую папку (см. также «SQL2005_installation.doc» или
«SQL2008_installation.doc»), а также настроен доступ к самому SQL Server (см. раздел «Настройка
прав доступа к БД», включить эту учетную запись надо в роль «sysadmin» на странице
«Серверные роли», а на страницах «Сопоставление пользователей» и «Защищаемые
объекты» ничего не делать).
На странице «Расписания» нажать кнопку «Создать»:
Ввести имя в поле «Имя», проверить, что в поле «Тип расписания» выбрано
значение «Повторяющееся задание», а в поле «Выполняется» – «Еженедельно».
Поставить галочку возле нужного дня недели (остальные снять), а в поле «Однократное задание» указать
время, когда должен запускаться процесс резервного копирования (обычно это делается ночью):
В предыдущем окне нажать кнопку «ОК», в результате на странице «Расписания»
должна появиться строка:
Нажать кнопку «ОК».
Примечание. Чтобы проверить работоспособность созданного задания,
необходимо в разделе «Агент SQL Server/Задания» нажать правой кнопкой мыши на интересующем задании и в
контекстном меню выбрать пункт «Запустить задание на шаге», в появившемся окне выбрать первый шаг
данного задания и нажать «ОК». Далее появится окно отображающее ход выполнения задания. Если выполнение
задания закончится с ошибкой, то подробное описание ошибки можно увидеть вызвав пункт «Просмотр журнала»
того же контекстного меню.
What is PgAgent?
PgAgent is a basic scheduling agent that comes packaged with PgAdmin III (since pre-8.0 or so) and that can be managed by PgAdmin III.
PgAdmin III is the database administration tool that comes packaged with PostgreSQL.
For those familiar with
unix/linux cronjobs and crontab structure, PgAgent’s scheduling structure should look very familiar.
For those familiar with using Microsoft SQL Server Scheduling Agent or Windows Scheduling Tasks, but not used to crontab structure,
the PgAdmin III Job Agent interface to PgAgent should look very welcoming, but the schedule tab may look a little unfamiliar.
PgAgent can run both PostgreSQL stored functions and sql statements as well as OS shell commands and batch tasks.
Why use PgAgent over other agents such as cronjob, Microsoft Windows Scheduled Tasks, or Microsoft SQL Server Agent?
For one thing, since PgAgent runs off of standard Postgres tables,
you can probably more easily programmatically change jobs from it from within PostgreSQL sql calls
that insert right into the respective PgAgent pga_job, pga_jobstep, pga_jobagent, pga_schedule tables to roll your own App integrated scheduler.
Compared to CronTab, PgAgent has the following advantages:
- You can have multiple steps for a job without having to resort to a batch script.
- You can have multiple schedules for a job without having to repeat the line.
- Is cross platform
- For running PostgreSQL specific jobs such as stored function calls or adhoc sql update statements etc. it is a bit easier granted the PostgreSQL account used is a super user or has sufficient rights to the dbs.
Compared to Windows Scheduled Tasks — PgAgent has the following advantages:
- You can go down to the minute level
- Have several steps per job
- Have multiple schedules per job
- Is cross platform
- For running PostgreSQL specific jobs such as stored function calls it is easier than using windows scheduled tasks.
Compared to SQL Server Agent — PgAgent has the following advantages:
- SQL Server Agent comes only with Microsoft SQL Server Workgroup and above so not an option say for people running SQL Server Express editions or no SQL Server install.
- Is cross platform
Some missing features in PgAgent which would be nice to see in later versions would be some sort of notification system similar
to what SQL Server Agent has that can notify you by email when things fail and a maintenance wizard type complement tool similar to what SQL Server 2005 Maintenace Wizard provides that allows
users to walk thru a set of steps to build automated backup/DB Maintenance tasks. This is a bit tricky since it would need to be cross-platform.
Granted the job history display in PgAdmin that provides success and time taken to perform task is a nice touch and makes up for some of this lack and you can always roll your own by running some monitor to check the job event logs.
How to install PgAgent
Note the docs describe how to install PgAgent: http://www.pgadmin.org/docs/1.8/pgagent-install.html,
but the example to install it in a db called PgAdmin seems to send people off in the wrong direction. We shall highlight the areas where people most commonly screw up in installation, but for master
reference, refer to the official PgAgent install docs listed above.
While you can install PgAgent in any database, to our knowledge, you can only administer it via PgAdmin III if it is installed in the maintenance database which is usually the database called postgres. For ISPs, having the ability to install it in any db and rolling your own agent interface may be a useful feature.
Other note that is not explicitly stated, but is useful to know: PgAgent need not be installed on the same Server/Computer as your PostgreSQL server. It just needs to have the pgAgent files, which you can get by installing PgAdmin III or copying over the necessary files. PgAgent service/daemon also needs necessary access to the PostgreSQL database housing the job tables. If you are using it to backup databases to a remote server, the account it runs under will also need network file access or ftp access to the remote server. You can also have multiple PgAgent’s running on different servers that use the same schedule tables.
To install PgAgent, there are basically three steps
- Make sure you have plpgsql language installed in the postgres database. Which you do with the sql command runin postgres database.
CREATE TRUSTED PROCEDURAL LANGUAGE 'plpgsql' HANDLER plpgsql_call_handler VALIDATOR plpgsql_validator; - Run the PgAgent.sql using PgAdmin III or psql and run it in the db postgres — found in /path/to/PgAdmin III/1.8/scripts (on windows this is usually in «C:/Program Files/PgAdmin III/1.8/scripts»). This creates a schema catalog in the postgres database called pgAgent with the helper pgagent tables and functions.
- Install the PgAgent server service/Daemon process: On windows — you run a command something like below — the -u user is not the PostgreSQL user but the computer user that the PgAgent will be running under.
"C:\Program Files\PostgreSQL\8.2\bin\pgAgent" INSTALL pgAgent -u postgres -p somepassword hostaddr=127.0.0.1 dbname=postgres user=postgresAfter you install on Windows — you should go into Control Panel -> Administrative Tools -> Services — «PostgreSQL Scheduling Agent — pgAgent» -> and start the service.
If the service doesn’t start — most likely you typed the postgres computer account password in wrong. Simply switch to the Log On tab and retype the password or change to use a different account.Keep in mind — if you wish PgAgent to run scripts that require File Network access (e.g. copying files to network servers, you need to have the service run under a network account that has
network access to those servers.On Unix/Linux systems — it varies how its installed. It is usually run under the root account and the line is added to startupscripts usually /etc/init.d or I think on MacOSX its /etc/xinetd.d
/path/to/pgagent hostaddr=127.0.0.1 dbname=postgres user=postgresNote: as the docs say — its probably best not to specify the password. Instead — you can set the postgres account to be trusted from server you have PgAgent installed on or use the ~pgpass approach.
Once you have PgAgent installed, and open/refresh PgAdmin III, you should see another section called Jobs that looks like below:
If per chance, you do not see the new Jobs icon, make sure that you have PgAgent jobs checked by going to File->Options->Display
Creating Backup Jobs
Creating backup jobs is done with a shell script of some sort. In Windows this can be done with a .bat file and specifying the file in the PgAgent job or by writing the command
directly in the PgAgent job. In Linux/Unix — this is done with a .sh file and specifying that in the PgAgent job or writing the command directly in the PgAgent job.
Generally we go with a .bat or .sh file, because using a shell script allows you more granular control — such as backing up multiple databases or having
a separately date named file for each daily backup.
Below is a sample batch script for Windows that backs up selected databases and then does a full Pg_dumpall as well
@echo off
REM - backup directory can be a file server share that the PgAgent windows service account has access to
set BACKUPDIR="/path/to/backup/"
set PGHOST="localhost"
set PGUSER="postgres"
set PGBIN="C:/Program Files/PostgreSQL/8.2/bin/"
for /f "tokens=1-4 delims=/ " %%i in ("%date%") do (
set dow=%%i
set month=%%j
set day=%%k
set year=%%l
)
for /f "tokens=1-3 delims=: " %%i in ("%time%") do (
set hh=%%i
set nn=%%j
)
REM - It would be nice to use gzip in the pg_dumpall call (or if pg_dumpall supported compression as does the pg_dump)
REM here as we do on the linux/unix script
REM - but gzip is not prepackaged with windows so requires a separate install/download.
REM Our favorite all purpose compression/uncompression util for Windows is 7Zip which does have a command-line
%PGBIN%pg_dumpall -h %PGHOST% -U %PGUSER% -f %BACKUPDIR%fullpgbackup-%year%%month%.sql
%PGBIN%pg_dump -i -h %PGHOST% -U %PGUSER% -F c -b -v -f "%BACKUPDIR%db1-%year%%month%%day%%hh%.compressed" db1
%PGBIN%pg_dump -i -h %PGHOST% -U %PGUSER% -F c -b -v -f "%BACKUPDIR%db2-%year%%month%%day%%hh%.compressed" db2
Below is an equivalent Linux/Unix backup shell script
#!/bin/bash
#backup directory can be a file server share that the PgAgent daemon account has access to
BACKUPDIR="/path/to/backup"
PGHOST="localhost"
PGUSER="postgres"
PGBIN="/usr/bin"
thedate=`date --date="today" +%Y%m%d%H`
themonth=`date --date="today" +%Y%m`
#create a full backup of the server databases
$PGBIN/pg_dumpall -h $PGHOST -U $PGUSER | gzip > $BACKUP_DIR/fullbackup-$themonth.sql.gz
#put the names of the databases you want to create an individual backup below
dbs=(db1 db2 db3)
#iterate thru dbs in dbs array and backup each one
for db in ${dbs[@]}
do
$PGBIN/pg_dump -i -h $PG_HOST -U $PGUSER -F c -b -v -f $BACKUPDIR/$db-$thedate.compressed $db
done
#this section deletes the previous month of same day backup except for the full server backup
rm -f $BACKUPDIR/*`date --date="last month" +%Y%m%d`*.compressed
Save the respective above scripts in a (dailybackup.bat for windows pgagent) or (dailybackup.sh for Linux/Unix pgagent) file.
For bash unix scripts make sure it has unix line breaks (not windows) —
you may use dos2unix available on most linux/unix boxes to convert windows line breaks to unix linebreaks.
When saving as .sh make sure to give the .sh file execute rights using chmod on linux/unix.
Also change the db1, db2 and add additional lines for other databases you wish to backup to the respective names of your databases and add additional as needed.
cd /path/toscriptfolder
dos2unix dailybackup.sh
chmod 771 dailybackup.sh
/path/toscriptfolder/dailybackup.sh #this is to test execution of it
771 permissions gives execute rights to public and all rights (read,write,execute) to owner and group. Alternatively you could do 640 instead which would remove all rights from public, but then you will need to do a Change owner chown
to change ownership to account you are running PgAgent under. Note the above script and commands we tested on a CentOS box so commands and script may vary if you are running on MacOSX or another Linux variant.
A couple of notes about the above which are more preferences than anything.
- We like to create a dump all backup which would contain all the
databases and just overwrite it daily but keep one for each month. This is more for major disaster recovery than anything else. - We prefer the Postgres Native Compressed format for our date stamped backups.
The reason for that is with the pg_dump compressed format, it takes up less space, deals with binary objects well, and has the benefit that you can restore individual database objects for it. This is very useful
in cases where someone screws up and they come back to you days or months later. - You will note that the date stamp format we have included includes the Hour and would create a file something of the form — dbname-2008010102.compressed
— the reason for that is that it sorts nicely by name and date of backup and if disk space was an issue, you could easily include a line that deletes say backups older than a month. Going down to the hour level
allows us to quickly create emergency backups by clicking the Run Now on PgAdmin Jobs interface that wouldn’t overwrite the current days backup. - In practice we also like to have at least one of the backups ftped to a remote location and include that as part of the
script and/or backed up to a remote server that has good connectivity with the pgagent server. This helps in cases of complete server failure. This step is not included
here since its too OS and install specific to get into. - Open up PgAdmin — navigate to jobs section, right mouse click and click New Job —
- Fill in the properties tab as shown in this snapshot —
- Switch to the Steps tab and select Batch and fill in details as shown —
- Switch to the Definition tab and type in the path to the batch or sh file. Keep in mind the path is in context of the PgAgent service. So if you have PgAgent installed on a server that is different from the PostgreSQL server, then
make sure the paths in your script and path to the file is set as if you were the PgAgent account on PgAgent server. As show here
and then click the OK button. - Next switch to the Schedules tab and click to add a Schedule.
- Next Switch to Times tab. The reason we are skipping the Days tab is that anything you do not fill in is assumed to be All since we want all days, we leave that tab blank.
This diagram shows setting the backup time to be 02:15 AM every day —
Next to create the PgAgent backup job follow the following steps.
Once the job is saved, the hierarchy in PgAgmin looks like the below snapshots
Clicking on the Daily Schedule Icon
Clicking on the respective objects in the Job Hierarchy such as a Step or schedule gives you detailed information about each of those.
The statistics tab gives you details such as how long a step took, whether or not it succeeded or failed and when it was run.
Keep in mind that while PgAgent is closely related to PostgreSQL and uses PostgreSQL for scheduling and logging, there isn’t any
reason you can not use it as an all-purpose scheduling agent. In fact we use it to backup MySQL as well as PostgreSQL databases, do automated web crawls, download
remote backups etc. Using the SQL Job Type option, you can use it to run postgresql functions that rebuild materialized views, do other standard postgresql specific sql maintenance tasks, etc. On top
of that PgAdmin provides a nice interface to it that you can use on any computer (not just the one running PgAgent).