[ClusterLabs] How to backup?

[Ken Gaillot]

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 <peljasz at yahoo.co.uk> schrieb am 23.11.2018 um
> > > > > > 15:56 in Nachricht
> > > 
> > > <46d2baf6-a03d-9aac-fceb-7bcffb3830dd at yahoo.co.uk>:
> > > > 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: Users at clusterlabs.org
> > 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: Users at clusterlabs.org
> 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