@@ -570,13 +570,15 @@ See the following additional guides:
...
@@ -570,13 +570,15 @@ See the following additional guides:
## Warnings, limitations, and known issues
## Warnings, limitations, and known issues
### Separate buckets required when using Helm
### Use separate buckets
Generally, using the same bucket for your Object Storage is fine to do
Using separate buckets for each data type is the recommended approach for GitLab.
for convenience.
This ensures there are no collisions across the various types of data GitLab stores.
There are plans to [enable the use of a single bucket](https://gitlab.com/gitlab-org/gitlab/-/issues/292958)
in the future.
However, if you're using or planning to use Helm, separate buckets will
Helm-based installs require separate buckets to
be required as there is a [known limitation with restorations of Helm chart backups](https://docs.gitlab.com/charts/advanced/external-object-storage/#lfs-artifacts-uploads-packages-external-diffs-pseudonymizer).
1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
...
@@ -2303,20 +2303,9 @@ on what features you intend to use:
...
@@ -2303,20 +2303,9 @@ on what features you intend to use:
| [Terraform state files](../terraform_state.md#using-object-storage) | Yes |
| [Terraform state files](../terraform_state.md#using-object-storage) | Yes |
Using separate buckets for each data type is the recommended approach for GitLab.
Using separate buckets for each data type is the recommended approach for GitLab.
This ensures there are no collisions across the various types of data GitLab stores.
A limitation of our configuration is that each use of object storage is separately configured.
There are plans to [enable the use of a single bucket](https://gitlab.com/gitlab-org/gitlab/-/issues/292958)
[We have an issue for improving this](https://gitlab.com/gitlab-org/gitlab/-/issues/23345)
in the future.
and easily using one bucket with separate folders is one improvement that this might bring.
There is at least one specific issue with using the same bucket:
when GitLab is deployed with the Helm chart restore from backup
[will not properly function](https://docs.gitlab.com/charts/advanced/external-object-storage/#lfs-artifacts-uploads-packages-external-diffs-pseudonymizer)
unless separate buckets are used.
One risk of using a single bucket would be if your organization decided to
migrate GitLab to the Helm deployment in the future. GitLab would run, but the situation with
backups might not be realized until the organization had a critical requirement for the backups to
1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
...
@@ -2002,20 +2002,9 @@ on what features you intend to use:
...
@@ -2002,20 +2002,9 @@ on what features you intend to use:
| [Terraform state files](../terraform_state.md#using-object-storage) | Yes |
| [Terraform state files](../terraform_state.md#using-object-storage) | Yes |
Using separate buckets for each data type is the recommended approach for GitLab.
Using separate buckets for each data type is the recommended approach for GitLab.
This ensures there are no collisions across the various types of data GitLab stores.
A limitation of our configuration is that each use of object storage is separately configured.
There are plans to [enable the use of a single bucket](https://gitlab.com/gitlab-org/gitlab/-/issues/292958)
[We have an issue for improving this](https://gitlab.com/gitlab-org/gitlab/-/issues/23345)
in the future.
and easily using one bucket with separate folders is one improvement that this might bring.
There is at least one specific issue with using the same bucket:
when GitLab is deployed with the Helm chart restore from backup
[will not properly function](https://docs.gitlab.com/charts/advanced/external-object-storage/#lfs-artifacts-uploads-packages-external-diffs-pseudonymizer)
unless separate buckets are used.
One risk of using a single bucket would be if your organization decided to
migrate GitLab to the Helm deployment in the future. GitLab would run, but the situation with
backups might not be realized until the organization had a critical requirement for the backups to
1. If you're using [Gitaly with TLS support](#gitaly-tls-support), make sure the
1. If you're using [Gitaly with TLS support](#gitaly-tls-support), make sure the
...
@@ -1697,20 +1698,9 @@ on what features you intend to use:
...
@@ -1697,20 +1698,9 @@ on what features you intend to use:
| [Terraform state files](../terraform_state.md#using-object-storage) | Yes |
| [Terraform state files](../terraform_state.md#using-object-storage) | Yes |
Using separate buckets for each data type is the recommended approach for GitLab.
Using separate buckets for each data type is the recommended approach for GitLab.
This ensures there are no collisions across the various types of data GitLab stores.
A limitation of our configuration is that each use of object storage is separately configured.
There are plans to [enable the use of a single bucket](https://gitlab.com/gitlab-org/gitlab/-/issues/292958)
[We have an issue for improving this](https://gitlab.com/gitlab-org/gitlab/-/issues/23345)
in the future.
and easily using one bucket with separate folders is one improvement that this might bring.
There is at least one specific issue with using the same bucket:
when GitLab is deployed with the Helm chart restore from backup
[will not properly function](https://docs.gitlab.com/charts/advanced/external-object-storage/#lfs-artifacts-uploads-packages-external-diffs-pseudonymizer)
unless separate buckets are used.
One risk of using a single bucket would be if your organization decided to
migrate GitLab to the Helm deployment in the future. GitLab would run, but the situation with
backups might not be realized until the organization had a critical requirement for the backups to
1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
...
@@ -2002,20 +2002,9 @@ on what features you intend to use:
...
@@ -2002,20 +2002,9 @@ on what features you intend to use:
| [Terraform state files](../terraform_state.md#using-object-storage) | Yes |
| [Terraform state files](../terraform_state.md#using-object-storage) | Yes |
Using separate buckets for each data type is the recommended approach for GitLab.
Using separate buckets for each data type is the recommended approach for GitLab.
This ensures there are no collisions across the various types of data GitLab stores.
A limitation of our configuration is that each use of object storage is separately configured.
There are plans to [enable the use of a single bucket](https://gitlab.com/gitlab-org/gitlab/-/issues/292958)
[We have an issue for improving this](https://gitlab.com/gitlab-org/gitlab/-/issues/23345)
in the future.
and easily using one bucket with separate folders is one improvement that this might bring.
There is at least one specific issue with using the same bucket:
when GitLab is deployed with the Helm chart restore from backup
[will not properly function](https://docs.gitlab.com/charts/advanced/external-object-storage/#lfs-artifacts-uploads-packages-external-diffs-pseudonymizer)
unless separate buckets are used.
One risk of using a single bucket would be if your organization decided to
migrate GitLab to the Helm deployment in the future. GitLab would run, but the situation with
backups might not be realized until the organization had a critical requirement for the backups to
## Uncomment and edit the following options if you have set up NFS
## Uncomment and edit the following options if you have set up NFS
##
##
...
@@ -1694,20 +1694,9 @@ on what features you intend to use:
...
@@ -1694,20 +1694,9 @@ on what features you intend to use:
| [Terraform state files](../terraform_state.md#using-object-storage) | Yes |
| [Terraform state files](../terraform_state.md#using-object-storage) | Yes |
Using separate buckets for each data type is the recommended approach for GitLab.
Using separate buckets for each data type is the recommended approach for GitLab.
This ensures there are no collisions across the various types of data GitLab stores.
A limitation of our configuration is that each use of object storage is separately configured.
There are plans to [enable the use of a single bucket](https://gitlab.com/gitlab-org/gitlab/-/issues/292958)
[We have an issue for improving this](https://gitlab.com/gitlab-org/gitlab/-/issues/23345)
in the future.
and easily using one bucket with separate folders is one improvement that this might bring.
There is at least one specific issue with using the same bucket:
when GitLab is deployed with the Helm chart restore from backup
[will not properly function](https://docs.gitlab.com/charts/advanced/external-object-storage/#lfs-artifacts-uploads-packages-external-diffs-pseudonymizer)
unless separate buckets are used.
One risk of using a single bucket would be if your organization decided to
migrate GitLab to the Helm deployment in the future. GitLab would run, but the situation with
backups might not be realized until the organization had a critical requirement for the backups to