| ▲ | andersmurphy 7 hours ago | |||||||||||||
Backups, litestream gives you streaming replication to the second. Deployment, caddy holds open incoming connections whilst your app drains the current request queue and restarts. This is all sub second and imperceptible. You can do fancier things than this with two version of the app running on the same box if that's your thing. In my case I can also hot patch the running app as it's the JVM. Server hard drive failing etc you have a few options: 1. Spin up a new server/VPS and litestream the backup (the application automatically does this on start). 2. If your data is truly colossal have a warm backup VPS with a snapshot of the data so litestream has to stream less data. Pretty easy to have 3 to 4 9s of availability this way (which is more than github, anthropic etc). | ||||||||||||||
| ▲ | rienbdj 6 hours ago | parent | next [-] | |||||||||||||
My understanding is litestream can lose data if a crash occurs before the backup replication to object storage. This makes it an unfair comparison to a Postgres in RDS for example? | ||||||||||||||
| ||||||||||||||
| ▲ | locknitpicker 6 hours ago | parent | prev [-] | |||||||||||||
> Backups, litestream gives you streaming replication to the second. You seem terribly confused. Backups don't buy you high availability. At best, they buy you disaster recovery. If your node goes down in flames, your users don't continue to get service because you have an external HD with last week's db snapshots. | ||||||||||||||
| ||||||||||||||