# Mirroring nextcloud

**URL:** <https://help.nextcloud.com/t/mirroring-nextcloud/52211>\
**Category:** ℹ️ Support\
**Created:** [April 25, 2019, 4:47pm UTC](https://help.nextcloud.com/t/mirroring-nextcloud/52211 "2019-04-25T16:47:37Z")\
**Posts on this page:** 1\
**Showing post:** 3

<div class="post-metadata">

**Author:** ![anon75456558](https://help.nextcloud.com/letter_avatar/anon75456558/32/6_22734026db12803ebb3e059622ac3534.png) [@anon75456558](https://help.nextcloud.com/u/anon75456558)\
**Post date:** [April 25, 2019, 7:19pm UTC](https://help.nextcloud.com/t/mirroring-nextcloud/52211/3 "2019-04-25T19:19:07Z")

</div>

Worth noting also that [OpenCloudMesh (OCM)](https://wiki.geant.org/display/OCM/Open+Cloud+Mesh) was [announced by devs of the Nextcloud project in 2016](https://nextcloud.com/de/blog/nextcloud-joins-open-cloud-mesh/) and [is documented here](https://lukasreschke.github.io/OpenCloudMeshSpecification/#introduction). It does not specifically address mirroring data as discussed in the previous post, but it does relate to finding common federation protocols for all the various, enterprise file sharing projects like Nextcloud, Seafile, Filerun, etc.

[Project github is located here, but has not been updated since mid-2017](https://github.com/GEANT/OCM-API). However, [Major federation improvements were added to the server in late 2018 via this Pull Request](https://github.com/nextcloud/server/pull/9345).

> [@Nextcloud pushes forward Open Cloud Mesh API with proposal for 1.0 release](https://help.nextcloud.com/t/nextcloud-pushes-forward-open-cloud-mesh-api-with-proposal-for-1-0-release/33172):
>
> Originally published at: [https://nextcloud.com/blog/nextcloud-pushes-forward-open-cloud-mesh-api-with-proposal-for-1.0-release/](https://nextcloud.com/blog/nextcloud-pushes-forward-open-cloud-mesh-api-with-proposal-for-1.0-release/) [image] Nextcloud founders Frank Karlitschek and Bjoern Schießle [invented the Federated Cloud Sharing API](https://www.schiessle.org/articles/2016/07/04/history-and-future-of-cloud-federation/) when still at ownCloud, and pushed the solution as a collaboratively developed standard under the Open Cloud Mesh initiative of the GÉANT Association, a European collaboration on e-infrastructure and services for research and education. Nextcloud formally joine…

Back in [Nextcloud 12 it was announced that Global Scale architecture would be deployed](https://help.nextcloud.com/t/nextcloud-joins-open-cloud-mesh-initiative-of-geant-to-continue-driving-federated-cloud-sharing-development/1368) to help scale up for large user case scenarios, but should be deployable on a minimum of two machines. This is designed for enterprise use, but it would address the kinds of questions you have for balancing between multiple servers. Not all of it has been implemented or documented so it is still more of a conceptual white paper.

[The Global Site Selector app](https://github.com/nextcloud/GlobalSiteSelector) is available in the app store for setting a Master/Slave relationship between multiple servers.  
[Lookup Server](https://github.com/nextcloud/lookup-server) is being developed as well, but [I think it needs additional documentation](https://github.com/nextcloud/lookup-server/issues).  
**Balancer** part of Global Scale does not yet exist, or is not yet being developed as part of Nextcloud’s overall Github.

Taken from [this old forum post](https://help.nextcloud.com/t/nextcloud-announces-global-scale-architecture-as-part-of-nextcloud-12/12873), these three things accomplish the following:

> ### Global Site Selector
> 
> The Global Site Selector (GSS) acts as a central instance that is accessed by the user during the first login, accessing it via the Web, WebDAV or REST. The GSS authenticates the user via the central user management like for example LDAP. It then looks up the node where the user is located in the lookup server and redirects the user to the right hostname. The following calls during the same session are done directly from client to the node.
> 
> ### Lookup Server
> 
> The lookup server stores the physical location of a user. It can be queried using a valid user id to fetch the federated sharing id of a user. In some situations, it is important to limit queries to a certain IP space to avoid data leaks. It also keeps track of old federated sharing IDs. The lookup server stores additional data of the users like for example the required QoS metrics like storage/quota settings, speed class, reliability class and so on.
> 
> ### Balancer
> 
> The Balancer runs on a dedicated machine, monitoring the various nodes and their storage, CPU, RAM and network utilization. It can mark nodes as online or offline and initiate the migration of user accounts to different nodes based on data in the Lookup Server like business or legal requirements, QoS settings or user location. If for example, a user would move from the US to Europe, the Balancer would initiate a migration from their data to an EU data center to improve the quality of service.
> 
> You can learn more details on [our webpage about Global Scale.](https://nextcloud.com/globalscale)

---

_[View the full topic](https://help.nextcloud.com/t/mirroring-nextcloud/52211)._
