Re: [hfdb] Re: Grand Unified Hardware Database

[Zenaan Harkness]

On Tue, 2004-07-27 at 13:20, James K. Lowden wrote:
> On Tue, 27 Jul 2004 07:32:01 +1000, Zenaan Harkness <address@hidden>
> wrote:
> > CVS is the archive tool on savannah AIUI. We'll think about it more
> > later, but I suspect something more compact than the entire db (which
> > will be mostly the same one night to the next) will be desirable.
> > 
> > This format needs to be:
> >  - human readable (ie. text, not binary)
> >  - usable to recreate/ restore the database
> 
> I basically agree.  Question: will we have any reason to restore the
> database to its status as of any arbitrary point in time.  Is it not
> sufficient to be able to go back a week/month/year?  As a technical
> matter, if the database grows to a substantial size, CVS updates (and
> storage) of database dumps will become nontrivial and perhaps infeasible. 

We don't need point-in-time recovery.

Rationale: if the database discs die for instance, we go back to our
last backup, and restore the database from there, and go the
(submissions) mailing list, and add any submissions more recent than the
recovery data.

We want to not have to manually re-insert "too many" submissions due to
a too-old db backup. I'd say a weeks worth should be acceptable.

This implies we need a mailing list to which all successful submissions
are CC'd to, so we can use them for recovery if needed.

> Archival storage is not common practice among DBAs.  

We need to be able to recover the database.

This must be failsafe - as in, we cannot have even the possibility of
losing the data. This is a requirement if we aim to be a grand and
unified database for our free software community.

It might be, that a submissions mailing list, and backups of the
database on say a weekly basis, which are mirrored by two or three
different sites (/people), are enough to provide this assurance.

CVS storage of the database is certainly not a necessity. But a
guarantee of data safety certainly is. If I have a copy of a backup of
the database, I would be most comfortable if that data is in a human
readable format.

Naturally, the stored procedures and other constraints - the db schema -
also needs to be part of the backup process.

Thanks for helping to clarify this.

cheers
zen