Hi,
We have successfully implemented a Backup and Recovery process in our
organization and currently testing it out. We took a previous day backup and
tried to restore it to a point in time.
The database is able to start applying the recovery settings. But it
recovered records past the recovery
Hi Sam,
Thank your sharing this script.
> Here's a script to make your backup and rsync it to a remote destination:
> #!/bin/bash
> echo "checkpoint"
> echo "CHECKPOINT;" | /local/pkg/bin/psql template1
> echo "start backup"
> echo "SELECT pg_start_backup('cisoradr:/cis/pgsql/katana7/backup');"
Hi Florian,
Thanks for the clarification and a link to a post on automated script.
On Jun 5, 2010, at 9:05 , Gnanakumar wrote:
> Thanks for your valuable suggestion and a detailed step on common way to
use
> PITR. Things are very clear now except that I've some other question in
> connection to
, June 05, 2010 7:39 PM
To: pgsql-admin@postgresql.org; gna...@zoniac.com
Cc: f...@phlo.org
Subject: RE: [ADMIN] PITR Recovery Question
"Gnanakumar" wrote:
> I couldn't able to get this particular step clearly: "One trick
> would be to temporarily change your archive_command
From: pgsql-admin-ow...@postgresql.org
[mailto:pgsql-admin-ow...@postgresql.org] On Behalf Of Florian Pflug
Sent: Sunday, 6 June 2010 10:11 PM
To: gna...@zoniac.com
Cc: pgsql-admin@postgresql.org
Subject: Re: [ADMIN] PITR Recovery Question
On Jun 5, 2010, at 9:05 , Gnanakumar wrote:
> Than
On Jun 5, 2010, at 9:05 , Gnanakumar wrote:
> Thanks for your valuable suggestion and a detailed step on common way to use
> PITR. Things are very clear now except that I've some other question in
> connection to this.
>
>> The correct way to clean out pg_xlog therefore is to either disable WAL
"Gnanakumar" wrote:
> I couldn't able to get this particular step clearly: "One trick
> would be to temporarily change your archive_command to 'true',
> delete all files from your archive, and then change the command
> back ". Can you please clarify and explain on this?
Based on other statemen
Hi Kevin,
> It is generally unsafe to delete any WAL files from pg_xlog. If
> they are there because your archive command has been failing, you
> need to turn off archiving or (probably more convenient) allow the
> archive script to return success until things clear. One trick
> would be to temp
Hi Florian,
Thanks for your valuable suggestion and a detailed step on common way to use
PITR. Things are very clear now except that I've some other question in
connection to this.
> The correct way to clean out pg_xlog therefore is to either disable WAL
archiving, or to make sure your archive_c
On Jun 4, 2010, at 13:54 , Gnanakumar wrote:
> In case, if I decide to clean the old WAL archives and set right PITR from
> today onwards by taking base backup, so that I can start managing and
> maintaining atleast from now onwards, what is the correct way/method of
> removing files from pg_xlog/,
"Gnanakumar" wrote:
> My pg_xlog/ and walarchive/ directory locations are
> "/usr/local/pgsql/data/pg_xlog" and "/mnt/pitr/walarchive"
> respectively.
>
> In case, if I decide to clean the old WAL archives and set right
> PITR from today onwards by taking base backup, so that I can start
> mana
Hi Florian,
I'm moving this discussion to pgsql-admin. To give a picture of my original
question, it is given below, so that other users in this mailing list will
understand my original problem statement.
> If you point it at a cluster's own pg_xlog directory, it won't work.
> You might want to
You other option is to use Slony. Create replica and in a short outage you
can move master to replica.
Chirag Dave 416-673-4102
Database Administrator, Afilias Canada Corp.
cd...@ca.afilias.info
On Wed, May 5, 2010 at 11:27 AM, raghu ram wrote:
> Hi Postgres Guru's,
>
>
> Is it possible to u
On 05/05/10 8:57 PM, raghu ram wrote:
Hi Postgres Guru's,
Is
it possible to use the Hot Backup (PITR Backup) of PostgreSQL on an
Operating system to restore the database on other Operating system.
Thanks
& Regards
Raghu
Nope, Hot Backup (Online Backup) of Postgre
On Wed, May 5, 2010 at 11:27 AM, raghu ram wrote:
> Hi Postgres Guru's,
>
>
> Is it possible to use the Hot Backup (PITR Backup) of PostgreSQL on an
> Operating system to restore the database on other Operating system.
>
>
> No, it isn't. Physical (PITR) backups are based on copying the physical
Hi Postgres Guru's,
Is it possible to use the Hot Backup (PITR Backup) of PostgreSQL on an
Operating system to restore the database on other Operating system.
Thanks & Regards
Raghu
On Tue, 2010-03-16 at 10:05 +, Renato Oliveira wrote:
> I have been testing PITR and I have noticed a 20% increase on the load of the
> Disk subsystem.
>
> Is that a normal thing to expect? Have you come across this or have you
> noticed this increase?
>
> I know some of you guys have been
Renato Oliveira wrote:
> I have been testing PITR and I have noticed a 20% increase on the
> load of the Disk subsystem.
>
> Is that a normal thing to expect?
It depends on your workload and archive script, but that doesn't
seem too shocking.
For one thing, turning on archiving causes more
Dear all,
I have been testing PITR and I have noticed a 20% increase on the load of the
Disk subsystem.
Is that a normal thing to expect? Have you come across this or have you noticed
this increase?
I know some of you guys have been using it for quite some time, would you mind
in sharing your
2010 10:12
To: pgsql-admin@postgresql.org
Subject: [ADMIN] PITR clarification to certain points
Importance: High
Dear all,
I apologise for this post in advance, I am sure some of you have already
answered many question and maybe find it boring by now.
I have been playing with PITR for some time
Dear all,
I apologise for this post in advance, I am sure some of you have already
answered many question and maybe find it boring by now.
I have been playing with PITR for some time now and read quite a bit about it,
it is nice feature. I am really enjoying playing with it.
I have managed to
On Mon, 2010-01-18 at 13:41 +, Renato Oliveira wrote:
> Julio,
>
> Unfortunately our live system runs 8.2.4 and it is quite tricky to
> upgrade it right now.
>
>
>
> By the way where can I find a how to use pitr-tools?
https://projects.commandprompt.com/public/pitrtools
Joshua D. Drake
epreth,
CAMBS SG8 6GB
UK
From: Julio Leyva [mailto:jcle...@hotmail.com]
Sent: 14 January 2010 18:47
To: Renato Oliveira
Subject: RE: [ADMIN] PITR online backups Setup
You better update to postgresql 8.3
PITR works very well with this version
I remember trying to setup it with 8.1 and It did no
On Thu, 14 Jan 2010 14:33:52 +, Renato Oliveira
wrote:
> Dear all,
>
> I am trying to setup PITR for online backup and also to create a more
> robust setup, in case our primary Postgres dies.
>
> I am testing this setup on Centos 5.4, Postgres version: 8.1.18 (not
sure
> why Centos has this
Dear all,
I am trying to setup PITR for online backup and also to create a more robust
setup, in case our primary Postgres dies.
I am testing this setup on Centos 5.4, Postgres version: 8.1.18 (not sure why
Centos has this old version by default).
I have enabled PITR, with the following comman
Ian Lea wrote:
>
> The advantage of setting it high is that you'll use less disk space
> and have fewer files to archive.
>
> The disadvantage of setting it high is that you might lose more data.
>
This is not *entirely* true. The archive_timeout setting only indicates the
time at which a ne
Ian Lea wrote:
> The advantage of setting it high is that you'll use less disk space
> and have fewer files to archive.
Although you can mitigate the space problem by using pg_clearxlogtail
(combined with gzip) or pglesslog from pgfoundry.
-Kevin
--
Sent via pgsql-admin mailing list (pgsq
Thank you Ian. I'm clear now.
--
View this message in context:
http://www.nabble.com/PITR-archive_timeout-Command-tp24788681p24790968.html
Sent from the PostgreSQL - admin mailing list archive at Nabble.com.
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to
> 1) What is the advantage / disadvantage of setting "archive_timeout" command
> to too small or too high value?
The advantage of setting it high is that you'll use less disk space
and have fewer files to archive.
The disadvantage of setting it high is that you might lose more data.
In your 30 m
Essentially, my question here is
1) What is the advantage / disadvantage of setting "archive_timeout" command
to too small or too high value?
2) What is the impact of setting this value during PITR recovery process?
--
View this message in context:
http://www.nabble.com/PITR-archive_timeout-Co
Hi Ian,
Ian Lea wrote:
>
> "We could stop the replay at any point and have a
> consistent snapshot of the database as it was at that time. Thus, this
> technique supports point-in-time recovery: it is possible to restore
> the database to its state at any time since your base backup was
> taken
1) Exactly the database was at 10:15 am
From http://www.postgresql.org/docs/8.3/static/continuous-archiving.html
"There is nothing that says we have to replay the WAL entries all the
way to the end. We could stop the replay at any point and have a
consistent snapshot of the database as it was at
Hi,
I have a basic and quick question related to "archive_timeout" command in
PITR.
I've set "archive_timeout" to 1800 seconds (30 minutes) in
"postgresql.conf", which means WAL archives are generated every 30 minutes.
So, if for an example my WAL archives are generated at the following time:
A couple of questions about these files:
1) When are these generated? Is this once an archive is generated, or
once the full archive_command has run?
2) Is there any harm in removing these files by appending an rm command
at the end of archive_command?
-salman
--
Sent via pgsql-admin maili
On Tue, Oct 21, 2008 at 2:29 PM, Scott Whitney <[EMAIL PROTECTED]> wrote:
> It is, is it? I was completely under the impression that it was not. Don't
> ask me where I got that impression. :)
>
> No problem whatsoever, in that case!
>
> Thanks for clearing up my inability to comprehend documentatio
EMAIL PROTECTED]
Sent: Tuesday, October 21, 2008 3:10 PM
To: Scott Whitney
Cc: pgsql-admin@postgresql.org
Subject: Re: [ADMIN] PITR question with base backup
Scott Whitney wrote:
> The problem is that I create databases pretty regularly. Let's say I
create
> 3 in a week. I'm not looking f
Scott Whitney wrote:
> The problem is that I create databases pretty regularly. Let's say I create
> 3 in a week. I'm not looking forward to going to my colo, grabbing the 20ish
> GB tgz file and restoring it 3 times per week. I'd rather do that dance
> monthly or quarterly and rely on the WALs in
I'm in the process of testing PITR recovery, and I have an issue.
My "data" directory is 30GB. Not huge, but it certainly takes awhile to tar
up.
My understanding is:
a) pg_start_backup
b) tar up
c) pg_stop_backup
d) restore tar file
The problem is that I create databases pretty regularly. Let's
On Fri, 2008-08-29 at 12:31 -0700, Richard Broersma wrote:
> Reading the manual for PITR, I see the backup commands are tar, cpio, and
> rsync.
>
> What DOS shell commands recommended: copy, xcopy? Is there something better?
Any command that copies files. Or an integrated backup product.
--
For Rsync on Windows check out:
http://www.nexenta.com/corp/index.php?option=com_content&task=view&id=64&Ite
mid=85
I'm using it on Vista and have not had any problems transferring data
to/from linux and solaris systems.
> From: [EMAIL PROTECTED] [mailto:pgsql-admin-
> [EMAIL PROTECTED] On Behalf
On Fri, 29 Aug 2008 12:31:53 -0700
"Richard Broersma" <[EMAIL PROTECTED]> wrote:
> Reading the manual for PITR, I see the backup commands are tar, cpio,
> and rsync.
>
> What DOS shell commands recommended: copy, xcopy? Is there something
> better?
>
You want to find rsync or the equivalent fo
Reading the manual for PITR, I see the backup commands are tar, cpio, and rsync.
What DOS shell commands recommended: copy, xcopy? Is there something better?
--
Regards,
Richard Broersma Jr.
Visit the Los Angeles PostgreSQL Users Group (LAPUG)
http://pugs.postgresql.org/lapug
--
Sent via pgs
On Tue, Aug 26, 2008 at 5:19 PM, <[EMAIL PROTECTED]> wrote:
> This means a file systems backup. eg.
>
> tar -cvpf data_bakup.tar /var/lib/pgsql/data
Thanks also for the script. I will take a close look.
--
Regards,
Richard Broersma Jr.
Visit the Los Angeles PostgreSQL Users Group (LAPUG)
ht
Hi Richard,
This means a file systems backup. eg.
tar -cvpf data_bakup.tar /var/lib/pgsql/data
Here's a script I use to automate this process. It may be helpful to
customize for yourself.
#!/bin/bash
#
# PostgreSQL Weekly Backup
#
DATE=$(date +%G%m%d)
MAILLOG="/backup/weekly_$DATE.log"
WALAR
>From the following link:
http://www.postgresql.org/docs/8.3/interactive/continuous-archiving.html#BACKUP-BASE-BACKUP
Step 3 says to perform the back up.
Does this mean a File System Backup of the Data directory?
OR
Does this mean performing a pg_dumpall and backing up the dump file?
--
On Sun, 2008-08-24 at 22:17 -0700, Bob Lunney wrote:
> I'm trying to vet the PITR/warm-standby process so set up a primary
> and secondary server on two different Windows machines. (Yeah, I
> know, but I don't have a choice in the matter.)
>
> The primary works fine and copies its WAL files to t
I'm trying to vet the PITR/warm-standby process so set up a primary and
secondary server on two different Windows machines. (Yeah, I know, but I don't
have a choice in the matter.)
The primary works fine and copies its WAL files to the archive directory. As
long as the secondary is in recover
Hi.
I have read the manual chapter over a couple of times. I've even done a
restore of my database and that worked fine. But I'd like to have
confirmed that it seems correct, so it didn't just work because I didn't
have any real activity on the database in my test-setup.
I have a Before Backu
On Fri, 2008-07-11 at 12:15 -0400, Tom Lane wrote:
> Robert Treat <[EMAIL PROTECTED]> writes:
> > Was review a clients config/setup and ran across a pitr warm standby
> > scenario
> > where the master machine is set to the current time, but the slave's time
> > is
> > currently sitting back in
Robert Treat <[EMAIL PROTECTED]> writes:
> Was review a clients config/setup and ran across a pitr warm standby scenario
> where the master machine is set to the current time, but the slave's time is
> currently sitting back in the month of May. Outside of getting ntp setup on
> the machine, I am
Howdy folks,
Was review a clients config/setup and ran across a pitr warm standby scenario
where the master machine is set to the current time, but the slave's time is
currently sitting back in the month of May. Outside of getting ntp setup on
the machine, I am wondering if I need to do anythin
Brad Nicholson wrote:
Say I'm using pg_standby to feed wal files from database A into both
database B and database C.
At some point, I lose A, so I bring Database B up and start the wal
archiving from there. Can I then continue streaming the wal files from
B into C, or do I need to take a new b
Say I'm using pg_standby to feed wal files from database A into both
database B and database C.
At some point, I lose A, so I bring Database B up and start the wal
archiving from there. Can I then continue streaming the wal files from
B into C, or do I need to take a new base backup from B and st
On Thursday 10 January 2008 12:27:37 David Wall wrote:
> I'm trying to get WAL file copying working across two systems. It seems
> pretty straightforward to handle this in the "archive_command" of the
> primary, in which I am able to copy the files easily to a staging area
> for the backup system.
I'm trying to get WAL file copying working across two systems. It seems
pretty straightforward to handle this in the "archive_command" of the
primary, in which I am able to copy the files easily to a staging area
for the backup system.
On the backup system, I have the recovery.conf pointing t
Hi,
we are running a PostgreSQL server (8.2.4) which is used for our internet
service and use log file shipping to get a near-real-time backup.
As the hardware for the backup database server is quite expensive we would
like to use it for internal reporting purposes. That's why we have done the
f
On Fri, 2007-08-31 at 21:56 -0400, Tom Lane wrote:
> Jeff Frost <[EMAIL PROTECTED]> writes:
> > That all seems reasonable enough. Is it in the docs somewhere? I
> > didn't find anything like this mentioned. If not, could we get it
> > added as a note?
>
> Yeah, it hadn't occurred to anyone to s
On Fri, Aug 31, 2007 at 09:56:50PM -0400, Tom Lane wrote:
> Jeff Frost <[EMAIL PROTECTED]> writes:
> > That all seems reasonable enough. Is it in the docs somewhere? I
> > didn't find anything like this mentioned. If not, could we get it
> > added as a note?
>
> Yeah, it hadn't occurred to anyo
On Fri, 31 Aug 2007, Jeff Frost wrote:
On Fri, 31 Aug 2007, Tom Lane wrote:
Jeff Frost <[EMAIL PROTECTED]> writes:
Why does it request it twice?
I think the reason is that the rollforward cycle is
fetch next segment into RECOVERYXLOG
process segment
unlink RECOVERYX
Jeff Frost <[EMAIL PROTECTED]> writes:
> That all seems reasonable enough. Is it in the docs somewhere? I
> didn't find anything like this mentioned. If not, could we get it
> added as a note?
Yeah, it hadn't occurred to anyone to specify this, because we just
thought of recovery_command as fet
On Fri, 31 Aug 2007, Tom Lane wrote:
Jeff Frost <[EMAIL PROTECTED]> writes:
Why does it request it twice?
I think the reason is that the rollforward cycle is
fetch next segment into RECOVERYXLOG
process segment
unlink RECOVERYXLOG
and only when the "fetch" step fails
Jeff Frost <[EMAIL PROTECTED]> writes:
> Why does it request it twice?
I think the reason is that the rollforward cycle is
fetch next segment into RECOVERYXLOG
process segment
unlink RECOVERYXLOG
and only when the "fetch" step fails does it realize it's done. So then
it
On Fri, 31 Aug 2007, Tom Lane wrote:
Jeff Frost <[EMAIL PROTECTED]> writes:
It seems like everything is happy, except it seems to ask for the 4F
log file more than once.
IIRC that's standard procedure. Is there a reason your recovery_command
can't support it?
Really? If that's the case, t
Jeff Frost <[EMAIL PROTECTED]> writes:
> It seems like everything is happy, except it seems to ask for the 4F
> log file more than once.
IIRC that's standard procedure. Is there a reason your recovery_command
can't support it?
regards, tom lane
--
Hi guys, I've inherited a PITR continuous recovery master/standby server pair.
The continuous recovery and loading of the xlogs seems to work fine, but when
I opted to test the replica bring up, it falls over with signal 6.
Here's an excerpt from the log with log levels set up to debug5:
DEBUG
>>> On Tue, Aug 7, 2007 at 10:31 PM, in message
<[EMAIL PROTECTED]>, Andrew Kroeger
<[EMAIL PROTECTED]> wrote:
> Kevin Grittner wrote:
>> The Netware server supports ssh, scp, and an rsync daemon. I don't see how
>> the ssh implementation is helpful, though, since it just gets you to the
>> Netwa
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> Apparently we will be moving to a Linux-based implementation of Netware at
> some unspecified future date, at which point we will apparently be able to
> deal directly with the Linux layer. At that point, there are obvious, clean
> solutions; but w
Kevin Grittner wrote:
> The Netware server supports ssh, scp, and an rsync daemon. I don't see how
> the ssh implementation is helpful, though, since it just gets you to the
> Netware console -- you can't cat to a disk file through it, for example.
> (At least not as far as we have been able to se
> >>> Decibel! <[EMAIL PROTECTED]> 08/07/07 4:51 PM >>>
> On Tue, Aug 07, 2007 at 02:12:29PM -0500, Kevin Grittner wrote:
> > > Copying a 16MB file that's already in memory isn't exactly an intensive
> > > operation...
> >
> > That's true for the WAL files. The base backups are another story.
On Tue, Aug 07, 2007 at 02:12:29PM -0500, Kevin Grittner wrote:
> > 2) Have archive_command copy to someplace on the database server, and
> > have another process copy from there to both the local backup as well as
> > the central backup.
>
> A possible option; although if the rsync daemon on the
> >>> Decibel! <[EMAIL PROTECTED]> 08/07/07 1:28 PM >>>
> On Tue, Aug 07, 2007 at 06:29:35AM -0500, Kevin Grittner wrote:
>> We have a database in each Wisconsin county which is part of the official
>> court record for the circuit courts in that county. We are required to keep
>> a backup in each
On Tue, Aug 07, 2007 at 06:29:35AM -0500, Kevin Grittner wrote:
> We have a database in each Wisconsin county which is part of the official
> court record for the circuit courts in that county. We are required to keep
> a backup in each county, such that we could recover a lost or corrupted
> data
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Tom Lane wrote:
>> well, I was using rysnc so I could copy to a different computer over
>> ssh, not using the rsync protocol to catch diffs. I don't have a
>> remote file system mounted so I can do just a cp.
> If you are going over an ssh conn
> If you are going over an ssh connection then scp seems like the
> appropriate tool. Yeah, rsync would work, but it's just a useless
> extra layer of software...
Actually, rsync has one edge over scp even where its other attributes
are moot: atomicity.
Rsync keeps the data in a temporary locati
We have a database in each Wisconsin county which is part of the official
court record for the circuit courts in that county. We are required to keep
a backup in each county, such that we could recover a lost or corrupted
database with what is in the county (as well as keeping at least four
separa
?
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Tom Lane
Sent: Monday, August 06, 2007 8:54 PM
To: [EMAIL PROTECTED]
Cc: pgsql-admin@postgresql.org
Subject: Re: [ADMIN] PITR with rsync
David Bear <[EMAIL PROTECTED]> writes:
> On Mon, Aug 06, 2007 at 0
David Bear <[EMAIL PROTECTED]> writes:
> On Mon, Aug 06, 2007 at 08:27:13PM -0400, Tom Lane wrote:
>> I suppose you could, but what's the point? Copying a single file that
>> doesn't currently exist on the destination plays to none of rsync's
>> strengths.
> well, I was using rysnc so I could cop
On Mon, Aug 06, 2007 at 08:27:13PM -0400, Tom Lane wrote:
> David Bear <[EMAIL PROTECTED]> writes:
> > I'm still uncomfortable with using the file system style backup method
> > in PITR and am very interested in ' more information ' on how others
> > may be doing backups. Specifically, I assume tha
David Bear <[EMAIL PROTECTED]> writes:
> I'm still uncomfortable with using the file system style backup method
> in PITR and am very interested in ' more information ' on how others
> may be doing backups. Specifically, I assume that PITR methods would
> also be accompanied with some combination o
I've been looking at the pages on PITR and am wondering if anyone has
tried using rsync to accomplish this.
I'm still uncomfortable with using the file system style backup method
in PITR and am very interested in ' more information ' on how others
may be doing backups. Specifically, I assume that
Speaking of PITR, it would be great if I could perform a PITR for a
particular database in an instance.
My options otherwise would be to install the instance elsewhere and
extract, or, create an instance for
each database (not reasonable, since we have dozens)
We backup each database separatel
PITR doesn't go back in time. It only supports roll-forward from a prior
base backup using the logs, stopping at a predefined time/xid/endoflogs.
Going backwards using the logs is mostly impossible because the log
records don't hold enough info to un-erase things.
It is theoretically possible to
On Tue, 2007-01-09 at 08:37 -0600, Ben K. wrote:
> On Mon, 8 Jan 2007, Simon Riggs wrote:
>
> > There is a log analysis tool on pgfoundry that does something similar.
>
> > You can already stop recovery at a certain point. So there's nothing to
> > stop you doing a recovery on a development machi
On Mon, 8 Jan 2007, Simon Riggs wrote:
There is a log analysis tool on pgfoundry that does something similar.
You can already stop recovery at a certain point. So there's nothing to
stop you doing a recovery on a development machine up to a certain
point, then dumping the deleted data using p
On Fri, 5 Jan 2007, Bruno Wolff III wrote:
I.e. would it be possible to restore the file system backup
and use the PITR method from a Solaris/SPARC main to a Linux backup, using
their respective native file system? What are the minimal conditions to be
met?
No the data is not only dependent on
On Mon, 2007-01-08 at 09:41 -0600, Ben K. wrote:
> > On Fri, 2007-01-05 at 12:59 -0600, Ben K. wrote:
> >> 2. sql dump and PITR
> >> Is it possible to use the PITR method with SQL dump? (pg_start_backup ->
> >> sql dump -> pg_stop_backup) I guess not, but just want to make sure.
> >
> > No, because
On Fri, 2007-01-05 at 12:59 -0600, Ben K. wrote:
2. sql dump and PITR
Is it possible to use the PITR method with SQL dump? (pg_start_backup ->
sql dump -> pg_stop_backup) I guess not, but just want to make sure.
No, because there is no reason or benefit.
Thanks. I guess the PITR plays on a di
On Fri, 2007-01-05 at 12:59 -0600, Ben K. wrote:
> 2. sql dump and PITR
>
> Is it possible to use the PITR method with SQL dump? (pg_start_backup ->
> sql dump -> pg_stop_backup) I guess not, but just want to make sure.
>
No, because there is no reason or benefit.
--
Simon Riggs
On Fri, Jan 05, 2007 at 12:59:51 -0600,
"Ben K." <[EMAIL PROTECTED]> wrote:
>
> Maybe this is answered somewhere or maybe self-evident, but I just wanted
> to make sure. I want to know if it's possible to do PITR between different
> platforms. I can try and learn, but if anyone knows, I'd appr
Maybe this is answered somewhere or maybe self-evident, but I just wanted
to make sure. I want to know if it's possible to do PITR between different
platforms. I can try and learn, but if anyone knows, I'd appreciate it.
1. file formats
What is the chance that the file format of files under
Mr. Dan wrote:
Hi,
Every day I'm arguing with 3 or 4 people on this point.
My point is that I have to do a tarball, a tar command as part of online
backup with postgresql v814. I keep saying that the reason we do a
tarbal (online backup) and not individual dumps is that we want the PITR
capa
Hi,
Every day I'm arguing with 3 or 4 people on this point.
My point is that I have to do a tarball, a tar command as part of online
backup with postgresql v814. I keep saying that the reason we do a tarbal
(online backup) and not individual dumps is that we want the PITR
capability. I've be
Can anyone answer please ?
--- Satya Prakash Tripathi <[EMAIL PROTECTED]>
wrote:
> Hi ,
>
> I am experimenting with PITR aspect of postgres8.0,
> and I needed some answers on this subject.
>
> I have following questions :
>
> 1)
> At time t0, I created a base backup. (got a backup
> marker fil
Hi ,
I am experimenting with PITR aspect of postgres8.0,
and I needed some answers on this subject.
I have following questions :
1)
At time t0, I created a base backup. (got a backup
marker file named as:
0008000200A8.005E61B4.backup)
(assume no previous base backups and recoveries.
On 4/5/06, Robin Iddon <[EMAIL PROTECTED]> wrote:[-l $LOGFILE]
Hope this helps,It did, thanks./rls-- :wq
Anyone have any suggestions on novel phrases to offer in my incantations for
getting this script to do everything I need?
You need to add "-l $LOGFILE" where log is wherever you want to write
the stderr+stdout from the postmaster to. Then it will return once
starting the server.
Also, is
On 4/5/06, Robin Iddon <[EMAIL PROTECTED]> wrote:
Andy Shellam wrote:>I have, however, recently developed an interest in rsync but I'm unsure as
>to how PG on the standby server would handle a complete rsync'd data>directory.
There has just recently been a fairly extensive discussion on this listab
On Wed, 5 Apr 2006, Robin Iddon wrote:
Marc G. Fournier wrote:
I know ppl are using it to do replication, but has anyone documented what
is involved in doing so?
thanks ...
We use linux HA and linux DRBD (~RAID1 mirror between disks across a LAN) to
provide a similar replication mechanism
Andy Shellam wrote:
Robin,
On my part it's simply the fact that I currently have two servers in
different geographical locations - and cost of new hardware is a huge issue.
I have, however, recently developed an interest in rsync but I'm unsure as
to how PG on the standby server would handle
te rsync'd data
directory.
Andy
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:pgsql-admin-
> [EMAIL PROTECTED] On Behalf Of Robin Iddon
> Sent: 05 April 2006 9:10 am
> Cc: pgsql-admin@postgresql.org
> Subject: Re: [ADMIN] PITR Based replication ...
>
>
1 - 100 of 129 matches
Mail list logo
