Backups and replication are two different things.
Backups provide a snapshot of data at a given point. They provide a restore point.
Replication is distributing every action to a different system so you have it at more than one location. Deletes are also replicated.
If you really want to be fault tolerant, you need to have both. (And more…)
So replication only solves the problem of having current data in multiple places. Backups provide the method to restore a system to a given point in time.
Discourse uses 2 mechanisms for storage:
- PostgreSQL database for everything except attached files
- Attached files store on the local system or in S3
To backup and/or replicate the data stored in the PostgreSQL database you can check the PostgreSQL documentation for how to do that. Concerning backups, and replication.
Attached files is a bit more tricky. If you store in on S3 you can use S3 backups. For locally stored files you can use a variety of local system options.
Creating full backups is a heavy task depending on the amount of data. So cannot easily do that more often. Discourse’s standard backup procedure is to create full backups. If you really want to reduce the risk of losing data you need to look for other options.
One option might be provided by your hosting service: volume snapshots. This provides for a way to make an “instant” copy of data stored in a volume. This allows you to restore the volume do that time. Volume snapshots might also be available within the OS depending on the used file system. (btrfs supports this for example.)
Besides that, the PostgreSQL documentation also goes into making more continuous backups of the database allowing for excellent point-in-time-recovery of the database. (Don’t forget to ship the backups off-site.) This is much faster than full backups.
For more granular attachment backups you can use various backup tools which allow for managing full+differential backups. For example duplicity. Or you could rsync (without delete). Between the snapshots you would still be able to lose files. Using S3 without deletion would be safer as the files are already on an other system.
To conclude. Discourse’s standard backup mechanism is not well suited for a more frequent backup schedule. If you want to have more backups, use a combination of the standard PostgreSQL backup/replication features, S3, volume snapshots, etc.
On my site I don’t use Discourse’s backup system for regular backups. I still have daily backups, but I use a combination of pg_dumps and duplicity configs (coordinated via backupninja).
