doc/administration/geo/replication/selective_synchronization.md
{{< details >}}
{{< /details >}}
Geo supports selective synchronization, which allows administrators to choose which projects should be synchronized by secondary sites. A subset of projects can be chosen, either by group or by storage shard. The former is ideal for reducing transfer and storage costs by replicating data belonging to only a subset of users. The latter is more suited to progressively rolling out Geo to a large GitLab instance.
[!note] Geo's synchronization logic is outlined in the documentation. Both the solution and the documentation is subject to change from time to time. You must independently determine your legal obligations in regard to privacy and cybersecurity laws, and applicable trade control law on an ongoing basis.
Selective synchronization:
By default, selective synchronization is disabled. To enable it:
[!warning] Promoting a secondary site with selective synchronization enabled to become the primary site results in permanent data loss for all data that was not replicated to that secondary site.
When selective synchronization is configured on a secondary site, only a subset of data is replicated:
All other data remains only on the original primary site. If you promote a secondary site with selective synchronization to become the new primary:
[!note] There is no validation or warning in the promotion process to prevent this scenario.
Before promoting a secondary site with selective synchronization:
If you must promote a secondary with selective sync enabled (for example, in an emergency):
Git clone, pull, and push operations over HTTP(S) and SSH are supported for repositories that exist on the primary site but not on secondary sites. This situation can occur when: