Engineering Owner: TBD ### Summary (for the Release Post; describes potential future state) ### Problem to solve <!-- What problem are we solving for them? Tight problem description that everyone can rally around. --> Setting up a disaster recovery solution for GitLab requires significant investment and is cumbersome in more complex setups, such as high availability configurations. Geo doesn't replicate all parts of GitLab yet, which means that users need to be aware of what they can recover in case of disaster. In the future, our users should be able to use a GitLab Disaster Recovery solution that fits within their business continuity plan. Users should be able to choose which Recovery Time Objective (RTO) and Recovery Point Objective (RPO) are acceptable to them and GitLab's DR solutions should provide configurations that fit those requirements. A systems administrator should be able to confidently setup a DR solution even when the setup is complex, as is the case for high availability. In case of an actual disaster, a systems administrator should be able to follow a simple and clear set of instructions that allows them to recover a working GitLab installation. In order to ensure that DR works, frequent failovers should be tested. ### Proposal ### Higher intent ### Intended users <!-- Who's the target user? Target user description. --> * [Systems administrators](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sidney-systems-administrator) * [Software developers](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sasha-software-developer) ### Further details ### What does success look like, and how can we measure that? - Success is when all replicated data sources are verified automatically after replication, corrective action is taken automatically if possible and information is surfaced in the UI ### What is the type of buyer? * Premium ### Links / references