From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Dan Gorman <dgorman(at)hi5(dot)com> |
Cc: | "Simon Riggs" <simon(at)2ndquadrant(dot)com>, "Toru SHIMOGAKI" <shimogaki(dot)toru(at)oss(dot)ntt(dot)co(dot)jp>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: PITR Backups |
Date: | 2007-06-22 17:12:02 |
Message-ID: | 23875.1182532322@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Dan Gorman <dgorman(at)hi5(dot)com> writes:
> This snapshot is done at the LUN (filer) level, postgres is un-aware
> we're creating a backup, so I'm not sure how pg_start_backup() plays
> into this ...
That method works too, as long as you snapshot both the data files and
WAL files --- when you start PG from the backup, it will think it
crashed and recover by replaying WAL. So, assuming that the snapshot
technology really works, it should be exactly as reliable as crash
recovery is. If you saw a problem I'd be inclined to question whether
there is some upstream component (OS or disk controller) that's
reordering writes.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2007-06-22 17:45:57 | Re: PITR Backups |
Previous Message | Dimitri | 2007-06-22 16:04:18 | Re: Data transfer very slow when connected via DSL |