|
| 1 | +<!-- doc/src/sgml/backupmanifest.sgml --> |
| 2 | + |
| 3 | +<chapter id="backup-manifest-format"> |
| 4 | + <title>Backup Manifest Format</title> |
| 5 | + |
| 6 | + <para> |
| 7 | + The backup manifest generated by <xref linkend="app-pgbasebackup" /> is |
| 8 | + primarily intended to permit the backup to be verified using |
| 9 | + <xref linkend="app-pgverifybackup" />. However, it is |
| 10 | + also possible for other tools to read the backup manifest file and use |
| 11 | + the information contained therein for their own purposes. To that end, |
| 12 | + this chapter describes the format of the backup manifest file. |
| 13 | + </para> |
| 14 | + |
| 15 | + <para> |
| 16 | + A backup manifest is a JSON document encoded as UTF-8. (Although in |
| 17 | + general JSON documents are required to be Unicode, PostgreSQL permits |
| 18 | + the <type>json</type> and <type>jsonb</type> data types to be used with any |
| 19 | + supported server encoding. There is no similar exception for backup |
| 20 | + manifests.) The JSON document is always an object; the keys that are present |
| 21 | + in this object are described in the next section. |
| 22 | + </para> |
| 23 | + |
| 24 | + <sect1 id="backup-manifest-toplevel"> |
| 25 | + <title>Backup Manifest Toplevel Object</title> |
| 26 | + |
| 27 | + <para> |
| 28 | + The backup manifest JSON document contains the following keys. |
| 29 | + </para> |
| 30 | + |
| 31 | + <variablelist> |
| 32 | + <varlistentry> |
| 33 | + <term><literal>PostgreSQL-Backup-Manifest-Version</literal></term> |
| 34 | + <listitem> |
| 35 | + <para> |
| 36 | + The associated value is always the integer 1. |
| 37 | + </para> |
| 38 | + </listitem> |
| 39 | + </varlistentry> |
| 40 | + |
| 41 | + <varlistentry> |
| 42 | + <term><literal>Files</literal></term> |
| 43 | + <listitem> |
| 44 | + <para> |
| 45 | + The associated value is always a list of objects, each describing one |
| 46 | + file that is present in the backup. No entries are present in this |
| 47 | + list for the WAL files that are needed in order to use the backup, |
| 48 | + or for the backup manifest itself. The structure of each object in the |
| 49 | + list is described in <xref linkend="backup-manifest-files" />. |
| 50 | + </para> |
| 51 | + </listitem> |
| 52 | + </varlistentry> |
| 53 | + |
| 54 | + <varlistentry> |
| 55 | + <term><literal>WAL-Ranges</literal></term> |
| 56 | + <listitem> |
| 57 | + <para> |
| 58 | + The associated value is always a list of objects, each describing a |
| 59 | + range of WAL records that must be readable from a particular timeline |
| 60 | + in order to make use of the backup. The structure of these objects is |
| 61 | + further described in <xref linkend="backup-manifest-wal-ranges" />. |
| 62 | + </para> |
| 63 | + </listitem> |
| 64 | + </varlistentry> |
| 65 | + |
| 66 | + <varlistentry> |
| 67 | + <term><literal>Manifest-Checksum</literal></term> |
| 68 | + <listitem> |
| 69 | + <para> |
| 70 | + This key is always present on the last line of the backup manifest file. |
| 71 | + The associated value is a SHA256 checksum of all the preceding lines. |
| 72 | + We use a fixed checksum method here to make it possible for clients |
| 73 | + to do incremental parsing of the manifest. While a SHA256 checksum |
| 74 | + is significantly more expensive than a CRC32C checksum, the manifest |
| 75 | + should normally be small enough that the extra computation won't matter |
| 76 | + very much. |
| 77 | + </para> |
| 78 | + </listitem> |
| 79 | + </varlistentry> |
| 80 | + </variablelist> |
| 81 | + </sect1> |
| 82 | + |
| 83 | + <sect1 id="backup-manifest-files"> |
| 84 | + <title>Backup Manifest File Object</title> |
| 85 | + |
| 86 | + <para> |
| 87 | + The object which describes a single file contains either a |
| 88 | + <literal>Path</literal> key or an <literal>Encoded-Path</literal> key. |
| 89 | + Normally, the <literal>Path</literal> key will be present. The |
| 90 | + associated string value is the path of the file relative to the root |
| 91 | + of the backup directory. Files located in a user-defined tablespace |
| 92 | + will have paths whose first two components are pg_tblspc and the OID |
| 93 | + of the tablespace. If the path is not a string that is legal in UTF-8, |
| 94 | + or if the user requests that encoded paths be used for all files, then |
| 95 | + the <literal>Encoded-Path</literal> key will be present instead. This |
| 96 | + stores the same data, but it is encoded as a string of hexadecimal |
| 97 | + digits. Each pair of hexadecimal digits in the string represents a |
| 98 | + single octet. |
| 99 | + </para> |
| 100 | + |
| 101 | + <para> |
| 102 | + The following two keys are always present: |
| 103 | + </para> |
| 104 | + |
| 105 | + <variablelist> |
| 106 | + <varlistentry> |
| 107 | + <term><literal>Size</literal></term> |
| 108 | + <listitem> |
| 109 | + <para> |
| 110 | + The expected size of this file, as an integer. |
| 111 | + </para> |
| 112 | + </listitem> |
| 113 | + </varlistentry> |
| 114 | + |
| 115 | + <varlistentry> |
| 116 | + <term><literal>Last-Modified</literal></term> |
| 117 | + <listitem> |
| 118 | + <para> |
| 119 | + The last modification time of the file as reported by the server at |
| 120 | + the time of the backup. Unlike the other fields stored in the backup, |
| 121 | + this field is not used by <xref linkend="app-pgverifybackup" />. |
| 122 | + It is included only for informational purposes. |
| 123 | + </para> |
| 124 | + </listitem> |
| 125 | + </varlistentry> |
| 126 | + </variablelist> |
| 127 | + |
| 128 | + <para> |
| 129 | + If the backup was taken with file checksums enabled, the following |
| 130 | + keys will be present: |
| 131 | + </para> |
| 132 | + |
| 133 | + <variablelist> |
| 134 | + <varlistentry> |
| 135 | + <term><literal>Checksum-Algorithm</literal></term> |
| 136 | + <listitem> |
| 137 | + <para> |
| 138 | + The checksum algorithm used to compute a checksum for this file. |
| 139 | + Currently, this will be the same for every file in the backup |
| 140 | + manifest, but this may change in future releases. At present, the |
| 141 | + supported checksum algorithms are <literal>CRC32C</literal>, |
| 142 | + <literal>SHA224</literal>, |
| 143 | + <literal>SHA256</literal>, |
| 144 | + <literal>SHA384</literal>, and |
| 145 | + <literal>SHA512</literal>. |
| 146 | + </para> |
| 147 | + </listitem> |
| 148 | + </varlistentry> |
| 149 | + |
| 150 | + <varlistentry> |
| 151 | + <term><literal>Checksum</literal></term> |
| 152 | + <listitem> |
| 153 | + <para> |
| 154 | + The checksum computed for this file, stored as a series of |
| 155 | + hexadecimal characters, two for each byte of the checksum. |
| 156 | + </para> |
| 157 | + </listitem> |
| 158 | + </varlistentry> |
| 159 | + </variablelist> |
| 160 | + </sect1> |
| 161 | + |
| 162 | + <sect1 id="backup-manifest-wal-ranges"> |
| 163 | + <title>Backup Manifest WAL Range Object</title> |
| 164 | + |
| 165 | + <para> |
| 166 | + The object which describes a WAL range always has three keys: |
| 167 | + </para> |
| 168 | + |
| 169 | + <variablelist> |
| 170 | + <varlistentry> |
| 171 | + <term><literal>Timeline</literal></term> |
| 172 | + <listitem> |
| 173 | + <para> |
| 174 | + The timeline for this range of WAL records, as an integer. |
| 175 | + </para> |
| 176 | + </listitem> |
| 177 | + </varlistentry> |
| 178 | + |
| 179 | + <varlistentry> |
| 180 | + <term><literal>Start-LSN</literal></term> |
| 181 | + <listitem> |
| 182 | + <para> |
| 183 | + The LSN at which replay must begin on the indicated timeline in order to |
| 184 | + make use of this backup. The LSN is stored in the format normally used |
| 185 | + by <productname>PostgreSQL</productname>; that is, it is a string |
| 186 | + consisting of two strings of hexadecimal characters, each with a length |
| 187 | + of between 1 and 8, separated by a slash. |
| 188 | + </para> |
| 189 | + </listitem> |
| 190 | + </varlistentry> |
| 191 | + |
| 192 | + <varlistentry> |
| 193 | + <term><literal>End-LSN</literal></term> |
| 194 | + <listitem> |
| 195 | + <para> |
| 196 | + The earliest LSN at which replay on the indicated timeline may end when |
| 197 | + making use of this backup. This is stored in the same format as |
| 198 | + <literal>Start-LSN</literal>. |
| 199 | + </para> |
| 200 | + </listitem> |
| 201 | + </varlistentry> |
| 202 | + </variablelist> |
| 203 | + |
| 204 | + <para> |
| 205 | + Ordinarily, there will be only a single WAL range. However, if a backup is |
| 206 | + taken from a standby which switches timelines during the backup due to an |
| 207 | + upstream promotion, it is possible for multiple ranges to be present, each |
| 208 | + with a different timeline. There will never be multiple WAL ranges present |
| 209 | + for the same timeline. |
| 210 | + </para> |
| 211 | + </sect1> |
| 212 | +</chapter> |
0 commit comments