pg_verifybackup
pg_verifybackup — проверить целостность базовой копии кластера Postgres Pro
Синтаксис
pg_verifybackup [параметр...]
Описание
pg_verifybackup позволяет проверить целостность копии кластера БД, сделанной программой pg_basebackup, по манифесту backup_manifest, созданному во время копирования. Копия должна быть представлена в формате «plain»; чтобы проверить копию в формате «tar», её нужно сначала разархивировать.
Важно отметить, что процедура контроля, выполняемая программой pg_verifybackup не включает и не может включать в себя все проверки, которые будет выполнять сервер, если его запустить с этой копией. Даже если вы пользуетесь этим средством, вам всё же следует выполнять тестовое восстановление данных, чтобы убедиться в том, что восстановленные базы работают ожидаемым образом и содержат нужные данные. Тем не менее pg_verifybackup может быстро выявить множество распространённых проблем, вызываемых неисправностью хранилища или ошибками пользователя.
Проверка копии выполняется в четыре этапа. На первом этапе pg_verifybackup читает файл backup_manifest. Если этот файл не существует, неправильно оформлен или не соответствует контрольной сумме, которая в нём содержится, pg_verifybackup завершает выполнение с критической ошибкой.
На втором этапе pg_verifybackup проверяет, что файлы данных, находящиеся на диске в настоящее время, в точностью совпадают с теми файлами, которые сервер должен был передать, за несколькими исключениями, описанными ниже. При этом выявляются все пропавшие или добавившиеся файлы, кроме некоторых игнорируемых. В частности, на этом этапе не принимается во внимание присутствие, отсутствие или какое-либо изменение файлов postgresql.auto.conf, standby.signal и recovery.signal, так как ожидается, что эти файлы могут создаваться или модифицироваться в процессе создания копии. Также из рассмотрения исключается файл backup_manifest в целевом каталоге и всё содержимое каталога pg_wal, несмотря на то, что эти файлы не будут описаны в манифесте копии. Проверяются только файлы; наличие или отсутствие каталогов контролируется только косвенно: если какой-либо каталог отсутствует, неизбежно будут отсутствовать и все файлы, которые должны в нём содержаться.
Затем pg_verifybackup проверяет контрольные суммы всех файлов, сравнивая их со значениями, указанными в манифесте, и выдаёт ошибки для файлов, у которых вычисленная контрольная сумма не совпадает с сохранённой в манифесте. Это действие не выполняется для файлов, вызвавших ошибки на предыдущем шаге, так как о проблемах с ними уже известно. Для файлов, которые игнорировались на втором этапе, контрольные суммы тоже не проверяются.
На последнем этапе pg_verifybackup, используя манифест, проверяет, имеются ли в журнале WAL все записи, необходимые для восстановления, и можно ли их успешно прочитать и разобрать. Файл backup_manifest содержит информацию о том, какие записи потребуются, благодаря чему pg_verifybackup может вызвать pg_waldump, чтобы разобрать и тем самым проверить эти записи журнала. При вызове программы pg_waldump передаётся флаг --quiet, так что она будет выдавать только ошибки, без каких-либо других сообщений. Хотя этот уровень проверки достаточен для выявления явных проблем, например, отсутствия файлов или несоответствия внутренних контрольных сумм, он всё же не даёт гарантию обнаружения всех проблем, которые могут возникнуть при попытке восстановления базы. Например, данный метод проверки бесполезен, если из-за внутренней ошибки сервера в WAL будут вноситься записи с правильными контрольными суммами, но бессмысленным содержимым.
Заметьте, что в случае наличия дополнительных файлов WAL, не требующихся для восстановления копии, они не будут проверяться этим средством, хотя проверить их можно, вызвать pg_waldump отдельно. Также учтите, что проверка WAL зависит от версии: для проверки целостности копии необходимо использовать ту версию pg_verifybackup, а значит и pg_waldump, с которой эта копия была получена. Проверки же целостности файлов должны работать с данными любой версии сервера, сформировавшего файл backup_manifest.
Параметры
Утилита pg_verifybackup принимает следующие аргументы командной строки:
-e--exit-on-errorЗавершиться при первой же выявленной проблеме. В отсутствие этого указания
pg_verifybackupпродолжает проверку копии после обнаружения первой ошибки и сообщает обо всех ошибках.-iпуть--ignore=путьИгнорировать указанный файл или каталог, который может быть задан относительным путём, при сравнении списка файлов данных, фактически присутствующих в копии, со списком в файле
backup_manifest. Если указан путь к каталогу, из рассмотрения исключается всё дерево подкаталогов, начиная с указанного. В случае совпадения относительного пути файла с указанным никакие сообщения о дополнительных или пропавших файлах, а также об изменении размера или несовпадении контрольных сумм файлов, выдаваться не будут. Этот параметр можно задать несколько раз.-mпуть--manifest-path=путьИспользовать файл манифеста по заданному пути вместо файла, расположенного в корневом каталоге копии.
-n--no-parse-walНе пытаться разобрать данные журнала предзаписи, которые могут понадобиться для восстановления проверяемой копии.
-P--progressВключает вывод сообщений о прогрессе. Эти сообщения будут выводиться при проверке контрольных сумм.
Этот параметр нельзя использовать с параметром
--quiet.-q--quietНе выводить ничего, если копия проходит проверку успешно.
-s--skip-checksumsНе проверять контрольные суммы файлов данных. При этом тем не менее будет проверяться отсутствие или наличие файлов и их размеры. В таком режиме проверка выполняется гораздо быстрее, так как собственно содержимое файлов читать не требуется.
-wпуть--wal-directory=путьПроверять файлы WAL, находящиеся в указанном каталоге, а не в
pg_wal. Это полезно, если архив WAL сохраняется отдельно от основного содержимого копии.
Другие флаги:
-V--versionСообщить версию pg_verifybackup и завершиться.
-?--helpВывести справку об аргументах командной строки pg_verifybackup и завершиться.
Примеры
Создание базовой копии сервера mydbserver и проверка целостности копии:
$pg_basebackup -h mydbserver -D /usr/local/pgsql/data$pg_verifybackup /usr/local/pgsql/data
Создание базовой копии сервера mydbserver, перемещение файла манифеста во внешний каталог и проверка копии:
$pg_basebackup -h mydbserver -D /usr/local/pgsql/backup1234$mv /usr/local/pgsql/backup1234/backup_manifest /my/secure/location/backup_manifest.1234$pg_verifybackup -m /my/secure/location/backup_manifest.1234 /usr/local/pgsql/backup1234
Проверка копии с исключением файла, добавленного в каталог копии вручную, и без проверки контрольных сумм:
$pg_basebackup -h mydbserver -D /usr/local/pgsql/data$edit /usr/local/pgsql/data/note.to.self$pg_verifybackup --ignore=note.to.self --skip-checksums /usr/local/pgsql/data
См. также
pg_basebackuppg_verifybackup
pg_verifybackup — verify the integrity of a base backup of a Postgres Pro cluster
Synopsis
pg_verifybackup [option...]
Description
pg_verifybackup is used to check the integrity of a database cluster backup taken using pg_basebackup against a backup_manifest generated by the server at the time of the backup. The backup must be stored in the "plain" format; a "tar" format backup can be checked after extracting it.
It is important to note that the validation which is performed by pg_verifybackup does not and cannot include every check which will be performed by a running server when attempting to make use of the backup. Even if you use this tool, you should still perform test restores and verify that the resulting databases work as expected and that they appear to contain the correct data. However, pg_verifybackup can detect many problems that commonly occur due to storage problems or user error.
Backup verification proceeds in four stages. First, pg_verifybackup reads the backup_manifest file. If that file does not exist, cannot be read, is malformed, or fails verification against its own internal checksum, pg_verifybackup will terminate with a fatal error.
Second, pg_verifybackup will attempt to verify that the data files currently stored on disk are exactly the same as the data files which the server intended to send, with some exceptions that are described below. Extra and missing files will be detected, with a few exceptions. This step will ignore the presence or absence of, or any modifications to, postgresql.auto.conf, standby.signal, and recovery.signal, because it is expected that these files may have been created or modified as part of the process of taking the backup. It also won't complain about a backup_manifest file in the target directory or about anything inside pg_wal, even though these files won't be listed in the backup manifest. Only files are checked; the presence or absence of directories is not verified, except indirectly: if a directory is missing, any files it should have contained will necessarily also be missing.
Next, pg_verifybackup will checksum all the files, compare the checksums against the values in the manifest, and emit errors for any files for which the computed checksum does not match the checksum stored in the manifest. This step is not performed for any files which produced errors in the previous step, since they are already known to have problems. Files which were ignored in the previous step are also ignored in this step.
Finally, pg_verifybackup will use the manifest to verify that the write-ahead log records which will be needed to recover the backup are present and that they can be read and parsed. The backup_manifest contains information about which write-ahead log records will be needed, and pg_verifybackup will use that information to invoke pg_waldump to parse those write-ahead log records. The --quiet flag will be used, so that pg_waldump will only report errors, without producing any other output. While this level of verification is sufficient to detect obvious problems such as a missing file or one whose internal checksums do not match, they aren't extensive enough to detect every possible problem that might occur when attempting to recover. For instance, a server bug that produces write-ahead log records that have the correct checksums but specify nonsensical actions can't be detected by this method.
Note that if extra WAL files which are not required to recover the backup are present, they will not be checked by this tool, although a separate invocation of pg_waldump could be used for that purpose. Also note that WAL verification is version-specific: you must use the version of pg_verifybackup, and thus of pg_waldump, which pertains to the backup being checked. In contrast, the data file integrity checks should work with any version of the server that generates a backup_manifest file.
Options
pg_verifybackup accepts the following command-line arguments:
-e--exit-on-errorExit as soon as a problem with the backup is detected. If this option is not specified,
pg_verifybackupwill continue checking the backup even after a problem has been detected, and will report all problems detected as errors.-ipath--ignore=pathIgnore the specified file or directory, which should be expressed as a relative path name, when comparing the list of data files actually present in the backup to those listed in the
backup_manifestfile. If a directory is specified, this option affects the entire subtree rooted at that location. Complaints about extra files, missing files, file size differences, or checksum mismatches will be suppressed if the relative path name matches the specified path name. This option can be specified multiple times.-mpath--manifest-path=pathUse the manifest file at the specified path, rather than one located in the root of the backup directory.
-n--no-parse-walDon't attempt to parse write-ahead log data that will be needed to recover from this backup.
-P--progressEnable progress reporting. Turning this on will deliver a progress report while verifying checksums.
This option cannot be used together with the option
--quiet.-q--quietDon't print anything when a backup is successfully verified.
-s--skip-checksumsDo not verify data file checksums. The presence or absence of files and the sizes of those files will still be checked. This is much faster, because the files themselves do not need to be read.
-wpath--wal-directory=pathTry to parse WAL files stored in the specified directory, rather than in
pg_wal. This may be useful if the backup is stored in a separate location from the WAL archive.
Other options are also available:
-V--versionPrint the pg_verifybackup version and exit.
-?--helpShow help about pg_verifybackup command line arguments, and exit.
Examples
To create a base backup of the server at mydbserver and verify the integrity of the backup:
$pg_basebackup -h mydbserver -D /usr/local/pgsql/data$pg_verifybackup /usr/local/pgsql/data
To create a base backup of the server at mydbserver, move the manifest somewhere outside the backup directory, and verify the backup:
$pg_basebackup -h mydbserver -D /usr/local/pgsql/backup1234$mv /usr/local/pgsql/backup1234/backup_manifest /my/secure/location/backup_manifest.1234$pg_verifybackup -m /my/secure/location/backup_manifest.1234 /usr/local/pgsql/backup1234
To verify a backup while ignoring a file that was added manually to the backup directory, and also skipping checksum verification:
$pg_basebackup -h mydbserver -D /usr/local/pgsql/data$edit /usr/local/pgsql/data/note.to.self$pg_verifybackup --ignore=note.to.self --skip-checksums /usr/local/pgsql/data