Fwd: Long term database archival

From: "Marco Bizzarri" <marco(dot)bizzarri(at)gmail(dot)com>
To: pgsql-general(at)postgresql(dot)org
Subject: Fwd: Long term database archival
Date: 2006-07-12 19:03:19
Message-ID: 3f0d61c40607121203v6fa51f49lbb20b7bd768662a1@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

---------- Forwarded message ----------
From: Marco Bizzarri <marco(dot)bizzarri(at)gmail(dot)com>
Date: Jul 12, 2006 9:03 PM
Subject: Re: [GENERAL] Long term database archival
To: "Karl O. Pinc" <kop(at)meme(dot)com>

Long term archival of electronic data is a BIG problem in the
archivist community. I remember, a few years ago, a paper describing
the problem of historical (20+ years old) data which were running the
risk of being lost simply because of lacking of proper hardware.

What I would suggest is to explore the problem trying to search first
with experience and research already done on the topic. The topic
itself is big, and it is not simply a matter of how you dumped the
data.

A little exploration in the archivist community could produce some
useful result for your problem.

Regards
Marco

On 7/6/06, Karl O. Pinc <kop(at)meme(dot)com> wrote:
> Hi,
>
> What is the best pg_dump format for long-term database
> archival? That is, what format is most likely to
> be able to be restored into a future PostgreSQL
> cluster.
>
> Mostly, we're interested in dumps done with
> --data-only, and have preferred the
> default (-F c) format. But this form is somewhat more
> opaque than a plain text SQL dump, which is bound
> to be supported forever "out of the box".
> Should we want to restore a 20 year old backup
> nobody's going to want to be messing around with
> decoding a "custom" format dump if it does not
> just load all by itself.
>
> Is the answer different if we're dumping the
> schema as well as the data?
>
> Thanks.
>
> Karl <kop(at)meme(dot)com>
> Free Software: "You don't pay back, you pay forward."
> -- Robert A. Heinlein
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
> choose an index scan if your joining column's datatypes do not
> match
>

--
Marco Bizzarri
http://notenotturne.blogspot.com/

--
Marco Bizzarri
http://notenotturne.blogspot.com/

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Bruno Wolff III 2006-07-12 19:08:05 Re: Dynamic table with variable number of columns
Previous Message Joseph Shraibman 2006-07-12 18:54:54 Re: VACUUM FULL versus CLUSTER ON