Continuous backup is important for disaster recovery. The more frequent the backup, the less data would be lost in the event of restoring from backup.
The usual destination for backups is S3, the amazon-compliant object storage.
For added redundancy and resilience (and geographical distribution as well) a single backup can be placed on to several destinations.
The server that does backups for me, is the server that I use for a lot of automation: jenkins. I run a jenkins job (executing daily) for each resource (such as a database) that I'm backing up. There are dozens of such jobs running on a mature Jenkins instance.
It is customary to do backups daily - it is a convenient schedule. My system for backing up makes two copies (of a single entity being backed up): for the day, and for the month. With the naming conventions that I have put in place, this pattern has proven useful in real-world applications. Let's say I have a bucket with backups from several different resources. I may structure is like so:
<BACKUP_ROOT>/2025/202501/20250101_my-special-resource_environment2.sql.tar.gz
<BACKUP_ROOT>/2025/202501/20250102_my-special-resource_environment2.sql.tar.gz
<BACKUP_ROOT>/2025/202501/ ...
<BACKUP_ROOT>/2025/202501/20250101_my-other-resource_environment5.sql.tar.gz
<BACKUP_ROOT>/2025/202501/ ...
<BACKUP_ROOT>/2025/202501_my-special-resource_environment2.sql.tar.gz
<BACKUP_ROOT>/2025/202501_my-other-resource_environment5.sql.tar.gz
<BACKUP_ROOT>/2025/ ...One of the reasons for this is that if I have hundreds of backup files in a bucket, it's difficult to list them. So I'd put them in a folder by-month. It's also easier to manually delete backups by-month this way, when needed.
The monthly backup gets overwritten daily. Meaning, for example, that on day 20250505 I would make a backup of a resource to timestamps 20250505 and 202505. The latter overwrites the one made on 20250504, with the same name. On the one hand, I still have the daily backup, if I need it. On the other hand, I don't need to look for the latest backup, since it is the latest for the month, not for the day. And the disadvantage of this verbose approach is that more space is consumed: rather than one backup, you are making a few more (8.33% more, since you are effectively making one more backup per month). The disadvantage is probably insignificant, especially if you regularly clean up old unneeded backups. The cleanup process can also be automated.
~ * ~ * ~ * ~
The security of the backup is as important as the security of the application overall. If an application can be restored from a backup like from a seed, then it is as valuable as the application itself. Be cognizant of the restrictions and the barriers to access of the backups that you create and maintain. Consider forcing encryption of all backups.
It is a balance to have many enough backups in many enough places, and have them secure and unaccessible to unauthorized people and organizations. Encryption does help here: if properly encrypted, and keys are truly secret, then you can have more copies of backups stored in multiple places.