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.
-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
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
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
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
Hello,
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. That is, if you don't forget to include the
current WAL block.
I have found a script to determine the current
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
Hi all.
I am newer to postgresql develop, so my qestion maybe too simple.
I have noticed that we have discussed the incremental backup and PITR before.
Frankly, I am still interested in incremental backup. I am not sure
whether we can implement such function based on XLog
Since there exists
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
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
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
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
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
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
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
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
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
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
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
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
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:
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
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
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
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
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
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
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
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
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
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|
How's this issue going on the 7.4 development tree?
I saw it on the TODO list, but didn't find much on the archives of this
mailing list.
--
Porqué usar una base de datos relacional cualquiera,
si podés usar PostgreSQL?
-
Martín
32 matches
Mail list logo
