Hi, sorry for the extremly late reply, u fully forgot about that.
Yes i have tried out using snapshots and it worked perfectly fine. Of course when making a snapshot you should ensure your reflex app has stopped so you wont get any problems with caching. If you dont want to stop your reflex app you could snapshot memory too but what i have learnt is not to do that.
Backup is still needed 100% if you are using databases, in that case i would ONLY backup the databse and make a snapshot of the server where the app is running on. Backups could make your storage pretty full after some time, wont happen that fast with snapshots.
Right now I run our reflex apps on hetzner servers, and I do daily backups of Hetzner.
However, if e.g. the backup is done at midnight, a user pays at 10am and I save it in the database, and I mess up the database at 11am, the entries for this user are lost because the last backup didn’t account for the most recent changes.
I’m thinking about something like a managed postgres database on AWS and just connecting my reflex app with it.
Basically just having a single AWS RDS postgres database, and creating a different schema for each of my reflex apps.
Using the cheapest AWS configuration that would cost 17$/mo for single availability zone, 20GB storage included.
But with Single-AZ the backups they do are still not real time, so the same scenario as with the hetzner backups could happen.
Multi-availability zone only costs double, and then there’s very low chance of any data loss.
Also encryption at rest is handled by AWS automatically.
I think I’ll try out this route, cause hosted supabase is too expensive, self hosted supabase really complicated to set up, and just using AWS RDS seems quite simple i.e. low maintenance cost.
Switching to AWS RDS for PostgreSQL with Multi-AZ sounds like a solid plan to ensure higher availability and reduce the risk of data loss. AWS’s managed backups and encryption features provide strong safety, and the Multi-AZ setup adds resilience against server or zone failures.
You could also consider enabling Point-in-Time Recovery (PITR) on AWS RDS. This allows you to restore your database to any point within a specified retention period (up to 35 days), which can be helpful in scenarios where recent changes need recovery. It might slightly increase costs due to storage requirements for transaction logs, but it adds an extra layer of data security.
In addition, using incremental backups can be an effective way to ensure data integrity with minimal storage overhead. Incremental backups only capture the changes since the last backup, which makes them more storage-efficient compared to differential backups, which capture all changes since the last full backup. Since AWS RDS already manages automated backups, this could complement that system by giving you more control over your backup strategy.