...

• The host running the replication script connects to the leader of the production cluster (using SSH or MySQL).
• A full backup of the MySQL Database is created, using mysqldump.
• The MySQL backup is compressed and stored onto the shared NFS mount.

...

With all data stored on the NFS mount, the contents of the entire mount are replicated to the BCP datacenterdata center.
This can be done using Rsync via SSH or using a storage vendor related replication technology (e.g. Netapp SnapMirror)

...

For maximum safety, we recommend to separate both scenarios in the NFS mount. This way an accidental reversal of the direction cannot lead to unwanted data loss.

Reduced number of nodes in BCP

The ideal setup is to run production and BCP with the exact same setup. This way the user experience will not degrade when a failover to BCP occurs.
It is however possible to run a reduced setup in BCP. E.g. instead of 3 nodes, only 1 node can be used.

Note that you should never run an even number of Squirro application and Elasticsearch nodes since both system benefit from the ability to build quorums to detect and handle network segmentation events.

Backup the NFS mount

It is highly recommended that  the NFS mount is regularly backed up or protected by a vendor specific snapshotting technology.
The NFS mount can be easily used to restore previous cluster states, and is ideal for disaster recovery. 

...

The issue is minor if the SSO integration is active since the user will be logged in automatically.