2020-06-23 00:09:42 +05:30
---
stage: Enablement
group: Geo
2021-02-22 17:27:13 +05:30
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-23 00:09:42 +05:30
type: howto
---
2021-03-11 19:13:27 +05:30
# Geo with Object storage **(PREMIUM SELF)**
2019-07-31 22:56:46 +05:30
2019-12-21 20:55:43 +05:30
Geo can be used in combination with Object Storage (AWS S3, or other compatible object storage).
2019-07-31 22:56:46 +05:30
2021-10-27 15:23:28 +05:30
The storage method for files is recorded in the database, and the database is replicated
from the **primary** Geo site to the **secondary** Geo site, so the **secondary** Geo site
must match the storage method of the **primary** Geo site.
Therefore, if the **primary** Geo site uses object storage, the **secondary** Geo site must use it too.
2021-06-08 01:23:25 +05:30
Currently, **secondary** sites can use either:
2019-07-31 22:56:46 +05:30
2021-06-08 01:23:25 +05:30
- The same storage bucket as the **primary** site.
2019-12-21 20:55:43 +05:30
- A replicated storage bucket.
2019-07-31 22:56:46 +05:30
2019-12-21 20:55:43 +05:30
To have:
- GitLab manage replication, follow [Enabling GitLab replication ](#enabling-gitlab-managed-object-storage-replication ).
- Third-party services manage replication, follow [Third-party replication services ](#third-party-replication-services ).
2020-04-22 19:07:51 +05:30
[Read more about using object storage with GitLab ](../../object_storage.md ).
2021-09-04 01:27:46 +05:30
## Enabling GitLab-managed object storage replication
2019-12-21 20:55:43 +05:30
2020-06-23 00:09:42 +05:30
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/10586) in GitLab 12.4.
2019-12-21 20:55:43 +05:30
2021-02-22 17:27:13 +05:30
WARNING:
2020-11-24 15:15:51 +05:30
This is a [**beta** feature ](https://about.gitlab.com/handbook/product/#beta ) and is not ready yet for production use at any scale. The main limitations are a lack of testing at scale and no verification of any replicated data.
2019-12-21 20:55:43 +05:30
2021-06-08 01:23:25 +05:30
**Secondary** sites can replicate files stored on the **primary** site regardless of
2021-03-11 19:13:27 +05:30
whether they are stored on the local file system or in object storage.
2019-12-21 20:55:43 +05:30
2021-09-04 01:27:46 +05:30
To enable GitLab replication:
2019-12-21 20:55:43 +05:30
2021-09-04 01:27:46 +05:30
1. On the top bar, select **Menu >** ** {admin}** **Admin** .
1. On the left sidebar, select **Geo > Nodes** .
1. Select **Edit** on the **secondary** site.
2021-02-22 17:27:13 +05:30
1. In the **Synchronization Settings** section, find the **Allow this secondary node to replicate content on Object Storage**
checkbox to enable it.
2019-07-31 22:56:46 +05:30
For LFS, follow the documentation to
2020-04-22 19:07:51 +05:30
[set up LFS object storage ](../../lfs/index.md#storing-lfs-objects-in-remote-object-storage ).
2019-07-31 22:56:46 +05:30
For CI job artifacts, there is similar documentation to configure
[jobs artifact object storage ](../../job_artifacts.md#using-object-storage )
2020-11-24 15:15:51 +05:30
For user uploads, there is similar documentation to configure [upload object storage ](../../uploads.md#using-object-storage )
2019-07-31 22:56:46 +05:30
2021-06-08 01:23:25 +05:30
If you want to migrate the **primary** site's files to object storage, you can
2019-12-21 20:55:43 +05:30
configure the **secondary** in a few ways:
- Use the exact same object storage.
- Use a separate object store but leverage your object storage solution's built-in
replication.
- Use a separate object store and enable the **Allow this secondary node to replicate
content on Object Storage** setting.
GitLab does not currently support the case where both:
2021-06-08 01:23:25 +05:30
- The **primary** site uses local storage.
- A **secondary** site uses object storage.
2019-07-31 22:56:46 +05:30
2019-12-21 20:55:43 +05:30
## Third-party replication services
2019-07-31 22:56:46 +05:30
When using Amazon S3, you can use
[CRR ](https://docs.aws.amazon.com/AmazonS3/latest/dev/crr.html ) to
2021-06-08 01:23:25 +05:30
have automatic replication between the bucket used by the **primary** site and
the bucket used by **secondary** sites.
2019-07-31 22:56:46 +05:30
If you are using Google Cloud Storage, consider using
[Multi-Regional Storage ](https://cloud.google.com/storage/docs/storage-classes#multi-regional ).
2019-09-30 21:07:59 +05:30
Or you can use the [Storage Transfer Service ](https://cloud.google.com/storage-transfer/docs/ ),
2019-07-31 22:56:46 +05:30
although this only supports daily synchronization.
2021-01-29 00:20:46 +05:30
For manual synchronization, or scheduled by `cron` , see:
2019-07-31 22:56:46 +05:30
2019-09-30 21:07:59 +05:30
- [`s3cmd sync` ](https://s3tools.org/s3cmd-sync )
2019-07-31 22:56:46 +05:30
- [`gsutil rsync` ](https://cloud.google.com/storage/docs/gsutil/commands/rsync )
