@@ -500,39 +500,51 @@ PostgreSQL documentation
500
500
</varlistentry>
501
501
502
502
<varlistentry>
503
- <term><option>--no-slot </option></term>
503
+ <term><option>--manifest-checksums=<replaceable class="parameter">algorithm</replaceable> </option></term>
504
504
<listitem>
505
505
<para>
506
- This option prevents the creation of a temporary replication slot
507
- during the backup even if it's supported by the server.
506
+ Specifies the checksum algorithm that should be applied to each file
507
+ included in the backup manifest. Currently, the available
508
+ algorithms are <literal>NONE</literal>, <literal>CRC32C</literal>,
509
+ <literal>SHA224</literal>, <literal>SHA256</literal>,
510
+ <literal>SHA384</literal>, and <literal>SHA512</literal>.
511
+ The default is <literal>CRC32C</literal>.
508
512
</para>
509
513
<para>
510
- Temporary replication slots are created by default if no slot name
511
- is given with the option <option>-S</option> when using log streaming.
514
+ If <literal>NONE</literal> is selected, the backup manifest will
515
+ not contain any checksums. Otherwise, it will contain a checksum
516
+ of each file in the backup using the specified algorithm. In addition,
517
+ the manifest will always contain a <literal>SHA256</literal>
518
+ checksum of its own contents. The <literal>SHA</literal> algorithms
519
+ are significantly more CPU-intensive than <literal>CRC32C</literal>,
520
+ so selecting one of them may increase the time required to complete
521
+ the backup.
512
522
</para>
513
523
<para>
514
- The main purpose of this option is to allow taking a base backup when
515
- the server is out of free replication slots. Using replication slots
516
- is almost always preferred, because it prevents needed WAL from being
517
- removed by the server during the backup.
524
+ Using a SHA hash function provides a cryptographically secure digest
525
+ of each file for users who wish to verify that the backup has not been
526
+ tampered with, while the CRC32C algorithm provides a checksum which is
527
+ much faster to calculate and good at catching errors due to accidental
528
+ changes but is not resistant to targeted modifications. Note that, to
529
+ be useful against an adversary who has access to the backup, the backup
530
+ manifest would need to be stored securely elsewhere or otherwise
531
+ verified not to have been modified since the backup was taken.
532
+ </para>
533
+ <para>
534
+ <xref linkend="app-pgverifybackup" /> can be used to check the
535
+ integrity of a backup against the backup manifest.
518
536
</para>
519
537
</listitem>
520
538
</varlistentry>
521
539
522
540
<varlistentry>
523
- <term><option>--no-verify-checksums </option></term>
541
+ <term><option>--manifest-force-encode </option></term>
524
542
<listitem>
525
543
<para>
526
- Disables verification of checksums, if they are enabled on the server
527
- the base backup is taken from.
528
- </para>
529
- <para>
530
- By default, checksums are verified and checksum failures will result
531
- in a non-zero exit status. However, the base backup will not be
532
- removed in such a case, as if the <option>--no-clean</option> option
533
- had been used. Checksum verifications failures will also be reported
534
- in the <link linkend="monitoring-pg-stat-database-view">
535
- <structname>pg_stat_database</structname></link> view.
544
+ Forces all filenames in the backup manifest to be hex-encoded.
545
+ If this option is not specified, only non-UTF8 filenames are
546
+ hex-encoded. This option is mostly intended to test that tools which
547
+ read a backup manifest file properly handle this case.
536
548
</para>
537
549
</listitem>
538
550
</varlistentry>
@@ -576,51 +588,39 @@ PostgreSQL documentation
576
588
</varlistentry>
577
589
578
590
<varlistentry>
579
- <term><option>--manifest-force-encode </option></term>
591
+ <term><option>--no-slot </option></term>
580
592
<listitem>
581
593
<para>
582
- Forces all filenames in the backup manifest to be hex-encoded.
583
- If this option is not specified, only non-UTF8 filenames are
584
- hex-encoded. This option is mostly intended to test that tools which
585
- read a backup manifest file properly handle this case.
594
+ This option prevents the creation of a temporary replication slot
595
+ during the backup even if it's supported by the server.
596
+ </para>
597
+ <para>
598
+ Temporary replication slots are created by default if no slot name
599
+ is given with the option <option>-S</option> when using log streaming.
600
+ </para>
601
+ <para>
602
+ The main purpose of this option is to allow taking a base backup when
603
+ the server is out of free replication slots. Using replication slots
604
+ is almost always preferred, because it prevents needed WAL from being
605
+ removed by the server during the backup.
586
606
</para>
587
607
</listitem>
588
608
</varlistentry>
589
609
590
610
<varlistentry>
591
- <term><option>--manifest- checksums=<replaceable class="parameter">algorithm</replaceable> </option></term>
611
+ <term><option>--no-verify- checksums</option></term>
592
612
<listitem>
593
613
<para>
594
- Specifies the checksum algorithm that should be applied to each file
595
- included in the backup manifest. Currently, the available
596
- algorithms are <literal>NONE</literal>, <literal>CRC32C</literal>,
597
- <literal>SHA224</literal>, <literal>SHA256</literal>,
598
- <literal>SHA384</literal>, and <literal>SHA512</literal>.
599
- The default is <literal>CRC32C</literal>.
600
- </para>
601
- <para>
602
- If <literal>NONE</literal> is selected, the backup manifest will
603
- not contain any checksums. Otherwise, it will contain a checksum
604
- of each file in the backup using the specified algorithm. In addition,
605
- the manifest will always contain a <literal>SHA256</literal>
606
- checksum of its own contents. The <literal>SHA</literal> algorithms
607
- are significantly more CPU-intensive than <literal>CRC32C</literal>,
608
- so selecting one of them may increase the time required to complete
609
- the backup.
610
- </para>
611
- <para>
612
- Using a SHA hash function provides a cryptographically secure digest
613
- of each file for users who wish to verify that the backup has not been
614
- tampered with, while the CRC32C algorithm provides a checksum which is
615
- much faster to calculate and good at catching errors due to accidental
616
- changes but is not resistant to targeted modifications. Note that, to
617
- be useful against an adversary who has access to the backup, the backup
618
- manifest would need to be stored securely elsewhere or otherwise
619
- verified not to have been modified since the backup was taken.
614
+ Disables verification of checksums, if they are enabled on the server
615
+ the base backup is taken from.
620
616
</para>
621
617
<para>
622
- <xref linkend="app-pgverifybackup" /> can be used to check the
623
- integrity of a backup against the backup manifest.
618
+ By default, checksums are verified and checksum failures will result
619
+ in a non-zero exit status. However, the base backup will not be
620
+ removed in such a case, as if the <option>--no-clean</option> option
621
+ had been used. Checksum verifications failures will also be reported
622
+ in the <link linkend="monitoring-pg-stat-database-view">
623
+ <structname>pg_stat_database</structname></link> view.
624
624
</para>
625
625
</listitem>
626
626
</varlistentry>
0 commit comments