Re: [HACKERS] [DOCS] Online backup vs Continuous backup
Bruce Momjian wrote: > I used your suggestion and renamed "online backup" to "incremental > backup", and added a mention that many database vendors call it > "online backup". Consistency would then demand that the other two be renamed to "full backup". I think we had better suggestions earlier. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [DOCS] Online backup vs Continuous backup
I used your suggestion and renamed "online backup" to "incremental backup", and added a mention that many database vendors call it "online backup". Patch attached. --- Rick Gigger wrote: > How about: > > use "Online backup" or "Hot backup" to refer to either method of back > since they are both done while the system is online or hot. > > If you want to get specific refer to doing a "sql dump" etc for using > pg_dump > Then use "Incremental backup" to refer to the whole process of the > WAL archival etc > Refer to the actual log files themselves as transaction logs. > > That all seems to be pretty intuitive and non-ambiguous non-confusing > to me. > > On Dec 26, 2005, at 11:44 AM, Tom Lane wrote: > > > Bruce Momjian writes: > >> I suggest the following patch to rename our capability "Continuous > >> Backup". > > > > This doesn't seem like an improvement. "Online backup" is the > > standard > > terminology AFAIK. > > > > regards, tom lane > > > > ---(end of > > broadcast)--- > > TIP 4: Have you searched our list archives? > > > >http://archives.postgresql.org > > > > > ---(end of broadcast)--- > TIP 9: In versions below 8.0, the planner will ignore your desire to >choose an index scan if your joining column's datatypes do not >match > -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 Index: doc/src/sgml/backup.sgml === RCS file: /cvsroot/pgsql/doc/src/sgml/backup.sgml,v retrieving revision 2.76 diff -c -c -r2.76 backup.sgml *** doc/src/sgml/backup.sgml7 Nov 2005 17:36:44 - 2.76 --- doc/src/sgml/backup.sgml14 Feb 2006 04:00:50 - *** *** 19,25 SQL dump File system level backup !On-line backup Each has its own strengths and weaknesses. --- 19,25 SQL dump File system level backup !Incremental backup Each has its own strengths and weaknesses. *** *** 372,382 ! ! On-line backup and point-in-time recovery (PITR) !on-line backup --- 372,382 ! ! Incremental backup and point-in-time recovery (PITR) !incremental backup *** *** 452,458 !To recover successfully using an on-line backup, you need a continuous sequence of archived WAL files that extends back at least as far as the start time of your backup. So to get started, you should set up and test your procedure for archiving WAL files before you take your --- 452,459 !To recover successfully using an incremental backup (also called "online !backup" by many database vendors), you need a continuous sequence of archived WAL files that extends back at least as far as the start time of your backup. So to get started, you should set up and test your procedure for archiving WAL files before you take your *** *** 782,793 pg_start_backup or pg_stop_backup, and you will therefore be left to your own devices to keep track of which backup dump is which and how far back the associated WAL files go. ! It is generally better to follow the on-line backup procedure above. !Recovering with an On-line Backup Okay, the worst has happened and you need to recover from your backup. --- 783,794 pg_start_backup or pg_stop_backup, and you will therefore be left to your own devices to keep track of which backup dump is which and how far back the associated WAL files go. ! It is generally better to follow the incremental backup procedure above. !Recovering with an Incremental Backup Okay, the worst has happened and you need to recover from your backup. *** *** 1119,1129 ! Caveats ! At this writing, there are several limitations of the on-line backup technique. These will probably be fixed in future releases: --- 1120,1130 ! Caveats ! At this writing, there are several limitations of the incremental backup technique. These will probably be fixed in future releases: Index: doc/src/sgml/config.sgml === RCS file: /cvsroot/pgsql/doc/src/sgml/config.sgml,v retrieving revision 1.47 diff -c -c -r1.47 config.sgml *** doc/src/sgml/config.sgml5 Feb 2006 18:19:14 -
Re: [HACKERS] [DOCS] Online backup vs Continuous backup
I think it would all make more sense if we described the use of archive_command = something as being in "WAL Archive Mode". That would then allow us to say: "You can only take Online Backups while in WAL Archive Mode". "If you ever wish to perform PITR, you must use WAL Archive Mode". "If you backed-up in WAL Archive Mode, you can perform an Archive Recovery". It seems to me there are two different context in which one would be making statements like this. And what we are "allowed to say" depends greatly on context. These contexts are as follows: 1) Explaining the feature set of postgres to a potential user. 2) Explaining to an actual postgres user how to actually do something. In the first case it makes the most sense to me to use industry standard or very intuitive terminology to the extend that it exists. ie (Transaction Logs vs. WAL). Incremental Backup and Point in Time Recovery seem to be fairly commonly used and understood database buzzwords for someone to investigate the feature set of an RDBMS. In the second case it seems to me that the most important thing is that you pick terminology that is consistent, unambiguous and clearly defined. Log archival, PITR, etc are not point and click operations like they are in say MS SQL Server. This gives us more flexibility but it also requires a deeper understanding. If someone is unwilling or unable to to learn whatever terminology you happen to come up with then it seems to me they shouldn't even be attempting to set up one of those features. At the same time if the terminology you uses changes all the time (is not consistent), or if you can't figure out what any of the terms mean (they are not clearly defined) or if you use terms like "online backup" to mean both types of backup but then use it once in a specific circumstance where only one usage is appropriate (you are using the terms ambiguously) then users will be confused and it will be your fault not theirs. Just my 2 cents Rick Gigger ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [DOCS] Online backup vs Continuous backup
How about: use "Online backup" or "Hot backup" to refer to either method of back since they are both done while the system is online or hot. If you want to get specific refer to doing a "sql dump" etc for using pg_dump Then use "Incremental backup" to refer to the whole process of the WAL archival etc Refer to the actual log files themselves as transaction logs. That all seems to be pretty intuitive and non-ambiguous non-confusing to me. On Dec 26, 2005, at 11:44 AM, Tom Lane wrote: Bruce Momjian writes: I suggest the following patch to rename our capability "Continuous Backup". This doesn't seem like an improvement. "Online backup" is the standard terminology AFAIK. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [DOCS] Online backup vs Continuous backup
On Mon, 2005-12-26 at 13:46 -0500, Bruce Momjian wrote: > Tom Lane wrote: > > Bruce Momjian writes: > > > I suggest the following patch to rename our capability "Continuous > > > Backup". > > > > This doesn't seem like an improvement. "Online backup" is the standard > > terminology AFAIK. > > But why is it the standard terminology? It doesn't seem logical. Well, as Greg says its a physical backup that can be done on-line, so online backup makes perfect sense to me. I've never had somebody say "that makes no sense" before. Nomenclature is different everywhere, I accept. I generally describe it like this: Logical Backup - use pg_dump - must be done on-line Physical Backup All file copy only - must be Cold/Off-line backup All file copy + WAL archiving - allows Hot/Online or Cold/Offline backup People understand those terms... When do I mention PITR? Well, I describe this as Archive Recovery, with an option to go to end-of-logs, or to a point-in-time. [In the code, the mode variable is InArchiveRecovery.] I do think that saying "do you use PITR?" makes little sense. We should be talking about the backup mode, not the potential future recovery mode. I think it would all make more sense if we described the use of archive_command = something as being in "WAL Archive Mode". That would then allow us to say: "You can only take Online Backups while in WAL Archive Mode". "If you ever wish to perform PITR, you must use WAL Archive Mode". "If you backed-up in WAL Archive Mode, you can perform an Archive Recovery". Best Regards, Simon Riggs ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [DOCS] Online backup vs Continuous backup
Tom Lane wrote: > Bruce Momjian writes: > > I suggest the following patch to rename our capability "Continuous > > Backup". > > This doesn't seem like an improvement. "Online backup" is the standard > terminology AFAIK. But why is it the standard terminology? It doesn't seem logical. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [DOCS] Online backup vs Continuous backup
Bruce Momjian writes: > I suggest the following patch to rename our capability "Continuous > Backup". This doesn't seem like an improvement. "Online backup" is the standard terminology AFAIK. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
