We need a space available for Disaster recovery

[David Andrew]

Hi all, and thanks in advance.

We have had 2 significant outages of our infrastructure in the last few weeks, both of wich left our knowledge base offline, so increasing the difficulty of brining it back.  This is provided to us as a service asn we have little to no control over the supply.

We already have a project to move to atlassian Cloud, but this is going slow and we need a interim solution (in action within a week) to make the one space available to the TECH team to assist with recovery and data consitency.

Questions/points for discussions/possible options include

- build a new confluence online (Cloud based servers azure amazon etc) adn migrate to that until atlassian cloud is ready

- Atlassian cloud temporary space ( but  how does single sign on etc work when we already have a tenancy)

- Export the space as static HTML site to a cloud solution as above (needs attachements etc and scheduled updates)

We are a vctim of atlassian becomeing more important to the business than planned and now we need confluence first in the event of a DR

[Nic Brough -Adaptavist-]

I've done the first option several times - a secondary DR Confluence set up in a second data centre somewhere away from the primary.  Most of the time, it's been a full DR solution - we're replicating Confluence because it's a production system.  A few times though, it's been "DR for the Confluence docs that are about recovering from a Confluence failure" - these have tended to be low-power systems, again sitting somewhere outside the main data centre but with only one space, which is exported from the main one and copied over regularly or when the original is updated.  Heck, once, as a temporary proof of concept for one client, I fired it all up on a machine in my house, actually doing the whole setup and copy space during the DR meeting (2 hours, I was only there to talk about the Atlassian stack, so I had spare time and got big brownie points near the end of it.  Took me a bit longer to get an automatic refresh scripted and reliable)

Moving to the Cloud is likely to be a bit more of a fuss than "create server somewhere and fire up a copy"

[Kishan Sharma]

I would second @Nic Brough -Adaptavist- thoughts. If you are running a production instance (primary site), a Disaster Recovery (secondary site) is a must so that you can fail over your service to the secondary site in case of any unforeseen events at primary site. You can plan this architecture on public cloud or on-premise based on your requirements.

An alternative way can be, to export all pages from all spaces to pdf via a script at a scheduled time, but it's not a viable option if your confluence site is extra large. It may come in handy for small confluence instances since you will have an offline copy available all the time

[Benjamin W.]

One idea when remaining OnPremise on a server in another data center could be:

- copy complete Confluence installation and data-directory the other server (as THE ONE importance piece of documentation is NOT in THE tech space, but rather in the OTHER.....)

- restore the database into a local hosted one on the other server

- change base URL from confluence... to disasterflence...

- disable any enterprise user directories (like ActiveDirectory, Azure) and use a local confluence user

- deal with licenses of the application (dev license)

You even do not have to take care about updates, as once installed, the binaries will be overwritten from prod Confluence.

In case both data center have major issues, you could simply take this VM and deploy it on any hardware. 

Running on Windows and SQL-Server, can be fully automated with Powershell and SQL-scripts.