Re: Snapshot backups

From: James Sewell <james(dot)sewell(at)lisasoft(dot)com>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: Snapshot backups
Date: 2013-06-21 00:17:58
Message-ID: CANkGpBv4c8neu4Uk3=j1aHD4xn+NFK0XNREfi3D-mj46vwEUGg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Thanks Magnus,

Could you elaborate a bit more on this?

I've been having a look at do_pg_start_backup() and I can't really see
anything apart from enabling full page writes and running a checkpoint to
avoid getting a torn page. I could be missing something easily though, as
I'm not familiar with the codebase.

do_pg_stop_backup() isn't really of consequence, as the backup is taken
before this - so any restore is to a point in time before this as well.

I was under the impression a restore was (more or less) the same as a crash
recovery, and logically it seems like PGDATA snapshot is equivalent to a
crash/restart (disk at a discrete point in time).

I can understand if log replay might take longer, but I am struggling to
see how it could result in an inconsistent state?

As I said I know this isn't best practice, but just want to understand how
it works.

Cheers,

James Sewell
Solutions Architect
_____________________________________

[image:
http://www.lisasoft.com/sites/lisasoft/files/u1/2013hieghtslogan_0.png]

Level 2, 50 Queen St,
Melbourne, VIC, 3000

P: 03 8370 8000 F: 03 8370 8099 W: www.lisasoft.com

On Thu, Jun 20, 2013 at 6:34 PM, Magnus Hagander <magnus(at)hagander(dot)net>wrote:

>
> On Thu, Jun 20, 2013 at 8:45 AM, James Sewell <james(dot)sewell(at)lisasoft(dot)com>wrote:
>
>> Hey All,
>>
>> This is a message to confirm my thoughts / validate a possible approach.
>>
>> In a situation where PGDATA and {XLOG, ARCHIVELOG} are on different
>> SAN/NAS volumes and a backup is to be initiated do pg_start_backup and
>> pg_stop_backup need to be used?
>>
>> I am using snapshots of each volume for backup.
>>
>> My thinking is that they are not needed (although I realise it is good
>> practice).
>>
>> As far as I can tell all they are doing is something like:
>>
>> pg_start_backup:
>> - create backup label
>> - trigger checkpoint
>>
>> pg_stop_backup
>> - remove backup label file
>> - creates backup history file
>> - trigger log switch
>>
>> There is nothing in here that is *required* from a backup point of view.
>> Am I missing anything?
>>
>
> The backup functions also set internal state in the database, so you can't
> just replace it with doing those operations manually. You do need to call
> those functions.
>
> --
> Magnus Hagander
> Me: http://www.hagander.net/
> Work: http://www.redpill-linpro.com/
>

--

------------------------------
The contents of this email are confidential and may be subject to legal or
professional privilege and copyright. No representation is made that this
email is free of viruses or other defects. If you have received this
communication in error, you may not copy or distribute any part of it or
otherwise disclose its contents to anyone. Please advise the sender of your
incorrect receipt of this correspondence.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message 高健 2013-06-21 00:24:54 Re: Tow kinds of different result while using create index concurrently
Previous Message James Sewell 2013-06-20 23:28:54 Re: LDAP authentication timing out