Обсуждение: Changes to backup.sgml
-hackers, After my brain flatulence last week on backups, I decided to read the docs again. There are some improvements that I would like to make and wanted some feedback: 1. File System Level Backup The section should be a note within the larger document. It is largely a legacy section from before 8.3. 2. Rework the paragraph about consistent snapshots into its own section 3. Push the rsync paragraph (and edit where appropriate) within the continuous archiving section. 3a. Add information about robocopy (windows rsync) 4. Move continuous archiving up above everything except pg_dump. Perhaps change time to Online Backup. 4a. I want to do some general rewording, there are some places where the documentation is not clear. I can just do this and then let the reviewers have their say. JD -- Command Prompt, Inc. - http://www.commandprompt.com/ 503-667-4564 PostgreSQL Centered full stack support, consulting and development. Announcing "I'm offended" is basically telling the world you can't control your own emotions, so everyone else should do it for you.
On Thu, May 14, 2015 at 09:53:01AM -0700, Joshua Drake wrote: > > -hackers, > > After my brain flatulence last week on backups, I decided to read > the docs again. There are some improvements that I would like to > make and wanted some feedback: > > 1. File System Level Backup > > The section should be a note within the larger document. It is > largely a legacy section from before 8.3. Uh, file system snapshots on VMs make this feature still useful, I think. > 2. Rework the paragraph about consistent snapshots into its own section OK. > 3. Push the rsync paragraph (and edit where appropriate) within the > continuous archiving section. > > 3a. Add information about robocopy (windows rsync) Oh, yes, we should mention robocopy. I had never heard of that. > 4. Move continuous archiving up above everything except pg_dump. > Perhaps change time to Online Backup. Uh, I don't like Online Backup because pg_dump is an "online" backup, no? > 4a. I want to do some general rewording, there are some places > where the documentation is not clear. I can just do this and then > let the reviewers have their say. Sure. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. +
On 05/15/2015 07:42 AM, Bruce Momjian wrote: >> 3. Push the rsync paragraph (and edit where appropriate) within the >> continuous archiving section. >> >> 3a. Add information about robocopy (windows rsync) > > Oh, yes, we should mention robocopy. I had never heard of that. > >> 4. Move continuous archiving up above everything except pg_dump. >> Perhaps change time to Online Backup. > > Uh, I don't like Online Backup because pg_dump is an "online" backup, > no? Online File Backup? JD -- Command Prompt, Inc. - http://www.commandprompt.com/ 503-667-4564 PostgreSQL Centered full stack support, consulting and development. Announcing "I'm offended" is basically telling the world you can't control your own emotions, so everyone else should do it for you.
On Fri, May 15, 2015 at 08:15:51AM -0700, Joshua Drake wrote: > > On 05/15/2015 07:42 AM, Bruce Momjian wrote: > > >>3. Push the rsync paragraph (and edit where appropriate) within the > >>continuous archiving section. > >> > >> 3a. Add information about robocopy (windows rsync) > > > >Oh, yes, we should mention robocopy. I had never heard of that. > > > >>4. Move continuous archiving up above everything except pg_dump. > >>Perhaps change time to Online Backup. > > > >Uh, I don't like Online Backup because pg_dump is an "online" backup, > >no? > > Online File Backup? Uh, yeah, kind of, though that starts to sound like file system backup. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. +
On Thu, May 14, 2015 at 12:53 PM, Joshua D. Drake <jd@commandprompt.com> wrote: > 1. File System Level Backup > > The section should be a note within the larger document. It is largely a > legacy section from before 8.3. I agree. I think this section is just plain weird at this point. Most people would assume that you can copy or move the database files when the database server is shut down, but few people would consider that a usable backup strategy. I'm not sure exactly how this should be refactored, but I think something should be done. Maybe the title should be something like "Moving or Copying Database Files" instead of "File System Level Backup", and the content could be adjusted to fit that theme. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On 05/15/2015 10:03 AM, Robert Haas wrote: > > On Thu, May 14, 2015 at 12:53 PM, Joshua D. Drake <jd@commandprompt.com> wrote: >> 1. File System Level Backup >> >> The section should be a note within the larger document. It is largely a >> legacy section from before 8.3. > > I agree. I think this section is just plain weird at this point. > Most people would assume that you can copy or move the database files > when the database server is shut down, but few people would consider > that a usable backup strategy. I'm not sure exactly how this should > be refactored, but I think something should be done. Maybe the title > should be something like "Moving or Copying Database Files" instead of > "File System Level Backup", and the content could be adjusted to fit > that theme. > In looking at this further, we really need to think about this in a different light. The first page needs to immediately mention we don't need to take the database offline for a backup. 24.1. SQL Dump I think we should remove any references to redirection and use only appropriate flags instead. Any admin worth their salt will realize you can use redirection and those who aren't worth their salt are just going to be confused. For example: Instead of pg_dump dbname > file use pg_dump -d dbname -f dbname.sql I also think we really need to encourage the use of -Fd or -Fc 24.1.1. Restoring the Dump In conjunction with my suggestions for SQL Dump, I think we need to focus on using pg_restore. In short, -Fd and -Fc get precedence (although we will discuss the sql dump) and thus pg_restore will also get precedence. 24.1.2. Using pg_dumpall We need to give larger precedence to pg_dumpall for the sake of globals. I also recommend that we eliminate referencing pg_dumpall as the way to backup the cluster, (except for small databases) and instead focus on the required -g option. 24.1.3. Handling Large Databases The idea of a "large" database is completely different now from then. This reads almost identical to what it said in 8.0. 24.2. File System Level Backup We already discussed this 24.3. Continuous Archiving and Point-in-Time Recovery (PITR) List robocopy (available since server 2003) 24.3.1. Setting Up WAL Archiving 24.3.2. Making a Base Backup Better discussion of pg_basebackup needs to be had. 24.3.3. Making a Base Backup Using the Low Level API Already discussed this 24.3.4. Recovering Using a Continuous Archive Backup "Remove any files present in pg_xlog/; these came from the file system backup and are therefore probably obsolete rather than current. If you didn't archive pg_xlog/ at all, then recreate it with proper permissions, being careful to ensure that you re-establish it as a symbolic link if you had it set up that way before." Is that actually needed? Won't PostgreSQL just ignore them or spit them out? 24.3.5. Timelines I need to read through this again 24.3.6. Tips and Examples I will probably add some to this. 24.3.7. Caveats -- Command Prompt, Inc. - http://www.commandprompt.com/ 503-667-4564 PostgreSQL Centered full stack support, consulting and development. Announcing "I'm offended" is basically telling the world you can't control your own emotions, so everyone else should do it for you.