From: | Philip Warner <pjw(at)rhyme(dot)com(dot)au> |
---|---|
To: | Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at>, "'Mikheev, Vadim'" <vmikheev(at)SECTORBASE(dot)COM> |
Cc: | "'pgsql-hackers(at)postgresql(dot)org'" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: AW: AW: Backup, restore & pg_dump |
Date: | 2000-10-18 10:39:59 |
Message-ID: | 3.0.5.32.20001018203959.02885740@mail.rhyme.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
At 10:38 18/10/00 +0200, Zeugswetter Andreas SB wrote:
>
>We should not call this tx log business "Incremental backup"
>an incremental backup scans all pages, and backs
>them up if they changed in respect to the last higher level backup.
>(full backup, level 1 backup, level 2 backup ....)
You may be tying implementation too closely to function; so long as
succesive incremental backups are (a) incremental since the last higher
level backup, and (b) sufficient to restore the database when cobined with
other incremental backups, then ISTM that the method of deriving the backup
(from logs, or reading data pages) is irrelevant.
I too am used to incremental backups that actually read data pages, but if
the WAL has enough information to determine the pages, the why not use
it...but maybe I'm missing something.
----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.B.N. 75 008 659 498) | /(@) ______---_
Tel: (+61) 0500 83 82 81 | _________ \
Fax: (+61) 0500 83 82 82 | ___________ |
Http://www.rhyme.com.au | / \|
| --________--
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/
From | Date | Subject | |
---|---|---|---|
Next Message | Timaran Ricardo | 2000-10-18 11:36:50 | Re: Documentation about compiler Postgres |
Previous Message | Zeugswetter Andreas SB | 2000-10-18 10:03:59 | AW: AW: AW: Backup, restore & pg_dump |