From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
Cc: | pgsql-patches(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Incrementally Updated Backup |
Date: | 2006-09-19 18:55:20 |
Message-ID: | 200609191855.k8JItKH08828@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
No, too late.
---------------------------------------------------------------------------
Simon Riggs wrote:
>
> Way past feature freeze, but this small change allows a powerful new
> feature utilising the Restartable Recovery capability. Very useful for
> very large database backups...
>
> Includes full documentation.
>
> Perhaps a bit rushed, but inclusion in 8.2 would be great. (Ouch, don't
> shout back, read the patch first....)
>
> -----------------------------
> Docs copied here as better explanation:
>
> <title>Incrementally Updated Backups</title>
>
> <para>
> Restartable Recovery can also be utilised to avoid the need to take
> regular complete base backups, thus improving backup performance in
> situations where the server is heavily loaded or the database is
> very large. This concept is known as incrementally updated backups.
> </para>
>
> <para>
> If we take a backup of the server files after a recovery is
> partially
> completed, we will be able to restart the recovery from the last
> restartpoint. This backup is now further forward along the timeline
> than the original base backup, so we can refer to it as an
> incrementally
> updated backup. If we need to recover, it will be faster to recover
> from
> the incrementally updated backup than from the base backup.
> </para>
>
> <para>
> The <xref linkend="startup-after-recovery"> option in the
> recovery.conf
> file is provided to allow the recovery to complete up to the current
> last
> WAL segment, yet without starting the database. This option allows
> us
> to stop the server and take a backup of the partially recovered
> server
> files: this is the incrementally updated backup.
> </para>
>
> <para>
> We can use the incrementally updated backup concept to come up with
> a
> streamlined backup schedule. For example:
> <orderedlist>
> <listitem>
> <para>
> Set up continuous archiving
> </para>
> </listitem>
> <listitem>
> <para>
> Take weekly base backup
> </para>
> </listitem>
> <listitem>
> <para>
> After 24 hours, restore base backup to another server, then run a
> partial recovery and take a backup of the latest database state to
> produce an incrmentally updated backup.
> </para>
> </listitem>
> <listitem>
> <para>
> After next 24 hours, restore the incrementally updated backup to
> the
> second server, then run a partial recovery, at the end, take a
> backup
> of the partially recovered files.
> </para>
> </listitem>
> <listitem>
> <para>
> Repeat previous step each day, until the end of the week.
> </para>
> </listitem>
> </orderedlist>
> </para>
>
> <para>
> A weekly backup need only be taken once per week, yet the same level
> of
> protection is offered as if base backups were taken nightly.
> </para>
>
> </sect2>
>
> --
> Simon Riggs
> EnterpriseDB http://www.enterprisedb.com
[ Attachment, skipping... ]
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faq
--
Bruce Momjian bruce(at)momjian(dot)us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-09-19 19:00:13 | Re: -HEAD planner issue wrt hash_joins on dbt3 ? |
Previous Message | Zdenek Kotala | 2006-09-19 18:52:34 | Re: [HACKERS] DOC: catalog.sgml |
From | Date | Subject | |
---|---|---|---|
Next Message | Neil Conway | 2006-09-19 19:05:25 | Re: Notes on restoring a backup with --single-transaction |
Previous Message | Zdenek Kotala | 2006-09-19 18:52:34 | Re: [HACKERS] DOC: catalog.sgml |