Назад | Перейти на главную страницу

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

Я пытаюсь настроить сценарий резервного копирования на сервере Windows. Я использовал pgAgent (планирование для pgAdmin) для запуска сценария резервного копирования. Никаких проблем со скриптом резервного копирования.

Однако мои рабочие места работают не так, как следовало бы. Я установил и расписание, и шаги.

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

Я запускаю сервис так: "C:\Program Files\pgAdmin III\pgAgent" INSTALL pgAgent -u postgres -p secret hostaddr=127.0.0.1 dbname=pgadmin user=postgres

И я получаю сообщение об ошибке, сообщающее мне, что произошла ошибка с данными для входа, хотя я знаю, что это правильно. Когда я захожу в службы (панель управления -> администрирование -> службы), я могу запустить службу с локальным пользователем.

Может в этом проблема?

Где я могу посмотреть или изменить разрешения для пользователя postgres?

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

  1. Создайте пользователя специально для резервного копирования, назовем его «резервные копии». Вы можете использовать createuser из вашей установки PostgreSQL.

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

  3. Разрешите ему входить в систему с локального хоста только с использованием пароля (механизм «md5»), или если вы настраиваете игру как пользователя на своем компьютере с MS Windows и используете механизм «идент». Вам нужно будет изменить pg_hba.conf файл, чтобы обеспечить соблюдение любого из этих действий и ограничения на вход только с localhost.

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

Подробности этого метода можно найти на http://wiki.postgresql.org/wiki/Automated_Backup_on_Windows.

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

Postgres очень гибок - есть несколько способов получить хорошую, пригодную для использования резервную копию (и многие из лучших не требуют использования pgAgent - вы можете создавать сценарии с помощью обычных инструментов ОС).

nearora уже описал использование pg_dumpall что может быть для вас жизнеспособным.

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

Вариант 2: резервное копирование на уровне файловой системы

Обычно это делается путем выключения сервера и захвата PGDATA каталог.
Если вы не можете выключить сервер, тогда вопреки тому, что здесь сказано в руководстве, ты жестяная банка получить полезную резервную копию, не выключая сервер. Просто сделайте «базовую резервную копию», как если бы вы настраивали WAL / PITR ведомый.

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


Вариант 3: резервное копирование ведомого

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

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

Основным недостатком является то, что для этого требуется подчиненный сервер, и вы должны убедиться, что Postgres остановлен на подчиненном сервере. перед ты хватаешь PGDATA каталог и не запускается снова, пока вы не закончите захват файлов.
Вам также необходимо обеспечить завершение резервного копирования в разумные сроки, чтобы сегменты WAL, которые вам нужны, чтобы догнать мастер, по-прежнему были доступны. На практике это будет проблемой только для кластеров с ЧРЕЗВЫЧАЙНО высокие нагрузки записи, или если вы сделаете что-то вроде VACUUM FULL на ведущем устройстве, пока выполняется резервное копирование ведомого.

Я настраиваю pgAdmin таким образом

pgagent.exe INSTALL pgAgent -u postgres -p secret host=localhost dbname=pgadmin user=postgres

Затем вам нужно настроить файл pgpass.conf в пользовательском каталоге postgres, под winxp он находится в Application Data / postgres / pgpass.conf, а под win7 он должен быть appdata / local / postgres / pgpass.conf (не уверен на 100%)

Это определено здесь http://wiki.postgresql.org/wiki/Pgpass

hostname:port:database:username:password

это позволяет pgAgent получить доступ к серверу postgreSQL, тогда для вашего пользователя будет создан pgpass, когда вы запомните пароль для pgAdmin.

Без этого pgpass pgAgent не может получить доступ к базе данных.