Hi Bryan, Backup data is a mean to restore your cluster after all nodes in the group are lost, for example, when the data centre hosting the cluster is hit by natural disaster like flood, hurricane, etc. Even when one node from the group survives you can rebuild your cluster from it by removing lost nodes and adding new nodes if required. Though the probability of loosing all nodes is quite low, you need to have a strategy to restore your system from backup. It is up to your business to define how much data can be lost. You can backup data every 15 minutes if required. Ideally you would want to backup data on every node as backup utility is not aware about the state of the group.
Kind Regards, Alex On 13 March 2018 at 15:57, bryand <[email protected]> wrote: > Thanks for the reply Alex. > > I've been working on our production Broker-J backup and recovery solution > and my plan was to create a little Java app that utilizes the Broker-J > provided BDBBackup class and perform a hot backup every 15 minutes. Ideally > we'd never have to use it but things happen (our production ActiveMQ KahaDB > got corrupted just last week). I've been reading through the Berkeley DB > Java Edition and comments in the BDBBackup class and am wondering if > performing the hot backup every 15 minutes will cause any issues with how it > locks files? Once we migrate all of our ActiveMQ clients over to be > Broker-J clients we will have a fairly active messaging environment in > production. > > Also, I've been wondering what the first approach of our production recovery > process should be. Being that I'm only planning on taking a hot backup > every 15 minutes if we use those backups then we'll be losing any changes > made since that last backup. Would it be best to try to utilize one of the > replicated databases and the DbResetRepGroup capability you mentioned in > hopes that corrupted changes hadn't made it to both of the replica databases > yet? And then if that doesn't recover the Berkeley DB use our backups as > more of a last resort since it could result in missing messages? > > Just curious on what people have come up with for the production > backup/recovery approaches. > > Thanks > Bryan > > > > -- > Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
