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 pgman@candle.pha.pa.us 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 itemizedlist listitemparaacronymSQL/ dump/para/listitem listitemparaFile system level backup/para/listitem !listitemparaOn-line backup/para/listitem /itemizedlist Each has its own strengths and weaknesses. /para --- 19,25 itemizedlist listitemparaacronymSQL/ dump/para/listitem listitemparaFile system level backup/para/listitem !listitemparaIncremental backup/para/listitem /itemizedlist Each has its own strengths and weaknesses. /para *** *** 372,382 /para /sect1 ! sect1 id=backup-online ! titleOn-line backup and point-in-time recovery (PITR)/title indexterm zone=backup !primaryon-line backup/primary /indexterm indexterm zone=backup --- 372,382 /para /sect1 ! sect1 id=backup-incremental ! titleIncremental backup and point-in-time recovery (PITR)/title indexterm zone=backup !primaryincremental backup/primary /indexterm indexterm zone=backup *** *** 452,458 /para para !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 emphasisbefore/ you take your --- 452,459 /para para !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 emphasisbefore/ you take your *** *** 782,793 functionpg_start_backup/ or functionpg_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. /para /sect2 sect2 id=backup-pitr-recovery !titleRecovering with an On-line Backup/title para Okay, the worst has happened and you need to recover from your backup. --- 783,794 functionpg_start_backup/ or functionpg_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. /para /sect2 sect2 id=backup-pitr-recovery !titleRecovering with an Incremental Backup/title para Okay, the worst has happened and you need to recover from your backup. *** *** 1119,1129 /para /sect2 ! sect2 id=backup-online-caveats titleCaveats/title
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
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 pgman@candle.pha.pa.us 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
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
On Mon, 2005-12-26 at 13:46 -0500, Bruce Momjian wrote: Tom Lane wrote: Bruce Momjian pgman@candle.pha.pa.us 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
Bruce Momjian pgman@candle.pha.pa.us 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
Re: [HACKERS] [DOCS] Online backup vs Continuous backup
Tom Lane wrote: Bruce Momjian pgman@candle.pha.pa.us 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
