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 ... " -- Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/ "Nunca confiaré en un traidor. Ni siquiera si el traidor lo he creado yo" (Barón Vladimir Harkonnen)
