Thread: Doc: Move standalone backup section, mention -X argument
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.
Adding to commitfest.
David J.
Attachment
I compiled the patch and it worked without any problems.
I think the patch makes sense, because of the structure of the current
docs. It seems more logical to have this section in this part of the
documentation, where it is useful and not only described for another
chapter, because it won't even work with the current chapter it is
referenced in ("Continous Archiving and Point-in-Time Recovery
(PITR)").
I am still new to Postgres, so I can't tell whether it can be written
more detailed or not. But I really like it, that is in a more fitting
chapter in my opinion.
Regards,
Marlene Reiterer
Am Mo., 16. Sept. 2024 um 10:35 Uhr schrieb David G. Johnston
<david.g.johnston@gmail.com>:
>
> A documentation comment came in [1] causing me to review some of our backup documentation and I left the current
contentand location of the standalone backups was odd. I propose to move it to a better place, under file system
backups.
>
> Adding to commitfest.
>
> David J.
>
> [1] https://www.postgresql.org/message-id/CAKFQuwZ%3DWxdWJ6O66yQ9dnWTLO12p7h3HpfhowCj%2B0U_bNrzdg%40mail.gmail.com
>
On Monday, February 10, 2025, Álvaro Herrera <alvherre@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.
On Sat, 29 Jun 2024 at 02:27, David G. Johnston <david.g.johnston@gmail.com> wrote: > > A documentation comment came in [1] causing me to review some of our backup documentation and I left the current contentand location of the standalone backups was odd. I propose to move it to a better place, under file system backups. > > Adding to commitfest. I noticed that Alvaro's comment from [1] is not yet addressed, I have changed the status of commitfest entry to Waiting on Author, please address them and change the status back to Needs review. [1] - https://www.postgresql.org/message-id/202502101154.bmb536npfl5e%40alvherre.pgsql Regards, Vignesh