Re: [Gramps-users] [Gramps-devel] [Fwd: Help! Database corruption]

[Benny M. <ben...@gm...>]

If the db files were not written to, then all was in the log I suppose.
Version 3.3 makes sure to clear the logs, so the problem of growing log
files should not occur anymore as long as users close gramps from time to
time... I advise people to have a look in their database directory
(~/.gramps/grampsdb) if that is indeed the case for them.

You are not the first to point us to this problem. I think we have these
kind of bug reports now since a year or so. However, we have not been able
to understand yet how or why it occurs, which makes fixing it difficult. We
believe it is something of the previous version. It is very worrying
however that the database recovery tools don't seem to work on this problem
(you are also not the first to say this to be the case). They have always
worked in the past when problems occur.

Benny

2011/11/21 Jeff Silver <jsg...@ja...>

> Thanks Michiel and Benny,
>
> Yes I did try db4.8_recover with various options, but did not get the data
> back.
> I took a snapshot of all the DB files, but unfortunately only *after* I'd
> attempted recovery via gramps.
> It looks like the data has gone, and I don't want to use lots of other
> people's time in trying to recover it. (I still have all the paper source
> materials.)
> I was mostly intrigued by the 'strings' result showing that the data still
> seemed to be present in the log file, and by the fact that the .db files
> had not been written to for months.
> Also, the DB was on an NFS-mounted partition, and 'strings' from the log
> file shows a strange mix of pathnames; some matching the directory
> hierarchy on the NFS-client where gramps is running, and some matching the
> NFS-server.
> I guess I'd have to delve deeply into BDB to figure that out, and I'd do
> better to spend my time setting up a proper backup strategy. (And I'd
> rather let the developers get on with developing!)
>
> I's be happy to hear other suggestions, but I wouldn't want anyone to
> spend a lot of time on it.
>
> Thanks again.
> --
> Jeff
>
> On Mon, 21 Nov 2011 09:31:23 +0100, Benny Malengier
> <ben...@gm...> wrote:
> > Jeff,
> >
> > The first is to keep a full backup of the .gramps/grampsdb directory,
> > before you attempt any recovery.
> >
> > The second is that we direct people to:
> >
>
> http://gramps-project.org/wiki/index.php?title=Recover_corrupted_family_tree#What_to_do_now.3F
> >
> > The third is that the .gbkp files in the database directories are
> backups,
> > so you can rename those to .db, and try to open/recover them
> >
> > The fourth is that if you believe you lost too much information to
> reenter,
> > and recovery did not work, you can send the entire directory with the
> bad
> > database privately to a developer. Me for example.
> >
> > When you have your data back, please upgrade to latest version. Bugs are
> > removed, and the last version flushes the log more than the 3.2 version.
> >
> > Benny
> >
> > 2011/11/20 Jérôme <rom...@ya...>
> >
> >>
> >>
> >> -------- Message original --------
> >> Sujet: [Gramps-users] Help! Database corruption
> >> Date: Sun, 20 Nov 2011 09:55:31 +0000
> >> De: Jeff Silver <jsg...@ja...>
> >> Pour :: <gra...@li...>
> >>
> >> My wife has spent many hours entering data in our gramps database.
> >> One day, we got the warning that the database needed to be repaired.
> >> Maybe
> >> we shut down inelegantly.
> >> After the repair, all the recently added data seemed to be missing.
> >> I ran 'strings' on the log.0000000001 file and saw a lot of stuff that
> >> was
> >> definitely some of the missing data.
> >> The various .db and .gbkp files had not been updated for a long time.
> >>
> >> I don't know a lot about the workings of Berkeley DB, but I guess that
> >> the
> >> .db files were not updated because the log.0000000001 file had not got
> >> big
> >> enough to have its contents flushed, but I'm happy to be corrected on
> >> that.
> >>
> >> I'm running Gramps 3.2.3-1.
> >>
> >> I have now instituted a regular-copy backup to let me recover if this
> >> happens again (yes yes, I should have done that before).
> >>
> >> But does anyone have any ideas as to how I can recover or extract the
> >> data
> >> that seems to be in the log.0000000001 file?
> >>
> >> --
> >> Jeff
>
>