Taking your first steps into the world of backup doesn't have to be a challenge. We have prepared the following list of questions to make it easier for you to decide what kind of backup would suit your company best:

1. Do you want to use the on-premise version (deployed in your infrastructure) or the SaaS (cloud) version?

2. What is your goal? What results do you want to achieve?

3. How do you imagine a perfect backup solution? What are your desired essentials for a backup software?

4. What kind of data do you want to protect? What resources do you have to secure?

5. Have you already thought about the backup schedule? Is there a specific RTO/RPO you want to achieve?

6. Are there any policies, requirements or conditions you have to meet?

7. Do the resources you want to protect have any technological limitations or access restrictions?

8. What type of storage do you want to use (i.e., on-site, cloud)?

9. Who will manage your backup service? Would you need several accounts with different levels of permissions?

10. Do you need to integrate your backup service with an external identity provider (IdP) via SAML protocol?

Having these answered, you can head to and check all available backup options to find the one which best suits your needs, or schedule a demo with our sales team to learn more about the GitProtect backup system and how it works.

Licensing in GitProtect defines how product usage rights are assigned and managed within an organization, covering subscription scope, activated instances, and available feature sets depending on the selected plan.

Licenses are required to use GitProtect for backup and recovery. They define how data protection is enabled across different environments and workloads and are assigned based on the type and number of protected resources. Depending on the deployment scenario, licenses cover SaaS platforms, Microsoft 365 organizations, and repositories, ensuring that each protected element is properly accounted for within the licensing model.

GitProtect pricing is available on the .

Below you can find all license types available in GitProtect, categorized by protected resource type.

The cloud worker is a GitProtect worker installed in the cloud. It connects to cloud-based environments like or cloud storage services to perform backup tasks.

You don't have to assign any licenses to cloud workers — the correct license is assigned automatically by GitProtect system.

Cloud worker's installation location depends on the GitProtect Management Service installation directory.

API limits for Azure DevOps and Azure DevOps Server outline the restrictions on requests that can affect how Xopero ONE interacts with your data.

Azure DevOps

Rate limits enhance security by preventing an overwhelming number of requests that could disrupt, block, or destabilize the application's functionality—the system enforces these limits for stability. For more information, visit the official Microsoft Learn website.

Azure DevOps Server

In Azure DevOps Server (on-premises), API limits are flexible and depend on server resources and configuration. Unlike the cloud version, there are no fixed, global request limits—administrators set performance parameters and limits tailored to the organization's specific needs.

Rate limits are enforced for security and stability— excessive requests may block access or disrupt the application’s operation. For detailed information, refer to the official Bitbucket documentation.

Bitbucket Data Center protected resources define which parts of your environment GitProtect can access, secure, and restore.

Backup coverage

The following list includes all Bitbucket Data Center resources covered by backup.

• Branches

• Commits

• LFS

• Pull requests

• Repository

• Tags

• Webhooks

GitProtect Management Service is available in two deployment models: as a SaaS offering or as an on-premises component. For SaaS customers, the Management Service is hosted in the EMEA region and the US region.

Service deployment

In SaaS model, the GitProtect Management Service platform is deployed in two different locations:

Useful links and items

For IdP integration, GitProtect uses differentiated login levels (i.e., Admin, Backup Operator, Viewer, etc.). By default, single users are being authenticated with predefined permissions, based on the roles they are assigned. If you require multiple users to log in with consistent security policies, permissions, or access rights, you can implement group mapping.

The configuration process includes specifying two key parameters: claim type and claim value — for example, in Entra ID, the following parameters refer to:

1. Claim type — name of the custom claim defined for the application on the Entra ID side to identify the group. In this example, claim type value is set to xoperogroup.

2. Claim value — a unique Entra ID group identifier (ID) to be mapped (not its name).

GitProtect supports multiple repository selection methods that allow administrators to define the scope of backup and recovery operations according to organizational requirements. Repositories can be selected manually, automatically, or included and excluded based on configurable rules and filters.

Selecting data to protect

When creating a backup plan, one of the steps is to specify which repositories you want to protect. GitProtect offers several methods for selecting repositories:

1. Protect all: this option ensures that all existing repositories and projects, as well as any newly created ones, are automatically included in the backup plan without requiring manual updates.

2. Select projects: using checkboxes, you can choose specific projects to protect.

3. Select repositories: using checkboxes, you can choose specific repositories to protect.

1. Exclude repositories: using checkboxes, you can exclude specific repositories, allowing the plan to cover all other repositories by default.

2. Set rules: this option lets you define criteria to include repositories and projects based on attributes such as their names or associated topics, ensuring that repositories meeting these conditions are automatically protected.

GitProtect system architecture is presented in the following diagram:

GitProtect product as a platform consists of three main components: management service, worker, and storage.

The main component required to run GitProtect backup system is called GitProtect Management Service. It allows you to comprehensively manage your backups and related resources using Management Service console with a user-friendly and easy to navigate UI. In on-premise deployment model it can be installed on almost any computer with Windows and Linux operating systems or Docker environment (even popular NAS devices). When it comes to SaaS deployment model, the management service runs on provider's cloud infrastructure.

GitProtect Management Service is divided into separate modules, each of them dedicated to a different aspect of backup management:

GitProtect is a flexible backup solution that can be deployed in two different models: SaaS and on-premise.

The main difference between SaaS and on-premise models is where GitProtect service is installed and running. The first implementation type — SaaS (software as a service, a cloud-based model) — is hosted and maintained by us while the other, on-prem model, is hosted in-house (directly on your local infrastructure). Which implementation type works best for your company depends on a variety of factors including your objectives, system limitations, company's budget, security requirements, company policy, and more. Before you decide which solution deployment model to use, you need to evaluate your options and compare it with your infrastructure to figure out which implementation type would be the best fit.

Software as a service (SaaS) is a way of delivering software over the internet. Instead of installing and maintaining software on your computer, you access it online through a subscription with a cloud service provider.

To deploy GitProtect SaaS you don't have to allocate any additional devices that could be used as a local server - the service runs in our cloud infrastructure. You don't have to worry about its maintenance or administration, and the continuity of operation is guaranteed by us.

To access the on-premise GitProtect Management Service, connect to the device which Management Service console is installed on, using the following address:

ipAddress — the IP address of the device with Management Service installed on

port — port defined during installation process — by default, GitProtect uses 28555

If your Management Service opened successfully, you can proceed with the below steps (creating your root account, adding the license code, logging in, running your first setup).

In GitProtect, creating a backup plan allows you to define what data should be protected, where backups are stored, and how often they are performed.

A Microsoft 365 backup plan in GitProtect defines which data is protected, how frequently backups are performed, and how long recovery points are retained. A dedicated Microsoft 365 backup plan enables protection of mailboxes, OneDrive resources, and SharePoint sites while applying automated schedules and granular retention policies that align with organizational data protection and compliance requirements.

To optimize backup tasks, GitProtect Management Service provides several advanced features that enable flexible configuration based on specific infrastructure requirements. When creating a backup plan, you can customize settings such as backup windows, task balancing, storage locations, bandwidth limits, and more.

GitProtect provides granular control over Microsoft 365 backups. Instead of backing up an entire environment, you can selectively target specific data types—such as messages, calendars, or contacts—to optimize storage capacity and focus exclusively on critical assets.

GitProtect supports backup and recovery of Git Large File Storage (LFS) content for DevOps organizations, ensuring that repositories configured with Git LFS are protected together with their associated large binary objects. During restore operations, both standard Git data and LFS objects are recovered to preserve repository integrity and maintain consistency across supported DevOps platforms.

GitProtect supports the backup and recovery of LFS objects across all supported DevOps platforms.

While you can choose whether to include LFS metadata during the recovery process, please note that LFS must be restored alongside its parent repository; it cannot be recovered as a standalone item.

GitProtect is designed to protect DevOps ecosystems, including Azure DevOps.

To ensure your entire Azure DevOps environment is reliably backed up, make sure to include all repositories along with their related metadata — the best practice is to create a backup plan for critical repositories and metadata that change daily (or even more frequently), for example, using the recommended Grandfather-Father-Son (GFS) rotation scheme.

Additionally, create a separate backup plan for unused repositories that you need to keep for future reference. This type of backup primarily serves Azure DevOps archival purposes, and with unlimited retention, you can store your copies for as long as needed — even indefinitely.

You can also delete repositories from your Azure DevOps account while keeping a copy in storage, which helps bypass Azure DevOps limits.

Incremental and differential backups

To protect a Bitbucket Data Center (DC) environment with GitProtect, the account used to authorize the connection must have sufficient permissions to access the workspaces, repositories, and related resources designated for backup.

GitProtect supports Bitbucket Data Center (DC) version 3.0.4 and higher, enabling comprehensive repository and metadata protection regardless of the underlying host operating system.

In Bitbucket Data Center, account permissions can be managed in three distinct ways, all of which are fully supported for use with GitProtect:

1. Global permissions — the user account connecting Bitbucket DC

Registration for a GitProtect account in the SaaS deployment model is a simple, self-service process on the GitProtect website. To sign up, customers provide basic business contact details, select data residency, and create administrator credentials. After registration, access to the GitProtect Management Service is granted via a unique SaaS login URL for subsequent provisioning, adding storage or cloud agents, and configuring roles and permissions.

Creating an account

The below steps outline the registration process on the GitProtect website.

Kestrel configuration

"commented_out_Kestrel": {
"Endpoints": {
"Http": {
"Url": "http://*:5000"
}
}

Microsoft 365 protected resources define which parts of the environment GitProtect can access, backup, and restore.

Backup coverage

The following list includes all Microsoft 365 resources covered by backup.

GitProtect provides selection rules, allowing administrators to determine which repositories and projects are included or excluded from backup and recovery tasks. Rules can be based on names, owners, creation dates, branches, or specific patterns, offering granular control over the backup scope and ensuring that only relevant repositories and projects are processed.

Selection rules and rule patterns

Below are the selection rules and rule patterns you can use in GitProtect to select repositories and projects for inclusion in backup jobs within your DevOps organization.

Azure DevOps & Bitbucket

1. Repository name — you can use the full or partial name of a repository. Wildcard characters can be used at the end of the rule to match repository names:

   1. * matches zero or more characters

   2. ? matches exactly one character

2. Project name: protects all repositories within the specified project.

1. Repository name — you can use the full or partial name of a repository. Wildcard characters can be used at the end of the rule to match repository names:

   1. * matches zero or more characters

   2. ? matches exactly one character

1. Repository name — you can use the full or partial name of a repository. Wildcard characters can be used at the end of the rule to match repository names:

   1. * matches zero or more characters

   2. ? matches exactly one character

The following are examples of rule patterns, along with brief explanations:

• Pattern: yourorganization/*

  • This will match all repositories in the organization named yourorganization.

• Pattern: yourorganization/n??

All selection rules can use regular expression patterns (regex).

Regular expressions let you create flexible and adaptable rules that align with your organization's naming conventions. This approach allows precise targeting and automation based on consistent patterns in repository or project names.

The following are illustrative examples of how these rules can be applied, although the available configurations extend well beyond these cases:

• Pattern: yourorganization/repo[0-9]+

  • This will match repositories such as repo1, repo12, repo123, and so on.

The GitProtect.io for Jira application was built on the Atlassian Forge developer platform. The application acts as a connector between Jira and GitProtect — during registration, each GitProtect.io for Jira app is linked to a single GitProtect service instance, which is created at the moment the app is installed on your Jira site.

Most backup operations are managed through the GitProtect Management Service, while the Jira interface allows basic actions like viewing the latest backup status, adjusting the backup schedule, and starting the backup process.

GitProtect supports two-factor authentication (aka 2FA, multi-factor authentication, MFA) based on an authenticator application. To use 2FA with your GitProtect account, you have to first enable MFA in your GitProtect Management Service admin panel, and then set it up.

Adding a Microsoft 365 tenant to GitProtect connects your organization's environment and enables data protection for supported services. The integration requires proper authorization and tenant-level permissions to establish a secure connection between Microsoft 365 and GitProtect, allowing you to configure backup settings, manage protection policies, and perform recovery operations.

The following documentation applies only to Microsoft 365 organizations with GitProtect licenses that include backup for Microsoft Exchange data (including individual mailboxes, calendars, and contacts) and OneDrive.

For instructions on enabling protection for SharePoint sites in new and existing Microsoft 365 organizations, refer to the article.

The below steps demonstrate how to integrate a Microsoft 365 organization with GitProtect using GitProtect Management Service.

Enabling SharePoint protection in GitProtect allows SharePoint sites to be included in the Microsoft 365 backup scope. The setup follows the same tenant-based flow used for other Microsoft 365 resources and requires that the necessary prerequisites and permissions are in place before backup configuration is started.

The following documentation applies only to Microsoft 365 organizations with GitProtect licenses (Microsoft 365 PRO) that include backup for Microsoft Exchange data (including individual mailboxes, shared mailboxes, calendars, and contacts), SharePoint, and OneDrive.

For instructions on adding Microsoft 365 tenants with only Microsoft Exchange and OneDrive protection to GitProtect, see .

The below steps demonstrate how to integrate a Microsoft 365

Microsoft Exchange and OneDrive data can be restored with granular control over the recovery scope and destination. Emails, calendars, contacts, files, and folders can be restored directly to a Microsoft 365 user account or locally to a device, supporting recovery after accidental deletion, migration, and other data-loss scenarios.

The below steps demonstrate how to restore Microsoft Exchange data and OneDrive folders and files using GitProtect Management Service.

GitProtect allows you to recover SharePoint data from available backup points and restore it to the original location or another selected destination. The recovery process helps restore entire sites after accidental deletion, unwanted changes, or other data-loss scenarios while preserving their structure, documents, lists, and associated data.

The below steps demonstrate how to restore SharePoint sites and their metadata using GitProtect Management Service.

Recovering an organization wiki restores lost or overwritten documentation, enabling projects to quickly regain access to their knowledge base without affecting other repository or project metadata.

The following steps demonstrate how to quickly recover your wiki using GitProtect Management Service.

GitProtect allows organizations to restore individual Azure DevOps repositories along with their associated metadata. The process ensures repository integrity and consistency while minimizing impact on other projects, supporting efficient disaster recovery, migration, and point-in-time restore operations.

The following steps demonstrate how to quickly restore a single Azure DevOps repository using GitProtect Management Service.

Recovering multiple Azure DevOps repositories simultaneously enables organizations to quickly restore only the selected repositories, ensuring consistent and reliable recovery across the development environment.

The following steps demonstrate how to restore multiple Azure DevOps repositories at once using GitProtect Management Service.

To protect a Bitbucket environment with GitProtect, the account or token used to authorize the connection must have sufficient permissions to access the workspaces, repositories, and related resources designated for backup. The specific permission scopes vary depending on the chosen authorization method.

When integrating Bitbucket using the OAuth authentication method, GitProtect requires the following permissions to securely access and protect your repository data:

• Account

  • Read and modify account information.