On Tue, 2018-12-04 at 11:27 +0000, lejeczek wrote: > On 28/11/2018 21:25, Jan Pokorn� wrote: > > On 26/11/18 09:10 +0100, Ulrich Windl wrote: > > > > > > lejeczek <[email protected]> schrieb am 23.11.2018 um > > > > > > 15:56 in Nachricht > > > > > > <[email protected]>: > > > > hi guys, > > > > > > > > Do we have tools or maybe outside of the cluster suite there is > > > > a way to > > > > backup cluster? > > > > > > > > I'm obviously talking about configuration so potentially > > > > cluster could > > > > be restored if need be. > > > > > > Something like "crm configure show >>your_backup_file"? Here we > > > create such a file hourly (with history) if the configuration had > > > changed... > > > > If that's indeed the questioned procedure[*] and it's pcs that > > is a weapon of choice, there's clufter tool to achieve something > > similar (see "clufter pcs2pcscmd" and derived, further > > qualified subcommand thereof, or indirectly triggered with > > "pcs config export pcs-commands"). > > > > [*] at the rawest level, the pacemaker cluster configuration > > is a set of: > > - static configuration bits of pacemaker's CIB (as opposed to > > dynamic ones/status) > > many thanks. > > And if one wanted to tell his third-party backup tool, which just > goes > after "flat" files, what locations/dirs (of pcs, pacemaker, ...) > should > be included in such a backup?
For pacemaker: /var/lib/pacemaker/cib is the most important (configuration history). You can include all of /var/lib/pacemaker if you want core dumps, incident history, etc. If you have authentication tokens somewhere (e.g. /etc/pacemaker is a common choice for Pacemaker Remote keys), add that if it isn't handled separately. Add /etc/pacemaker/sysconfig if you make changes to it. For corosync, at least /etc/corosync. I don't think pcs keeps anything that can't be easily regenerated, but if you want to save a few steps, add /var/lib/pcsd. > > > - messaging/quorum layer configuration (e.g. corosync.conf) > > - respective configuration of the name lookup in the > > environment (e.g. /etc/hosts or configuration of local > > DNS server + it's appointment in /etc/resolv.conf or > > at whichever authoritative location) > > - static prerequisites and possibly customized configuration > > for every and each employed resource unless fully > > configurable > > by the means of respective agents > > - other notable operating system level settings > > (firewall, watchdog kernel modules etc.) > > - physical node interconnect setup (or virtualized > > equivalent), incl. which network interfaces are > > available and how are they mapped in the topologies > > - "panned out wider picture arrangement" related > > configuration (e.g. when the cluster has its mirror peers > > in a booth formation) > > - ... (plethora of things I forgot to mention) > > You can see that it's really an open scoped term that > > could creep arbitrarily wide, but usually just two first > > points are subsumed, but that consequently means that's > > not something that would be easily portable/reproducible > > elsewhere in its entirety, but again, usually such backups > > would be for a local rollback/reinstating only (discretion > > in doing so is hopefully apparent). > > Just a thought experiment: for an isolated single machine, > > one can put the workload into the VM, freeze it and carry > > such a capsule as sort of a full-state backup, no problem > > -- good luck extrapolating this method to a cluster, but > > definitely would be an interesting project ;-) > > > > > You can also create textual context diffs automatically, or use > > > "cibadmin -Q -o configuration" instead of "crm configure show"... > > > > _______________________________________________ > > Users mailing list: [email protected] > > https://lists.clusterlabs.org/mailman/listinfo/users > > > > Project Home: http://www.clusterlabs.org > > Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratc > > h.pdf > > Bugs: http://bugs.clusterlabs.org > > > _______________________________________________ > Users mailing list: [email protected] > https://lists.clusterlabs.org/mailman/listinfo/users > > Project Home: http://www.clusterlabs.org > Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch. > pdf > Bugs: http://bugs.clusterlabs.org _______________________________________________ Users mailing list: [email protected] https://lists.clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
