Re: [Gramps-bugs] database corruption

[Don A. <don...@co...>]

Actually, if you upgrade to the 2.2.3 release (just released over the
weekend), there is a Autobackup feature, which is enabled by default. On
exit, your data is saved to a XML back file. So, if you ever encounter
and database corruption, you will always have a backup file you can get
back to.

Don

On Mon, 2006-11-27 at 22:05 -0800, Alex Roitman wrote:
> David,
>=20
> On Fri, 2006-11-17 at 13:54 -0500, David A Iacobellis wrote:
> > I have been using gramps for years and until now without the first glit=
ch. =20
> > Recently I have been entering a lot of data into gramps.  Yesterday I w=
ent to=20
> > start gramps and I received the error message that my database was corr=
upted=20
> > and gramps failed to start.  Fortunately I back up on a regular basis s=
o I=20
> > just loaded my backup and all was fine with the exception that I lost a=
bout 6=20
> > hours worth of data entry.  I was using version 2.0.11 of gramps at the=
 time=20
> > of the failure on a SuSE 10.0, AMD dual core 64 bit machine with the da=
tabase=20
> > stored on a 3 disk raid 5 array.  After I got the backup to work I upgr=
aded=20
> > to gramps v 2.2.1 (which is very nice).  This had the potential of bein=
g a=20
> > very big disaster.  Has anyone else experienced database failures such =
as=20
> > this?  What can I do to avoid this in the future?
>=20
> The only bullet-proof thing you can do is to export to XML from time
> to time and keep the XML safe. The current version, 2.2.3, is better
> than 2.2.1 in some regards, but from time to time we get reports of
> the database corruption. We usually cannot reproduce the problem,
> so it lingers there unfixed. It may be bug inside Berkeley db library
> or its python bindings.
>=20
> You can also try the Checkpoint tool. It would do exactly this:
> dump the uncompressed XML and use RCS to version-control it.
> You can also use custom scripts with it, if you want another
> archival method. RCS should work out of the box.
>=20
> But this way or another, if you do a lot of editing, just
> export to XML every so often and you should be OK in the face
> of any disaster. This is not to say that the disaster will
> necessarily happen, but better safe than sorry.
>=20
> An easy check for sanity for XML data is to see whether it ends
> with </database>. Exported data is also gzipped, so something
> like "zcat filename.gramps | tail" will display the end of the file.
> This is to make sure that the XML exported properly, with no
> errors preventing the normal export.
>=20
> Hope this helps,
> Alex
>=20
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share y=
our
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDEV
> _______________________________________________ Gramps-bugs mailing list =
Gra...@li... https://lists.sourceforge.net/lists/listi=
nfo/gramps-bugs