AW: AW: AW: Backup, restore & pg_dump

From: Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at>
To: "'Philip Warner'" <pjw(at)rhyme(dot)com(dot)au>
Cc: "'pgsql-hackers(at)postgresql(dot)org'" <pgsql-hackers(at)postgresql(dot)org>
Subject: AW: AW: AW: Backup, restore & pg_dump
Date: 2000-10-18 10:03:59
Message-ID: 11C1E6749A55D411A9670001FA6879633680B3@sdexcsrv1.f000.d0188.sd.spardat.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


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

Yes, definitely, but they actually refer to their redo logs directly,
not something extracted from the logs like you describe.
They call tx log backup incremental backup which we should avoid.

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

Something to think about later, but imho reading the data pages is The Way.

Do we have the info when a page was last modified (in respect to a WAL position,
not wallclock time) on each page ? This is probably an info we will need.

Andreas

Browse pgsql-hackers by date

  From Date Subject
Next Message Philip Warner 2000-10-18 10:39:59 Re: AW: AW: Backup, restore & pg_dump
Previous Message Hiroshi Inoue 2000-10-18 09:39:53 toast operations while locking a buffer