[antoinealb]

Does that mean it's okay for your application to loose transactions (which occured between the backup point and the failure point) or do you have other mitigations ?

[benbjohnson]

I'm the author of Litestream, which is an open-source tool for streaming replication for SQLite. That could be a good option if you need to limit your window for data loss. We have a pretty active Slack if you need help getting up and running. https://litestream.io/

[habibur]

Guess this daily 2 seconds of downtime is worth it, when that reduces cost say from $2000/month to $20/month.

[mrweasel]

Many banks still “shutdown” for hours every night to do backups.

[finiteseries]

I’m not anywhere near the banking industry but from HN alone I’ve been led to believe dailyish huge file transfers are also the norm in a variety of situations (aka SQLite’s backup strategy).

[ericlewis]

ftp or sftp if you're lucky - upload a giant CSV or receive one. It is crazy to me it still works this way.

[gryn]

and sometimes CSVs sent by mail on a set frequency (by a bot i'm guessing?)

[Spivak]

Isn't that how all backups work? If you need to prevent data loss then backups probably aren't your tool of choice. And if you're paranoid about data loss then any replication lag is also unacceptable.

* I'm worried about my server blowing up: Transactions have to be committed to more than one DB on separate physical hosts before returning.

* I'm worried about my datacenter blowing up: Transactions have to be committed to more than one DB in more than one DC before returning.