On Monday, February 10, 2025, Álvaro Herrera <alvhe...@alvh.no-ip.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.
