2020-06-03 17:08:23 -04:00
---
2022-05-29 20:08:35 -04:00
stage: Systems
2020-06-03 17:08:23 -04:00
group: Geo
2020-11-26 01:09:20 -05:00
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
2020-06-03 17:08:23 -04:00
type: howto
---
2021-11-17 10:10:28 -05:00
# Bring a demoted primary site back online **(PREMIUM SELF)**
2019-05-05 12:08:21 -04:00
2021-11-17 10:10:28 -05:00
After a failover, it is possible to fail back to the demoted **primary** site to
2019-05-05 12:08:21 -04:00
restore your original configuration. This process consists of two steps:
2021-11-17 10:10:28 -05:00
1. Making the old **primary** site a **secondary** site.
1. Promoting a **secondary** site to a **primary** site.
2019-05-05 12:08:21 -04:00
2020-12-04 16:09:29 -05:00
WARNING:
2021-11-17 10:10:28 -05:00
If you have any doubts about the consistency of the data on this site, we recommend setting it up from scratch.
2019-05-05 12:08:21 -04:00
2021-11-17 10:10:28 -05:00
## Configure the former **primary** site to be a **secondary** site
2019-05-05 12:08:21 -04:00
2021-11-17 10:10:28 -05:00
Since the former **primary** site will be out of sync with the current **primary** site, the first step is to bring the former **primary** site up to date. Note, deletion of data stored on disk like
repositories and uploads will not be replayed when bringing the former **primary** site back
2019-05-05 12:08:21 -04:00
into sync, which may result in increased disk usage.
2020-09-15 11:10:08 -04:00
Alternatively, you can [set up a new **secondary** GitLab instance ](../setup/index.md ) to avoid this.
2019-05-05 12:08:21 -04:00
2021-11-17 10:10:28 -05:00
To bring the former **primary** site up to date:
2019-05-05 12:08:21 -04:00
2021-11-17 10:10:28 -05:00
1. SSH into the former **primary** site that has fallen behind.
2019-05-05 12:08:21 -04:00
1. Make sure all the services are up:
2020-01-30 10:09:15 -05:00
```shell
2019-07-02 21:37:27 -04:00
sudo gitlab-ctl start
```
2020-12-04 16:09:29 -05:00
NOTE:
2021-11-17 10:10:28 -05:00
If you [disabled the **primary** site permanently ](index.md#step-2-permanently-disable-the-primary-site ),
2019-07-02 21:37:27 -04:00
you need to undo those steps now. For Debian/Ubuntu you just need to run
`sudo systemctl enable gitlab-runsvdir` . For CentOS 6, you need to install
2021-11-17 10:10:28 -05:00
the GitLab instance from scratch and set it up as a **secondary** site by
2020-09-15 11:10:08 -04:00
following [Setup instructions ](../setup/index.md ). In this case, you don't need to follow the next step.
2019-07-12 04:15:38 -04:00
2020-12-04 16:09:29 -05:00
NOTE:
2020-07-16 02:09:33 -04:00
If you [changed the DNS records ](index.md#step-4-optional-updating-the-primary-domain-dns-record )
2021-11-17 10:10:28 -05:00
for this site during disaster recovery procedure you may need to [block
2022-05-03 17:08:54 -04:00
all the writes to this site](planned_failover.md#prevent-updates-to-the-primary-site)
2019-07-02 21:37:27 -04:00
during this procedure.
2019-05-05 12:08:21 -04:00
2021-11-17 10:10:28 -05:00
1. [Set up database replication ](../setup/database.md ). In this case, the **secondary** site
refers to the former **primary** site.
1. If [PgBouncer ](../../postgresql/pgbouncer.md ) was enabled on the **current secondary** site
(when it was a primary site) disable it by editing `/etc/gitlab/gitlab.rb`
2020-10-30 17:08:52 -04:00
and running `sudo gitlab-ctl reconfigure` .
2021-11-17 10:10:28 -05:00
1. You can then set up database replication on the **secondary** site.
2019-05-05 12:08:21 -04:00
2021-11-17 10:10:28 -05:00
If you have lost your original **primary** site, follow the
[setup instructions ](../setup/index.md ) to set up a new **secondary** site.
2019-05-05 12:08:21 -04:00
2021-11-17 10:10:28 -05:00
## Promote the **secondary** site to **primary** site
2019-05-05 12:08:21 -04:00
2021-11-17 10:10:28 -05:00
When the initial replication is complete and the **primary** site and **secondary** site are
2020-04-01 02:07:50 -04:00
closely in sync, you can do a [planned failover ](planned_failover.md ).
2019-05-05 12:08:21 -04:00
2021-11-17 10:10:28 -05:00
## Restore the **secondary** site
2019-05-05 12:08:21 -04:00
2021-11-17 10:10:28 -05:00
If your objective is to have two sites again, you need to bring your **secondary**
site back online as well by repeating the first step
([configure the former **primary** site to be a **secondary** site](#configure-the-former-primary-site-to-be-a-secondary-site))
for the **secondary** site.