Smart Mirroring can greatly improve Git clone speeds for distributed teams working with large repositories. Large repositories that take hours to clone from a Bitbucket instance over the Internet from the other side of the world can take minutes when cloned from a local mirror on a fast network.
As your team grows and becomes more distributed, so will the need to clear up congestion that can come from an increasing number of continuous integration (CI) builds. Mirror farms can handle this issue by taking mirrors and clustering them into farms to reduce the time spent waiting for those build results.
If you're ready to start mirroring your repositories you can jump straight to the Set up a mirror or Set up a mirror farm page and follow the steps there, or read on to learn more about the benefits of using a mirror. If you have mirrors already configured, you might be searching for instructions on how to Clone a mirror repository.
About Smart Mirroring
Many software development teams using Git have large repositories as a result of storing lots of historical information, using monolithic repositories, or storing large binary files (or all three). Companies with distributed software development teams often have little control over the network performance available to them between sites. In combination, this leads to lost development time when developers have to wait long periods, often hours, to clone a large repository from across the world.
Smart Mirroring gives you back this lost development time by allowing you to set up live mirror nodes that hose copies of repositories in remote locations. These mirrors automatically keep all repositories hosted on them in sync with the primary Bitbucket Data Center instance. Users in those remote locations may clone and fetch repositories from the mirror and get identical content, only faster. Mirrors can be configured to mirror all repositories in all projects from their primary Bitbucket instance, or a selection of projects configured by an administrator.
How it works
Mirrors run the same Bitbucket application as a full Bitbucket Server instance, but configured to mirror an upstream Bitbucket Data Center instance where the primary copy of all your repositories is hosted.
Mirrors have no user interface and do not provide repository browsing, pull requests, or other such functionality, which is all provided by the primary Bitbucket server. The web interface of Bitbucket remain on the primary server.
When a user clones or fetches from a mirror, the mirror automatically delegates the authentication and authorization of their credentials back to the primary server. So no additional user management is required on mirrors, and all the users, groups, and permissions of the primary Bitbucket instance (whether provided by the built-in user directory and permission system or by your own user directories and/or custom extensions) are always replicated exactly on all mirrors.
Self-healing is one of the main design principles for smart mirroring. Mirrors have the ability to detect and recover from a number of error scenarios, while All operations retry with exponential backoff. Smart mirroring also includes an anti-entropy system (the farm vet) which verifies the consistency of a mirror against the primary every 3 minutes.
Ready to get started setting up a mirror?
Don't have Bitbucket Data Center yet? Purchase a Bitbucket Data Center license, or get an evaluation license to try Bitbucket Data Center.