#Disaster Recovery

GitLab is a stateful service that stores your repositories and project data, so you must plan disaster recovery (DR) for it separately. Without a dedicated recovery plan, a disaster can lead to the loss of that data.

This guide describes the disaster recovery options for GitLab and how they relate to the disaster recovery of the Alauda Container Platform (ACP) global cluster.

#Disaster Recovery Options

#Dedicated Disaster Recovery

GitLab provides a dedicated disaster recovery solution that lets you recover the GitLab service in a secondary cluster after the primary cluster fails, with minimal data loss.

For the architecture and detailed steps, refer to the Alauda Knowledge Base (KB).

#Backup and Restore

If you do not need the dedicated solution but want a recovery point to fall back to, use backup and restore. You periodically back up a GitLab instance and restore it when needed. This gives an approximate disaster recovery capability, with a longer recovery time than the dedicated solution.

For details, see Backup and Restore Using Velero.

#Relationship with ACP Global Cluster Disaster Recovery

When GitLab is deployed on the ACP global cluster, the disaster recovery of the global cluster and GitLab's disaster recovery are two independent solutions. They do not depend on each other, and global cluster disaster recovery does not protect GitLab:

• Global cluster disaster recovery does not synchronize GitLab resources, including GitLab instances, their workloads and data, and the dependent middleware.
• Global cluster disaster recovery does not recover GitLab after a disaster.

Therefore, even when GitLab runs on the ACP global cluster, you must still plan its disaster recovery separately using one of the options above.