Re: Doc: Move standalone backup section, mention -X argument

On Monday, February 10, 2025, Álvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
wrote:

> On 2024-Jun-28, David G. Johnston wrote:
>
> > A documentation comment came in [1] causing me to review some of our
> backup
> > documentation and I left the current content and location of the
> standalone
> > backups was odd. I propose to move it to a better place, under file
> system
> > backups.
>
> Even before this patch, these sections are all a bit incoherent, because
> we spend a lot of vertical space explaining WAL archiving before even
> mentioning how they would be used, with pg_basebackup mentioned halfway
> down the page. Your patch makes it a bit better, but I think it doesn't
> go far enough. Even after the patch, If the reader skips 25.2, then
> section 25.3 reads a bit incoherent until you're halfway down the (quite
> long) page and pg_basebackup is mentioned. I think it would be better
> to move 25.2 out of the way moving it to the end of the chapter, and do
> something like this
>
> 25.1. SQL Dump
> 25.1.1. Restoring the Dump
> 25.1.2. Using pg_dumpall
> 25.1.3. Handling Large Databases
>
> 25.2. Physical Backups Using Continuous Archiving
> David's text: "In constrast to logical backups ... "
> 25.2.1. Built-In Standalone Backups
> "If all you want is a standalone ..."
> 25.2.2. Setting Up WAL Archiving
> 25.2.3. Making a Base Backup
> 25.2.4. Making an Incremental Backup
> 25.2.5. Making a Base Backup Using the Low Level API
> 25.2.6. Recovering Using a Continuous Archive Backup
> 25.2.7. Timelines
> 25.2.8. Tips and Examples
> 25.2.9. Caveats
>
> 25.3. File System Level Backup
> Start current 25.2 with a few additional words: "An older and largely
> deprecated technique to take a backup is to directly copy the files ...
> "
>
>
Thanks. There is another comment floating about saying a similar thing.
I’m good with giving a more comprehensive patch a go.

David J.