> 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 r
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
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
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,
""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
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
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 the
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 copie
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:
> 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
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 y
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 save
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
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
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
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 C
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 en
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 wro
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 dat
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 wo
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.
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 copi
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 b
> 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: Th
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
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 back
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 small
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
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| h
> 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 posting
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
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 Mar
33 matches
Mail list logo
