Skip to content

Instantly share code, notes, and snippets.

@lindhe
Last active September 12, 2024 15:03
Show Gist options
  • Save lindhe/94b2ec89158482063d20efa215abe187 to your computer and use it in GitHub Desktop.
Save lindhe/94b2ec89158482063d20efa215abe187 to your computer and use it in GitHub Desktop.
Backup requirements

Backup requirements

Different applications have different requirements when it comes to being backed up. Some applications works perfectly fine if a disk snapshot is taken, while others may require to first enter some sort of maintenance mode first to ensure data consistency. These are my personal notes on what requirements different software stacks has. I make no promises that any of this is true. What I do promise you is that this is not an exhaustive list.

OpenSearch (ElasticSearch)

OpenSearch has snapshots. If a snapshot exists on disk before the data is backed up, that data will for sure be consistent. For more details, see this post in the OpenSearch forum.

To reduce the gap between the latest snapshot and a backup, the snapshot API can be used in a pre-backup hook to take a new snapshot before backing up.

Another alternative is to enable remote-backed storage, but that probably has little additional value if one already takes snapshots and performs backups.

PostgreSQL

As mentioned in the documentation, it is a bad idea to try and backup by copying the live files used by PostgreSQL. It can work under some circumstances, but tl;dr use pg_dump/pg_dumpall instead!

Both Bitnami and Kubegres implements support for running a cronjob that writes a database dump to a separate volume. I think it is not very important to use a separate volume if the main volume is backed up externally. The biggest reason for using a separate volume is probably to reduce the size of the backup (and possibly to protect the backup volume from accidental file operations).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment