"The power has failed recently though, maybe connected?"

Quite likely. Anything in the disk write cache will be lost on a power failure. Two ways to avoid that are:
1) Battery backup for your RAID
2) Disable write cache (which will of course have a performance penalty)

The database files would be actively changed, so any changes would be in the write cache resulting in a only partially written database when power returns.

Note that each db file is a separate sqlite database. You will only need to repair/delete the damaged one(s).

You might find that moving everything into a ODBC database with transaction support will result in less corruption if a power fails.

-Steve


On 18 August 2010 02:58, Brian May <brian@microcomaustralia.com.au> wrote:
On 7 August 2010 18:35, Brian May <brian@microcomaustralia.com.au> wrote:
>> As for how to do sqlite data recovery, try googling. e.g.
>> http://www.mail-archive.com/sqlite-users@sqlite.org/msg17538.html
>
> Thanks for the reference. I tried looking but obviously wasn't looking
> for the right search term.

Curiously I had the same problem reoccur. Unfortunately freeswitch
appears to work until some time after the initial problem, makes it
hard to find out what happened. The power has failed recently though,
maybe connected?

[ etc ]
2010-08-17 04:30:40.728489 [CRIT] switch_core_sqldb.c:938 SQL thread
unable to commit transaction, records lost!
2010-08-17 04:31:00.653705 [ERR] switch_core_sqldb.c:448 SQL ERR
[database disk image is malformed]
[ etc ]

huey:/opt/freeswitch/db# ls -l core2.db
-rw-r--r-- 1 freeswitch daemon 1502208 2010-08-15 17:11 core2.db
huey:/opt/freeswitch/db# sqlite3  core2.db
SQLite version 3.5.9
Enter ".help" for instructions
sqlite> .dump
BEGIN TRANSACTION;
COMMIT;

This is ext2 on flash memory. Maybe I should move core.db on to tmpfs?
I get the impression persistence isn't required for this file...