-*-text-*-
$Header: /CVSROOT/public/scylla-charybdis/md5backup/doc/metadata.txt,v 1.1 2004/05/09 23:25:12 tino Exp $

Some words to metadata logs:
============================

It cannot be stored under the backup prefix in the db.
Not for the size, but the db must not keep important
information.  Everything needed for a restore *must*not*
be stored in a binary format which cannot be read by a
human easily.  It should be easily parsable by a shell
as well.  Odysseus is no real solution, as metadata is
frequently changing, so it should not go into the md5
file store.  It shall be protected by md5 sums, though.

Idea:

Gather metadata for each target while scanning, this is
a peace(!) of cake.  In the header write some clear
information when this metadata was gathered and for
which target.   In the header write some good information
for disaster recovery instructions, too.  It should even
not be too complicated to make it the restore shell script!

Write this file into tmp/.  Calculate the md5 sum of this
metadata log while writing it.  Store the md5 sums of all
files found into the metadata log as well.  Use a format
which can be easily transformed into an md5 compatible file
(with a single line of sed or a commandline instruction).
After a target is finished, store this file under it's
MD5 sum into a metadata storage.  Append this MD5 sum to
the main logs for ease.  And keep a history queue of
some previous metadata logs.  This history can be kept in
the database, as if it is lost, nothing is harmed.

The output shall as well be able to do a compare, such
that one can test if the restore will be functional.

Good idea.  Make it so.

As soon as this is stable, md5backup will probably reach
version 1, it's beta phase.

-Tino
$Log: metadata.txt,v $
Revision 1.1  2004/05/09 23:25:12  tino
copied from TODO