I would think that it would be even easier than that -- simply write a separate 20-line python script that starts a transaction (thus assuring that no one else is writing to the db while the file is being copied), then forks an rsync to copy the single database file to another file on the local machine (or use file system snapshots), does a rollback to end the transaction, and finally rsyncs the copy off to the backup machine.
A cron to kick off the backup program once an hour (or whatever) ensures continual backups. Steve Friedman John Stanton wrote: > It would be a relatively minor job to make Sqlite replicate itself. The > partitioning in its design seperates the i/o level. > > Wade Williams wrote: >> I'm looking for an honest assessment from someone that may have made >> this decision in the past. >> >> I'm considering using an embedded database for an upcoming >> application. Operation rate is high 20,000-60,000 per day. (Those >> will mostly be selects, but some smaller percentage will be inserts). >> >> Our choices appear to be SQLite or Berkley DB. An RDBMS isn't really >> an option due to the administrative cost. >> >> My first inclination was to use SQLite. From what I've seen of the >> performance numbers, it should be able to support that rate without >> much trouble. >> >> However, a key feature is disaster recovery. If the primary machine >> goes down we've got to quickly switch to another machine (quickly >> meaning within minutes if not seconds). >> >> In my research it appears SQLite may not be a good option, since the >> only replication appears to be "lock the database and copy the file to >> the new machine." Berkeley DB seems to have the advantage of having >> replication built-in. However, I have no idea how useful the >> replication is and of course the API is much more inscrutable. I've >> also certainly heard all the Berkley DB corruption horror stories. >> >> I'm OK with stepping off the deep end into Berkeley DB, but I'd prefer >> SQLite. However, I'm certainly not looking to shoot myself in the foot. >> >> I'd appreciate input from anyone on this subject, especially tales >> from replication projects. >> >> Thanks, >> >> Wade >> _______________________________________________ >> 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 _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
