Re: Snapshot backups

Hey all,

I understand that I have already been given an answer here, but I am still
curious as to why this is the case (perhaps I should ask this on the
hackers list though, if so let me know).

More importantly I'd like to understand why I would need to use the
start/stop backup commands to ensure a valid backup when using filesystem
snapshots (assuming I get the order correct)- worst case scenario wouldn't
it be the same as a crash and cause an automatic roll-forward?

Cheers,
James

James Sewell
PostgreSQL Team Lead / 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 Fri, Jun 21, 2013 at 10:17 AM, James Sewell <james(dot)sewell(at)lisasoft(dot)com>wrote:

> 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.