Доброе утро.
опрос скорее всего глупый, но прошу сильно не пинать начинаю только разбирать pg_basebackup.
Исходные данные:
Используется Postgresql 10.3
Настраиваю pg_basebackup для регламентного создания резервной копии. Скрипт написал на powershell - все ок, но вопрос в другом.

Политика резервного копирования у нас - восстановление на ночной бэкап (WAL не используется)

Собственно вопрос:
1. Могу ли я при такой схеме в параметр
--wal-method передать значение none и на что это повлияет? Т.е. логика у меня такая - WAL не используется, не нужно его и бэкапить.
2. Вопрос связан с п. 1, при использовании --wal-method
отличного от значения none (т.е. в процессе бэкапа сохранять также WAL). Нужно ли мне для восстановления кластера PostgreSQL при необходимости помимо base.tar.gz восстанавливать pg_wal.tar.gz? И как это правильно делать?
Ведь я правильно понимаю, что общий алгоритм восстановления из pg_basebackup это остановить текущий кластер и инициализировать этот же кластер заменив его данные на то, что есть в резервной копии pg_basebackup? (Ну или инициализировать новый кластер с помощью pg_ctl -D путь к резервной копии)
3. Вопрос по параметру --checkpoint: Что мне грозит, если я буду использовать fast?
Ну и пункт 4:
PostgreSQL используется под Windows (знаю, что лучше под linux, но пока в требованиях стоит Windows). Смотрим настройки pg_hba.conf, чтобы сделать возможность подключаться скрипту планировщика без пароля. Использовать .pgpass не особо хочется, поэтому и смотрим в сторону pg_hba.

В linux, насколько я помню, мы использовали аутентификацию с типом peer или ident для localhost и она прекрасно отрабатывала.
А какой тип аутентификации можно использовать для Windows? Хочется завязать определенного пользователя операционной системы к кластеру PostgreSQL. У клиента нет домена (обычный небольшой сервер). По идее можно для localhost поставить trust и не парится, но хочется рассмотреть еще варианты.

mefman, Melkij

Видимо я неправильно применяю терминологию или недостаточно компетентен - прошу простить.

Я имел ввиду, что политика резервного копирования не предполагает восстановление на момент времени.

Касательно версии PostgreSQL - он используется для баз 1С: предприятия, поэтому такая экзотика (на новых версиях с патчами от фирмы 1С есть некоторые проблемы).

Полагаю Melkij правильно указал, что у меня есть WAL с момента запуска процедуры резервного копирования с помощью pg_basebackup. Т.е. после создания бэкапа в папке есть два файла:
base.tar.gz
pg_wal.tar.gz

Подскажите, правилен ли будет такой метод восстановления?
1. Остановить службу PostgreSQL
2. Распаковать в каталог (пути из головы для примера) D:\recovery архив base.tar.gz
3. В папку D:\recovery\pg_wal распаковать архив pg_wal.tar.gz
4. Инициализировать кластер pg_ctl -D D:\recovery

Или я где-то не прав?

Правильно ли я использовал архив pg_wal.tar.gz, который создан в процессе архивации?

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

Melkij,

Можете подробнее разъяснить фразу Melkijу вас нет бэкапов

Это из-за того, что я неправильно применил терминологию?

Maxim Boguk,

pg_dump сейчас используется, но я где-то читал, что он создает не консистентный бэкап базы данных. Поэтому, для надежности, используется pg_basebackup (т.е. фактически есть два бэкапа для БД - это pg_dump и pg_basebackup)

Melkij,

Спасибо за ответ.

У меня видимо вот вся путаница из-за непонимания механизмов работы WAL в PostgreSQL. Получается даже если у меня не используется PITR, то при использовании pg_basebackup он все равно есть?

Может быть у Вас есть стоящие ссылки, которыми можно в меня кинуть и отправить читать?

Касательно вот этого, я попробовал на тестовом сервере и получился такой лог:
< 2019-11-12 10:54:52.665 MSK >LOG: redo starts at 2/AE000028
< 2019-11-12 10:54:52.746 MSK >LOG: consistent recovery state reached at 2/AE0091D8
< 2019-11-12 10:54:52.747 MSK >LOG: invalid record length at 2/AF000198: wanted 24, got 0
< 2019-11-12 10:54:52.747 MSK >LOG: redo done at 2/AF000170
< 2019-11-12 10:54:52.748 MSK >LOG: last completed transaction was at log time 2019-11-12 04:04:00.378673+03
< 2019-11-12 10:54:53.310 MSK >LOG: database system is ready to accept connections

После этого база стала доступна и в ней стало возможно работать. При этом файл backup-label был переименован в backup-label.old. Есть информация, что нужно смотреть в логе? Я изначально думал, что он не запустится т.к. потребуется еще файл recovery.conf, а он в итоге и не потребовался

BigBudda, Melkij

Огромное спасибо за подробные ответы - буду тщательнее читать документацию и пытаться вникнуть!

Melkij,
А подскажите пожалуйста еще по вот этому моменту:
Melkijpg_dump консистентен и более того транзакционен.

Так было всегда? Или были какие-то особенности у старых версий?
Я также читал документацию postgresql и не нашел там подтверждения моим словам (то что он якобы не консистентен).

Есть ли какие-нибудь минусы у pg_dump о которых нужно помнить? И в чем минусы относительно pg_basebackup?