Hi Simon, there are multiple aspects to backup, data safety and time to recovery (TTR).
If your only goal is to have a separate copy of your data, backing up only one node of your database does the trick. However, if you want a short TTR, so your cluster is complete again as soon as possible, you want a backup of each of your nodes, so you can replay your backup at any time. Each node stores the data slightly differently on a physical level, which means restoring data from node A’s backup to node B is not trivial. While logically, this means you have three backups when you might only want one. If TTR is not a concern, you can just back up a single node to make sure you can restore that if needed, but rely on CouchDB internal backfill, if a node is replaced after a failure without data being added from a backup. This will take longer than restoring a node from its own backup. Best Jan — Professional Support for Apache CouchDB: https://neighbourhood.ie/couchdb-support/ 24/7 Observation for your CouchDB Instances: https://opservatory.app > On 7. May 2021, at 11:27, Simon Schwichtenberg <sschwichtenb...@dspace.de> > wrote: > > Hi, > > I wonder how you'd do backups of your data in a CouchDB cluster. The > documentation does not mention backups of clusters explicitly > (https://docs.couchdb.org/en/latest/maintenance/backups.html#database-backups). > > When you have a cluster of three nodes and the nodes are set to n=3 and q=2 > (see https://docs.couchdb.org/en/latest/cluster/sharding.html), I'd expect > that every single node in the cluster has all the data and you can copy the > .couch files from any of these three nodes. When you have 6 nodes with n=3 > and q=2 this approach does not work anymore because every node has just a > single shard. Please correct me if I am wrong. > > What is best practice to backup a cluster? > > This message is a follow-up from here: > https://github.com/cloudant/couchbackup/issues/349 > > Thanks, > Simon
