Re: [HACKERS] Incremental Backup Script

2006-01-09 Thread Gregor Zeitlinger
As per docs, if the databases are rarely updated it could take a long time for the WAL segment to roll over. Yes, therefore I want to copy the current WAL (as I said earlier). When restoring, I also want to make sure that I restore exactely to the point when I copied the current WA segment.

Re: [HACKERS] Incremental Backup Script

2006-01-04 Thread Gregor Zeitlinger
-Original Message- From: Zach Bagnall [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 04, 2006 4:42 AM To: pgsql-hackers@postgresql.org Subject: Re: [HACKERS] Incremental Backup Script Gregor: can you explain how to identify the current file? I had implemented a backup and restore

Re: [HACKERS] Incremental Backup Script

2006-01-03 Thread Zach Bagnall
On 12/26/05 11:04, Qingqing Zhou wrote: Gregor Zeitlinger [EMAIL PROTECTED] wrote Also, I was wondering whether it is always safe to copy the current WAL file, i.e. may the current WAL file be invalid in any circumstance? If you mean current WAL file is the xlog segment in use, then it is

Re: [HACKERS] Incremental Backup Script

2006-01-03 Thread Rick Gigger
I would certainly like some instructions on this as well. On Jan 3, 2006, at 8:41 PM, Zach Bagnall wrote: On 12/26/05 11:04, Qingqing Zhou wrote: Gregor Zeitlinger [EMAIL PROTECTED] wrote Also, I was wondering whether it is always safe to copy the current WAL file, i.e. may the current WAL

Re: [HACKERS] Incremental Backup Script

2005-12-26 Thread Simon Riggs
On Sun, 2005-12-25 at 14:02 +0100, Gregor Zeitlinger wrote: as far as I have understood, the WAL backup that you control via archive_command is the PostgreSQL equivalent to what other databases let you do with an incremental backup No it is not an incremental backup of changed data blocks, it

Re: [HACKERS] Incremental Backup Script

2005-12-25 Thread Qingqing Zhou
Gregor Zeitlinger [EMAIL PROTECTED] wrote Also, I was wondering whether it is always safe to copy the current WAL file, i.e. may the current WAL file be invalid in any circumstance? If you mean current WAL file is the xlog segment in use, then it is dangerous. We only backup the xlog

Re: [HACKERS] Incremental backup

2003-02-15 Thread Curt Sampson
On Fri, 14 Feb 2003, Kevin Brown wrote: Oracle has something they call rollback segments which I assume are separate bits of data that have enough information to reverse changes that were made to the database during a transaction, and I figured PITR would (or could) apply particular saved

Re: [HACKERS] Incremental backup

2003-02-15 Thread Tom Lane
Curt Sampson [EMAIL PROTECTED] writes: Oracle9i has a new feature called a flashback query, which uses the information in the rollback segements to let you query the database in a previous state. (I.e., select such and such from this table as of two hours ago.) Postgres could do this using the

Re: [HACKERS] Incremental backup

2003-02-15 Thread Marc Munro
Kevin, Hi. I was looking into PITR for PostgreSQL myself about a year back but life intervened. I am an Oracle DBA so may be able to help you with an understanding of how Oracle does this. You wrote: Oracle has something they call rollback segments which I assume are separate bits of data

Re: [HACKERS] Incremental backup

2003-02-15 Thread Kevin Brown
Curt Sampson wrote: Oracle9i has a new feature called a flashback query, which uses the information in the rollback segements to let you query the database in a previous state. (I.e., select such and such from this table as of two hours ago.) Postgres could do this using the older copies of

Re: [HACKERS] Incremental backup

2003-02-15 Thread Tom Lane
Curt Sampson [EMAIL PROTECTED] writes: ... But there's really no need for all fifty of those, if you don't mind not being able to restore to any time before the current time. Which, of course, is exactly the point of PITR designs. When you know that your assistant trainee DBA deleted most of

Re: [HACKERS] Incremental backup

2003-02-15 Thread Curt Sampson
On Sat, 15 Feb 2003, Tom Lane wrote: Curt Sampson [EMAIL PROTECTED] writes: ... But there's really no need for all fifty of those, if you don't mind not being able to restore to any time before the current time. Which, of course, is exactly the point of PITR designs. When you know that

Re: [HACKERS] Incremental backup

2003-02-14 Thread Kevin Brown
Bruce Momjian wrote: OK, once we have PITR, will anyone want incremental backups? None of my database references (Date's Introduction to Database Systems and Garcia-Molina's Database Systems - The Complete Book, in particular) seem to talk about PITR at all. At least, there's no index entry

Re: [HACKERS] Incremental backup

2003-02-14 Thread Christopher Browne
A long time ago, in a galaxy far, far away, [EMAIL PROTECTED] (Kevin Brown) wrote: Bruce Momjian wrote: OK, once we have PITR, will anyone want incremental backups? None of my database references (Date's Introduction to Database Systems and Garcia-Molina's Database Systems - The Complete

Re: [HACKERS] Incremental backup

2003-02-14 Thread Kevin Brown
Christopher Browne wrote: What PITR generally consists of is the notion that you want to recover to the state at a particular moment in time. In O*-nomenclature, this means that you recover as at some earlier moment for which you have a good backup, and then re-apply changes, which in

Re: [HACKERS] Incremental backup

2003-02-14 Thread Martin Marques
On Jue 13 Feb 2003 16:38, Bruce Momjian wrote: Patrick Macdonald wrote: Bruce Momjian wrote: Someone at Red Hat is working on point-in-time recovery, also known as incremental backups. PITR and incremental backup are different beasts. PITR deals with a backup + logs. Incremental

Re: [HACKERS] Incremental backup

2003-02-14 Thread Manfred Koizar
On Thu, 13 Feb 2003 19:24:13 -0500, Patrick Macdonald [EMAIL PROTECTED] wrote: I know Oracle and DB2 have incremental backup in their arsenal (and iirc, SQL Server has something called differential backup). Whatever the name, it's a win at the enterprise level. A differential backup copies only

Re: [HACKERS] Incremental backup

2003-02-14 Thread Bruce Momjian
OK, once we have PITR, will anyone want incremental backups? --- Martin Marques wrote: On Jue 13 Feb 2003 16:38, Bruce Momjian wrote: Patrick Macdonald wrote: Bruce Momjian wrote: Someone at Red Hat is working on

Re: [HACKERS] Incremental backup

2003-02-14 Thread Martin Marques
On Vie 14 Feb 2003 09:52, Bruce Momjian wrote: OK, once we have PITR, will anyone want incremental backups? I will probably not need it, but I know of people how have databases which build dumps of more then 20GB. They are interested in live incremental backups. -- Porqué usar una base de

Re: [HACKERS] Incremental backup

2003-02-14 Thread Greg Copeland
On Fri, 2003-02-14 at 06:52, Bruce Momjian wrote: OK, once we have PITR, will anyone want incremental backups? --- Martin Marques wrote: On Jue 13 Feb 2003 16:38, Bruce Momjian wrote: Patrick Macdonald wrote:

Re: [HACKERS] Incremental backup

2003-02-14 Thread Curt Sampson
On Fri, 14 Feb 2003, Bruce Momjian wrote: OK, once we have PITR, will anyone want incremental backups? Well, I'm not entirely clear on how PITR will work, so I may be off-base here, but it seems to me that offering incremental backups that back up only changed pages might not be all that big a

Re: [HACKERS] Incremental backup

2003-02-13 Thread Bruce Momjian
Patrick Macdonald wrote: But why would someone want incremental backups compared to PITR? The backup would be mixture of INSERTS, UPDATES, and DELETES, right? Seems pretty weird. :-) Yeah, it's a different method of producing a similar outcome. However, many companies do not want to

Re: [HACKERS] Incremental backup

2003-02-13 Thread Rod Taylor
Wow, I never even thought that was possible. Do other db's support that feature? Isn't that basically what the current replication kits for Postgresql do -- via triggers and log tables? -- Rod Taylor [EMAIL PROTECTED] PGP Key: http://www.rbt.ca/rbtpub.asc signature.asc Description: This

Re: [HACKERS] Incremental backup

2003-02-13 Thread Patrick Macdonald
Bruce Momjian wrote: Patrick Macdonald wrote: Yeah, it's a different method of producing a similar outcome. However, many companies do not want to be concerned with the management (and space) of archived logs. Incremental backup allows them the option of performing a full backup and

Re: [HACKERS] Incremental backup

2003-02-13 Thread Patrick Macdonald
Bruce Momjian wrote: Someone at Red Hat is working on point-in-time recovery, also known as incremental backups. PITR and incremental backup are different beasts. PITR deals with a backup + logs. Incremental backup deals with a full backup + X smaller/incremental backups. So... it doesn't

Re: [HACKERS] Incremental backup

2003-02-13 Thread Bruce Momjian
Patrick Macdonald wrote: Bruce Momjian wrote: Someone at Red Hat is working on point-in-time recovery, also known as incremental backups. PITR and incremental backup are different beasts. PITR deals with a backup + logs. Incremental backup deals with a full backup + X

Re: [HACKERS] Incremental backup

2003-02-13 Thread Patrick Macdonald
Bruce Momjian wrote: Patrick Macdonald wrote: Bruce Momjian wrote: Someone at Red Hat is working on point-in-time recovery, also known as incremental backups. PITR and incremental backup are different beasts. PITR deals with a backup + logs. Incremental backup deals with a

Re: [HACKERS] Incremental backup

2003-02-12 Thread Bruce Momjian
Someone at Red Hat is working on point-in-time recovery, also known as incremental backups. It will be in 7.4. --- Martin Marques wrote: How's this issue going on the 7.4 development tree? I saw it on the TODO list, but

Re: [HACKERS] Incremental backup

2003-02-12 Thread Christopher Kings-Lynne
Someone at Red Hat is working on point-in-time recovery, also known as incremental backups. It will be in 7.4. Does that mean that the poor guy/gal is implementing redo for all the index types? Chris ---(end of broadcast)--- TIP 3: if

Re: [HACKERS] Incremental backup

2003-02-12 Thread Bruce Momjian
Christopher Kings-Lynne wrote: Someone at Red Hat is working on point-in-time recovery, also known as incremental backups. It will be in 7.4. Does that mean that the poor guy/gal is implementing redo for all the index types? No idea. -- Bruce Momjian|