Since an Sqlite database is a single file taking a snapshot backup is very simple and rapid. You could maintain an almost current image at all times that way. Complete recovery could be possible by modifying Sqlite oryour application to keep a journal of SQL statements processed between snapshot backups.
A better strategy would be to ensure that you used a reliable server. We have never had a corrupted Sqlite database on our Linux or AIX aervers. JS raf wrote: > Roger Binns wrote: > > >>raf wrote: >> >>>i also needed the ability to restore an sqlite3 database >>>after a corruption. >> >>What exactly are you doing that corrupts the database in the first >>place? If the machine you are using is randomly corrupting data then >>having your own journal won't help that much! >> >>If you are doing things like turning synchronous off then it is easier >>to have two database files (use ATTACH). Have one be the defaults (ie >>correctness, no corruption) at the expense of speed and the second be >>turned for speed at the expense of possible corruption. You can copy >>the data back and forth as necessary. >> >>Roger > > > i've never turned off synchronous. i set up my recovery > mechanism on the grounds that corruption is possible and i > wanted the website to heal itself should it ever happen. > > i've only ever had one real corruption (as reported by > pragma integrity_check). i have no idea what caused it but > it was nothing mentioned in the how to avoid corruption > document. however, because the .dump command doesn't report > errors, i had been interpreting its many failures to > function correctly as a sign of corruption. this was a > mistake on my part but one that was easy to make since i was > also receiving "malformed disk image" error messages from > the website at the same time. it turned out that these > messages always coincided with database recovery (i.e. it > didn't preceed them) and so were presumably signs of the > database being rebuilt after a false corruption 'detection'. > > the .dump failures were just due to the database being busy. > i now retry .dumps when its output is abnormally short > and it's very much better. > > however, i will keep the recovery system in place because, > as i said, there has been one real corruption, and it might > happen again and the recovery system works very well. > > cheers, > raf > > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
