akp geek wrote:
Got it almost. Thanks a lot. One final question, please bear with me.
1. select pg_start_backup('label') ==> 10 AM
2. PGDATA folder backup ==> 10:05 AM
3. select pg_stop_backup => 10.10AM
4. The archiving will start writing files
You've got step (4) in the wrong place. The
Got it almost. Thanks a lot. One final question, please bear with me.
1. select pg_start_backup('label') ==> 10 AM
2. PGDATA folder backup ==> 10:05 AM
3. select pg_stop_backup => 10.10AM
4. The archiving will start writing files
5. If the disc crashes at 11AM, what will happen to the data bet
On Wed, Nov 11, 2009 at 12:51 PM, akp geek wrote:
> Hi All -
> I have read the document got a reasonable
> understanding of the WAL process. I have some confusion regarding the
> process.
>
> 1. I have set up the archiving process. Now the archive file are going
> to a different
Hi All -
I have read the document got a reasonable
understanding of the WAL process. I have some confusion regarding the
process.
1. I have set up the archiving process. Now the archive file are going
to a different mount point.
2. I set up job to create a back up of the PGDATA d
I have set up the replication using Bucardo. This is just an additional set
up
regards
On Tue, Nov 10, 2009 at 5:09 PM, silly wrote:
> How about using replication instead of incremental backups?
>
> On Tue, Nov 10, 2009 at 4:56 PM, Alan Hodgson wrote:
> > On Tuesday 10 November 2009, akp g
How about using replication instead of incremental backups?
On Tue, Nov 10, 2009 at 4:56 PM, Alan Hodgson wrote:
> On Tuesday 10 November 2009, akp geek wrote:
>> So Is it always good to have the backup using PG_dump instead of PITR or
>> a combination of both
>>
>
> I like to do both. Ongoing P
On Tuesday 10 November 2009, akp geek wrote:
> So Is it always good to have the backup using PG_dump instead of PITR or
> a combination of both
>
I like to do both. Ongoing PITR, daily base backups (by updating an rsync
copy), and weekly pg_dumps that in turn go to tape.
PITR gives a very rece
So Is it always good to have the backup using PG_dump instead of PITR or a
combination of both
Please advice
Regards
On Tue, Nov 10, 2009 at 11:24 AM, Scott Mead
wrote:
>
> On Tue, Nov 10, 2009 at 9:52 AM, Greg Stark wrote:
>
>>
>> It's always worth having the dump, even if you also implement
I have tested the procedure in the URL and it worked fine. I have
accidentally deleted my PGDATA folder after the backup procedure is done. I
could able to restore it. But still have few questions
Thanks for the help
Regards
On Mon, Nov 9, 2009 at 11:01 PM, Jing Tan wrote:
> I wrote an article
On Tue, Nov 10, 2009 at 9:52 AM, Greg Stark wrote:
>
> It's always worth having the dump, even if you also implement PITR.
> The dump allows you to restore just specific tables or to restore onto
> a different type of system. The PITR backup is a physical
> byte-for-byte copy which only works if
On Tue, Nov 10, 2009 at 11:03 AM, Alban Hertroys
wrote:
> IMHO The simplest solution is to just write a dump to the same file every
> now and then and have the backup software take care of storing only the
> differences. It does have a few drawbacks; it means you'll have a file about
> as large as
On 10 Nov 2009, at 3:48, akp geek wrote:
Dear all -
Is there way to create incremental backups in
postgres. I am currently using 8.4.1 on solaris.. I am new to
postgres. Can you please share your thoughts
Regards
IMHO The simplest solution is to just write a dump to t
I wrote an article about PITR , incremental backups and multiple timelines.
check out. http://jinxter555.blogspot.com/
it should be an easy read.
akp geek ha escrito:
Dear all -
Is there way to create incremental backups in postgres. I
am currently using 8.4.1 on solaris. I
On Mon, Nov 9, 2009 at 6:48 PM, akp geek wrote:
> Is there way to create incremental backups in postgres. I
> am currently using 8.4.1 on solaris. I am new to postgres. Can you please
> share your thoughts
I've read more about continuous back-ups:
http://www.postgresql.org/docs
Saving off the transaction log WAL files is a good way to do this.
Read this part of the manual:
http://www.postgresql.org/docs/8.4/interactive/continuous-archiving.html
...and see if that answers your questions.
On Nov 9, 2009, at 6:48 PM, akp geek wrote:
Dear all -
Is t
On Apr 19, 9:41 am, Kev <[EMAIL PROTECTED]> wrote:
> On Apr 17, 10:27 am, [EMAIL PROTECTED] (Mageshwaran) wrote:
>
> > hi everyone,
>
> > please any one give any methods to do incremental backups. it is urgent
> > .. help me
>
> > Regards
> > J Mageshwaran
>
> Sorry, I don't have anything implement
On Apr 17, 10:27 am, [EMAIL PROTECTED] (Mageshwaran) wrote:
> hi everyone,
>
> please any one give any methods to do incremental backups. it is urgent
> .. help me
>
> Regards
> J Mageshwaran
Sorry, I don't have anything implemented, but I've been wondering
about this too. One way (not necessaril
I have applied the following patch adds to the paragraph after the one
you quoted below. I just added mention that the start/stop time _and_
wal file names are in the history file.
---
Rick Gigger wrote:
> I've started writ
I've started writing some scripts to set up incremental backup to my
taste. I just discovered something and thought I would revisit this
thread briefly.
When you go to restore from a give base file system backup you need
to know the start WAL file that you need and the end WAL file that
Wonderful. That is good news. Thanks.
Rick
On Jan 31, 2006, at 7:14 AM, Tom Lane wrote:
Rick Gigger <[EMAIL PROTECTED]> writes:
That's what I mean by invalid. Let's say I do something stupid and
do a physical backup and I don't grab the current WAL file. All I
have is the last one to be a
Rick Gigger <[EMAIL PROTECTED]> writes:
> That's what I mean by invalid. Let's say I do something stupid and
> do a physical backup and I don't grab the current WAL file. All I
> have is the last one to be archived before I did my backup, which is
> not late enough to do a valid restore. W
Yes, I think copying it while it is being written is safe.
---
Rick Gigger wrote:
> Yes! Thanks you! That is exactly what I was looking for.
>
> So I take it that this means that it is save to copy the current in
> use
On Jan 30, 2006, at 6:58 PM, Tom Lane wrote:
Rick Gigger <[EMAIL PROTECTED]> writes:
And here is the real million dollar question. Let's say for some
reason I don't have the last WAL file I need for my backup to be
valid. Will it die and tell me it's bad or will it just start up
with a screwe
Rick Gigger <[EMAIL PROTECTED]> writes:
> And here is the real million dollar question. Let's say for some
> reason I don't have the last WAL file I need for my backup to be
> valid. Will it die and tell me it's bad or will it just start up
> with a screwed up data directory?
It'll restore
And here is the real million dollar question. Let's say for some
reason I don't have the last WAL file I need for my backup to be
valid. Will it die and tell me it's bad or will it just start up
with a screwed up data directory?
On Jan 30, 2006, at 4:29 PM, Rick Gigger wrote:
Yes! Tha
Yes! Thanks you! That is exactly what I was looking for.
So I take it that this means that it is save to copy the current in
use WAL file even as it is being written to?
And it also means that if I copy it with my physical file system
backup then I should have the last file that I need to r
Unfortunately, I think I understand your question. :-)
These TODO items are what you need:
* Point-In-Time Recovery (PITR)
o Allow point-in-time recovery to archive partially filled
write-ahead logs [pitr]
Currently only full WAL files are archived. T
I guess my email wasn't all that clear. I will try to rephrase. I
am moving from using the old style pg_dump for backups to using
incrementals and want to make sure I understand the process before I
go about writing a bunch of scritps.
To me setting up incremental backup consists of the f
Sorry for my sharp reply! It looks like we are after the same thing
so that does help a little although it doesn't really answer my
question. I set up my backups system using pg_dump back in 7.3
because that's all there was. I am finally moving to 8.1 and want to
switch to doing incremen
Rick Gigger wrote:
Um, no you didn't read my email at all. I am aware of all of that and
it is clearly outlined in the docs. My email was about a specific
detail in the process. Please read it if you want to know what my
actual question was.
I'm not sure your email is quite right as regard
OK, that was before going home from work, so it could be excusable :-D
I read your mail now in more detail, and I can't answer it other than
that we use here a standby data base based on WAL log shipping, and the
procedure of building the standby finishes with a script
inserting/deleting a few 1000
Um, no you didn't read my email at all. I am aware of all of that
and it is clearly outlined in the docs. My email was about a
specific detail in the process. Please read it if you want to know
what my actual question was.
Thanks,
Rick
On Jan 26, 2006, at 10:41 AM, Csaba Nagy wrote:
I didn't read your mail very carefully, but I guess you want:
- turn on WAL archiving, and archive all WAL logs;
- take the file system backup at regular time points, optionally you
can keep them also for point in time recovery;
Then you always have all the WAL files you need to recover to an
On 7/3/2004 9:11 AM, Martin Marques wrote:
El Vie 02 Jul 2004 18:39, Jan Wieck escribió:
On 6/22/2004 11:51 PM, mike g wrote:
> Slony version 1 is supposed to be live very soon. You can test beta3 if
> you like.
Slony-I version 1.0 is out now. It does not contain incremental backup.
This feature i
After takin a swig o' Arrakan spice grog, [EMAIL PROTECTED] (Martin Marques) belched
out:
> El Vie 02 Jul 2004 18:39, Jan Wieck escribió:
>> On 6/22/2004 11:51 PM, mike g wrote:
>> > Slony version 1 is supposed to be live very soon. You can test beta3 if
>> > you like.
>>
>> Slony-I version 1.0 i
El Vie 02 Jul 2004 18:39, Jan Wieck escribió:
> On 6/22/2004 11:51 PM, mike g wrote:
> > Slony version 1 is supposed to be live very soon. You can test beta3 if
> > you like.
>
> Slony-I version 1.0 is out now. It does not contain incremental backup.
> This feature is on the TODO list for 1.1.
I'
On 6/22/2004 11:51 PM, mike g wrote:
Slony version 1 is supposed to be live very soon. You can test beta3 if
you like.
Slony-I version 1.0 is out now. It does not contain incremental backup.
This feature is on the TODO list for 1.1.
Jan
Perhaps pgpool could help you. Version 2 was just released
On Thu, 19 Jun 2003, Matthew Nuzum wrote:
> Regarding backup history:
>
> I have an application designed for novices. Apparently it's easy to hit the
> "Delete" button, and then say yes to the "Are you sure you want to delete
> this?" question even when they don't want to. Therefore I simply mar
Regarding backup history:
I have an application designed for novices. Apparently it's easy to hit the
"Delete" button, and then say yes to the "Are you sure you want to delete
this?" question even when they don't want to. Therefore I simply mark a
record as deleted. For example,
UPDATE table SE
On your second question:
Keeping old data helps with data analysis, i.e., data mining. I would do the fired date as transactions. To see if an employee is still and employee, look for the latest transation, hired, rehired, contracted with as a temp/consultant, fired, laid off, etc.
Antonios Chris
Antonios Christofides <[EMAIL PROTECTED]> writes:
> Is this filenames-instead-of-BLOBs for easier backup common practice?
> Any other ideas or comments?
This is a major point of contention. Some people think keeping all data in the
database is a better approach, others think data that isn't inhe
41 matches
Mail list logo
