# Часто задаваемые вопросы > Часто задаваемые вопросы о резервном копировании, восстановлении, настройке и устранении неполадок pgBackRest. --- Индекс LLMS: [llms.txt](/ru/llms.txt) --- -------- ## Введение {#introduction} В этом разделе приведены подробные ответы на отдельные вопросы, которые могут быть рассмотрены в руководстве пользователя, справочнике по конфигурации или справочнике команд, а могут и не входить в них. Если здесь нет ответа на конкретный вопрос, полезным источником информации также может стать [список проблем pgBackRest на GitHub](https://github.com/pgbackrest/pgbackrest/issues). -------- ## Что делать при ошибке «could not find WAL segment»? {#what-if-i-get-the-could-not-find-wal-segment-error} У этой ошибки может быть множество причин, в том числе: - неверно настроенная команда `archive_command` - ошибки в файлах конфигурации pgBackRest - проблемы с сетью или правами доступа - ошибки в настройке стороннего продукта (например, S3, Swift или Minio) - большая очередь WAL, ожидающих архивирования Рекомендуется: - проверить `archive_command` в PostgreSQL - проверить настройки pgBackRest на каждом сервере (например, параметры `pg*` задаются на сервере репозитория, а параметры `repo*` — на сервере PostgreSQL) - выполнить команду `check`, задав для `--archive-timeout` значение больше указанного в файле конфигурации pgBackRest (или значения по умолчанию), чтобы проверить, не требуется ли больше времени для обработки очереди WAL. Если система генерирует большой объём WAL, стоит настроить [асинхронное архивирование](/ru/docs/pgbackrest/user-guide/#asynchronous-archiving) -------- ## Как вручную удалить набор резервной копии? {#how-do-i-manually-purge-a-backup-set} Полный набор резервной копии можно удалить с помощью параметра `--set`, как описано в разделе [Справочник команд: Expire](/ru/docs/pgbackrest/command/expire/). -------- ## Как задать отдельные настройки для каждой команды? {#how-can-i-configure-options-independently-for-each-command} pgBackRest позволяет задавать параметры в файле конфигурации отдельно для каждой команды. Эта возможность и приоритет параметров описаны в разделе [Настройка stanza кластера](/ru/docs/pgbackrest/user-guide/#configure-cluster-stanza). Например, параметр `process-max` можно настроить для каждой команды: ```ini [global] # used where not overridden process-max=2 [global:backup] # more cores for backup process-max=4 [global:restore] # all the cores for restore process-max=8 [global:archive-push] # more cores for archive-push process-max=3 [global:archive-get] # fewer cores for archive-get process-max=1 ``` -------- ## Можно ли использовать точки в имени бакета S3? {#can-i-use-dots-periods-in-my-s3-bucket-name} RFC-2818 не допускает, чтобы подстановочные знаки соответствовали точке (.), поэтому имена бакетов S3 не должны содержать точек. Если в имени бакета S3 есть точки, возникает ошибка вида «unable to find hostname 'my.backup.bucket.s3.amazonaws.com' in certificate common name or subject alternative names». Исключение — `repo-s3-uri-style=path`: при такой настройке имя бакета добавляется в начало URI, а не имени узла. Поскольку бакет не является частью имени узла, сертификат проверяется только по имени конечной точки, и точки в имени бакета не создают проблем. Следует учитывать, что не все объектные хранилища, совместимые с S3, поддерживают URI в стиле path. -------- ## Где найти пакеты старых версий pgBackRest? {#where-can-i-find-packages-for-older-versions-of-pgbackrest} Репозиторий [apt.postgresql.org](https://apt.postgresql.org) содержит [архив старых версий](https://apt-archive.postgresql.org). Debian также хранит [снимки](https://snapshot.debian.org/binary/pgbackrest/) всех тестовых сборок. -------- ## Почему резервное копирование завершается ошибкой, если задано `backup-standby=y`, а резервная база данных недоступна? {#why-does-a-backup-attempt-fail-when-backup-standbyy-and-the-standby-database-is-down} Резервное копирование с резервного сервера обычно настраивают для снижения нагрузки на первичный сервер, поэтому перенос копирования на первичный сервер при недоступности резервного часто противоречит этой цели. Увеличивать нагрузку на первичный сервер, когда в системе уже есть сбои, не рекомендуется. Если уже имеется достаточно свежая резервная копия, создание новой не критично: главное — своевременно архивировать WAL. После стабилизации системы времени для создания резервной копии будет достаточно. Если резервная копия всё же необходима, можно добавить резервные серверы или убрать `backup-standby`. Этот параметр можно переопределить в командной строке с помощью `--no-backup-standby`, поэтому для разового резервного копирования менять конфигурацию не требуется. -------- ## Следует ли размещать репозиторий на резервном сервере? {#should-i-setup-my-repository-on-a-standby-host} Нет. Если настроены первичная и резервная базы данных, файлы конфигурации pgBackRest следует сделать симметричными, чтобы переключение при отказе происходило беспрепятственно. В противном случае при переключении придётся изменять конфигурацию, иначе могут возникнуть дополнительные проблемы. Подробности приведены в разделе [Выделенный сервер репозитория](/ru/docs/pgbackrest/user-guide/#dedicated-repository-host) руководства пользователя. -------- ## Почему не работает восстановление на заданный момент времени? {#time-based-point-in-time-recovery-does-not-appear-to-work-why} Самая распространённая ошибка при восстановлении на заданный момент времени — выбор резервной копии, завершённой после целевого времени. При `--type=time`, если параметр `--set` не указан, pgBackRest ищет в настроенных репозиториях копию, завершённую до времени, заданного через `--target=`. Если подходящая копия не найдена, pgBackRest выдаёт ошибку, а не восстанавливает последнюю резервную копию. Копия, завершённая после целевого времени, не позволяет вернуться к этому более раннему моменту путём воспроизведения WAL. Чтобы воспользоваться параметром `--set`, выполните команду `info` и выберите набор резервной копии, время завершения которой предшествует целевому времени. Затем при восстановлении укажите `--set=BACKUP_LABEL`, где `BACKUP_LABEL` — выбранный набор резервной копии. Подробности приведены в разделе [Восстановление на заданный момент времени](/ru/docs/pgbackrest/user-guide/#point-in-time-recovery) руководства пользователя. -------- ## Что означает суффикс файла в архиве WAL? {#what-does-the-wal-archive-suffix-mean} Суффикс — это контрольная сумма SHA1, используемая для проверки целостности файла. Убрать её нельзя. -------- ## Занимает ли восстановление отдельных типов резервных копий (полных, дифференциальных, инкрементных) больше времени? {#does-it-take-longer-to-restore-specific-backup-types-full-differential-incremental} Восстановление разных типов резервных копий занимает одинаковое время. При восстановлении файлы извлекаются на основе манифеста резервной копии, который в случае инкрементной или дифференциальной копии может ссылаться на файлы из предыдущей копии. Хотя время *создания* резервной копии может различаться в зависимости от её типа, время восстановления определяется размером базы данных (при одинаковой производительности дискового и сетевого ввода-вывода и прочих равных условиях). -------- ## Как экспортировать резервную копию для использования в среде, изолированной от сети? {#how-can-i-export-a-backup-for-use-in-a-network-isolated-environment} pgBackRest использует репозиторий не только для хранения резервных копий и архивов WAL, но и для ведения необходимых метаданных, обеспечивающих сжатие, шифрование и пакетирование файлов. Поэтому простое копирование резервной копии вместе с частью файлов WAL обычно не работает, кроме случаев, когда соблюдены очень строгие и специфические условия. Однако есть обходной способ, если нужно получить самодостаточную копию базы данных для переноса, например, на USB-накопителе. Можно создать резервную копию с включённым параметром [`--archive-copy`](/ru/docs/pgbackrest/command/backup/#copy-archive-option---archive-copy), чтобы необходимые сегменты WAL сохранялись вместе с ней. Затем следует восстановить её с параметрами [`--type=none`](/ru/docs/pgbackrest/command/restore/#type-option---type) `--pg1-path=/your/target/path`. В результате получится восстановленный каталог данных PostgreSQL со всеми необходимыми файлами WAL уже в `pg_wal`, аналогичный создаваемому командой `pg_basebackup`. Этот каталог затем можно скопировать в другую систему; ожидается, что PostgreSQL сможет восстановиться из него без доступа к репозиторию pgBackRest. Следует учитывать, что восстановление этой копии не приведёт к переключению временной шкалы, поэтому такому кластеру не следует отправлять WAL в исходный репозиторий, из которого он был экспортирован. В среде, изолированной от сети, это не должно создавать проблем.