Where GitProtect Management Service is hosted across different regions.
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:
EMEA
For the EMEA region, GitProtect Management Service platform is hosted in Poland.
US
For the US region, GitProtect Management Service platform is hosted in the United States.
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.
Unfortunately, unlike other DevOps, Microsoft does not provide information about the exact number of queries that can be sent in a given time period.
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.
Post-installation actions
This article contains information about how to proceed after installing the GitProtect Management Service component.
Accessing the Management Service in on-prem deployment model
To access the on-premise GitProtect Management Service, connect to the device which Management Service console is installed on, using the following address:
ipAddress:port
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).
GitProtect first configuration
1
When you launch the Management Service for the first time, you will be prompted to create an administrator account. To register a valid admin account you have to provide your login (it has to be a valid email address) and create a password compliant with the GitProtect password policy. Once you complete the form click Register to proceed to the next step.
2
Having the administrator account registered, you will then be asked to provide a license key (which you should've received via email upon registering for GitProtect) — this is the last step before the GitProtect system becomes operational and ready to use. Once done, click Proceed to go to the system setup.
3
In the initial setup you should add your first device which you want to use to set up the storage. Then, you have to install the backup worker and activate it in GitProtect system.
4
Next, add the storage where you want to store your data. As GitProtect is a multi-storage system, you can add different storages from different sources and use both local storage (i.e., SMB, NFS) and cloud solutions (i.e., Wasabi, Amazon, etc.).
5
With all system components initialized, you can start protecting your data and create backup plans.
GitProtect Management Service
DevOps
GitProtect worker
Microsoft 365
Information about backup and recovery for Microsoft 365 tenants.
Deployment models
Review key differences between the on-premises and SaaS deployment models to determine the optimal configuration for your environment.
GitProtect provides flexible on-premises and cloud deployment models to accommodate diverse IT infrastructure, security policies, and data sovereignty requirements.
GitProtect is a flexible backup solution that can be deployed in two different models: SaaS and on-premises.
The primary difference between the SaaS and on-premises deployment models lies in where the GitProtect services are installed and run. In SaaS model, Xopero hosts and maintains all services in the cloud. In on-premises model, services are deployed and managed within the user's own infrastructure.
The backup storage location is independent of the deployment model of the GitProtect services. A SaaS deployment can use local storage repositories, while an on-premises deployment can use cloud-based storage repositories.
Software as a Service (SaaS) is a software delivery model in which applications are hosted and maintained by a service provider and accessed over the internet. Instead of installing and managing software on local infrastructure, users access the service through a subscription.
API limits
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 .
Marketplace
Authorize GitProtect from a cloud marketplace to set up a backup service and enable automated data protection.
Protected resources
Overview of protected Bitbucket Data Center resources, including repositories, wikis, and metadata secured by backup.
Bitbucket Data Center protected resources define which parts of your environment GitProtect can access, secure, and restore.
The following list includes all Bitbucket Data Center resources covered by backup.
System requirements
Hardware, operating system architecture, and software requirements for deploying the GitProtect Management Service and the backup agent.
Installing the GitProtect Management Service and the backup agent application requires meeting specific hardware, operating system, and storage prerequisites to guarantee reliable orchestration across your backup environment. Dedicated multi-core processor allocation, sufficient RAM, and high-speed storage are essential for sustaining internal backup operations, efficient database processing, and multi-agent communication.
The table below lists the minimum and recommended system requirements for deploying the Xopero ONE Backup&Recovery application.
Resource
Minimum
Recommended
Azure DevOps & DevOps Server
Recovery
Overview of Bitbucket data recovery in GitProtect, including restoration of repositories, wikis, and related metadata.
External Identity Providers (IdP)
Integration
Learn about integrating a Microsoft 365 tenant with GitProtect to protect its resources.
Installation on Windows & Linux
This article describes the process of GitProtect Management Service installation on Windows, Linux, and as a Docker container for on-premise deployment model.
Download and run GitProtect installer.
Click Next to start the installation setup.
Backup
Cloud worker
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.
Integration
Backup
Login with username and password
Simple guide on how to log in to GitProtect with a username and password.
1
Connect to your GitProtect Management Service.
Use <ipAddress>:<port> for the on-prem model or your unique login URL for SaaS model.
2
Enter your login and password in the appropriate fields and hit
Supported platforms
Supported operating systems and web browsers for deploying the GitProtect Management Service and the backup agent.
GitProtect delivers a flexible cross-platform architecture, enabling the deployment of the central management service and backup agent across diverse on-premises, cloud, and hybrid environments.
The Xopero ONE Backup&Recovery application supports the following operating systems:
Backup
Login with SSO
Learn how to log in to GitProtect with SSO.
1
Connect to your GitProtect Management Service.
Use <ipAddress>:<port> for the on-prem model or your unique login URL for SaaS model.
2
Backup
LFS
Backup coverage
The list is presented in alphabetical order.
Cloud worker is available only for the GitProtect SaaS deployment model.
As a form of cloud computing, SaaS allows the provider to manage all underlying infrastructure, platform components, and application resources, while customers use the software without having to maintain the physical or software environment required to run it.
In the SaaS deployment model, the management service runs entirely on Xopero's cloud infrastructure. This model eliminates the need to provision or manage dedicated local servers. Xopero handles all backend administration, software updates, and maintenance, ensuring continuous operational availability.
No local server or hardware provisioning required.
Secure, web-based management service accessible from anywhere.
High availability and guaranteed business continuity.
Native cloud-to-cloud backup.
Automated software updates, security patching, and maintenance.
On-premises software is installed and operated on infrastructure owned and managed by the organization or individual using the software. Unlike cloud-based solutions, on-premises software runs on local systems within the organization's environment rather than in a remote data center or cloud infrastructure. As a result, the organization is responsible for maintaining, managing, and securing the software and the underlying infrastructure.
In the on-premises deployment model, GitProtect services can be installed on supported operating systems, deployed in a Docker container, or hosted directly on compatible NAS devices. This deployment model eliminates reliance on external network connectivity — backup data is transferred across the local network, significantly increasing transfer speeds and operational efficiency.
Flexible deployment on supported OS, Docker, and NAS devices.
Fast, reliable local backups unaffected by external network outages.
Complete data sovereignty with zero external data transmission.
Full support for offline and air-gapped backup operations.
General information
Regardless of the deployment model, the platform provides identical features and functionality through a unified user interface.
SaaS model
Key advantages of SaaS deployment:
On-premises model
Key advantages of on-premises deployment:
Fedora: 29+
The GitProtect Management Service supports the following web browsers:
The Xopero ONE Backup&Recovery Agent application supports the following operating systems:
Accept the End-User License Agreement and hit Next to continue.
Select the installation folder and click Next.
Define the HTTP port for GitProtect Management Service. Depending on your needs you can either use a custom HTTP port, or stay with the default Management Service HTTP port (28555).
Click Install to start the installation process.
Once the installation is completed successfully, click Finish to close the installation wizard.
Installation process for Linux
Download and run GitProtect installer (xoperoserver.sh).
Add execute permission to the downloaded file using the following command:
chmod +x xoperoserver.sh
Run xoperoserver.sh. Accept the End-User License Agreement to continue.
Once the installation is completed, you can close the software installation window.
To register for a free trial and download the installer visit the GitProtect website. If you're already a registered user, download the installer here.
Installation process for Windows
Login
.
Select one of the available SSO options.
SSO options example for GitProtect SaaS.
3
Go through the selected supplier's login process.
4
Once signed in, you will be automatically redirected to your Management Service main page.
To log in to Xopero ONE using SSO, you can choose one of the following providers: Bitbucket, GitHub, GitLab, Google, or Microsoft. If you want to use your private identity provider for quick login, configure your IdP using the SAML protocol. See more in section.
Adding a Bitbucket DC instance to GitProtect
This article explains how to add a Bitbucket DC organization to GitProtect.
Using username and password
1
Log in to GitProtect Management Service, open the DevOps tab on the left side of the window, and select Bitbucket from the list.
2
Click the Connect button under Bitbucket Data Center.
3
Set your authentication method.
In Authentication, select Bitbucket DC.
Enter the Bitbucket DC server IP address and your username.
Add or select password from the Password Manager (same as your Bitbucket DC credentials).
4
Configure your repository sync and default worker. Specify hours for synchronization, or set a time interval for automatic updates.
5
Click Proceed to complete adding your Bitbucket DC organization and grant GitProtect access to the specified resources.
Active Directory integration
Learn how to integrate Active Directory with GitProtect using LDAP.
Integrating Active Directory (AD) with GitProtect enables automated user provisioning upon login, group-to-role mapping, and administrative fallback authentication.
General information
Integrating Active Directory (AD) with GitProtect (supporting both LDAP and LDAPS protocols) enables centralized and automated permission management within the backup system.
The automatic provisioning feature eliminates the need to create user accounts manually. Instead, each user's GitProtect profile is created automatically during their first login. User information and assigned roles are continuously synchronized and updated based on the Active Directory group structure. Administrators can further control the GitProtect environment by limiting authentication to selected AD groups and configuring the system's default language.
Additionally, administrators retain independent emergency access to the system. After each successful authentication, the system stores user's LDAP attributes and group memberships retrieved from Active Directory in its local database, while the user's password is securely managed by the password module. If the Active Directory server becomes unavailable, the system retrieves the required user and group information from the local database. If the provided password matches the securely stored record in the password module, the user is authenticated and granted access as if they had logged in through Active Directory.
The following steps outline how to configure Active Directory (AD) settings in GitProtect Management Service.
1
Navigate to ⚙️ Settings > External Identity Providers, then click Add new provider and select Active Directory.
2
Specify the required parameters.
The following steps outline how to configure group mapping settings in GitProtect Management Service.
1
Navigate to ⚙️ Settings > External Identity Providers, then click Add new provider > Active Directory or edit an existing one. In the Active Directory configuration aside, scroll down and click Group mapping.
2
In the next aside, click + Add new group mapping (or edit an existing one) and specify the required parameters.
Adding Azure DevOps Server to GitProtect
This article explains how to add an Azure DevOps Server organization to GitProtect.
Adding an Azure DevOps Server to GitProtect connects your projects and repositories to the platform, enabling seamless backup management and secure data protection.
Using a Personal Access Token (PAT)
Azure DevOps Server (self-managed, on-premise) does not support OAuth and requires a personal access token.
1
Log in to GitProtect Management Service, open the DevOps tab on the left side of the window, and select Azure DevOps from the list.
2
Click the Connect button under Azure DevOps Server.
3
Set your authentication method.
In Authentication, select Azure DevOps Server.
Enter the service address of your Azure DevOps Server (IP or DNS name, including the protocol).
Add or select PAT from the Password Manager.
4
Configure your repository sync and default worker. Specify hours for synchronization, or set a time interval for automatic updates.
5
Click Proceed to complete adding your Azure DevOps Server organization and grant GitProtect access to the specified resources.
6
Your Azure DevOps Server organization has now been successfully added to GitProtect. Click Custom policy to adjust your backup policy settings, or click Run backup to execute the backup immediately using the current policy configuration.
Required permissions
Permissions required to integrate Bitbucket Data Center with GitProtect to protect its resources.
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.
Supported platform versions
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.
Account permissions
For Bitbucket DC integrations, an HTTP access token can be used in place of a password. Since these tokens inherit your user account's existing privileges, ensure you restrict the token's permissions to the access levels required for GitProtect operations before connecting.
In Bitbucket Data Center, account permissions can be managed in three distinct ways, all of which are fully supported for use with GitProtect:
Global permissions — the user account connecting Bitbucket DC with GitProtect must have at least administrator privileges. Using global permissions grants the application access to protect all repositories across the entire Bitbucket DC instance.
Project permissions — alternatively, you can assign write permissions at the project level to the connecting user account. This method restricts GitProtect synchronization and backup scope strictly to the repositories within those specific projects.
Repository permissions — permissions can also be configured individually for each specific repository, offering granular control via two operational tiers:
Read (sufficient to perform data backups, but cannot be used to execute repository restorations).
Write (full authorization to perform both backup and restoration operations).
Integration
Repository selection methods
Learn about repository and project selection methods in GitProtect, including manual selection and rule-based configuration.
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:
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.
Select projects: using checkboxes, you can choose specific projects to protect.
Select repositories: using checkboxes, you can choose specific repositories to protect.
Exclude repositories: using checkboxes, you can exclude specific repositories, allowing the plan to cover all other repositories by default.
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.
Recovery
Overview of Bitbucket Data Center data recovery in GitProtect, including restoration of repositories and related metadata.
Repository selection rules
Configure selection rules to automatically include or exclude specific Git repositories and projects from backup jobs.
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, topics, or custom properties, offering granular control over the backup scope and ensuring that only relevant repositories and projects are processed.
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.
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:
Process overview
Learn more about the backup process for Azure DevOps.
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
8 GB
disk space
1 GB
2 GB
Repositories and projects created after applying method 2 or method 3 will not be automatically included in the backup plan and must be added manually.
Learn more about selection rules and rule patterns in this article.
Please note that, by default, the GitProtect Management Service installed on Linux uses port 28555.
Project name: protects all repositories within the specified project.
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:
* matches zero or more characters
? matches exactly one character
Topic name — specify the exact name of a topic. For example, if you enter the topic html, all repositories assigned to the html topic will be backed up.
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:
* matches zero or more characters
? matches exactly one character
Topic name — specify the exact name of a topic. For example, if you enter the topic html, all repositories assigned to the html topic will be backed up.
Group path: protects all repositories within the specified group or subgroup path.
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??
Matches repositories where n is followed by exactly two characters.
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.
Pattern:yourorganization/.*data.*
Matches any repository name containing the word data.
Pattern:yourorganization/(?!.*data.*)
Excludes any repository name that contains the word data.
Selection rules and rule patterns
Azure DevOps & Bitbucket
GitHub
GitLab
Selection rule examples
Regular expression patterns (regex)
help save storage space. In
GitProtect
you can define different retention and performance settings for each type of backup (
full
,
incremental
, and
differential
). For example, our software
allows you to include only the blocks of
Azure DevOps
data that have changed since the last backup, reducing storage usage, speeding up the process, and limiting bandwidth.
Use different types of storage to replicate backups, minimize the risk of outages or disasters, and comply with the 3-2-1 backup rule (which means having at least three copies of your data on two different storage types, with at least one copy stored in the cloud).
GitProtect is a multi-storage system that allows you to store your data:
General information
Backup type
Adding multiple storage instances
Choose whether GitProtect should automatically add new repositories to your backup.
For Bitbucket DC, you can also use an HTTP access token instead of a password.
Useful links and items
Name: custom IdP name.
Server address:Active Directory server address, either IP or FQDN.
Server port: 389 (LDAP) or 636 (LDAPS).
Start point: the starting point in the Active Directory tree (e.g., ou=local-dev,DC=ad,DC=local,DC=dev,DC=organization,DC=com).
Account name: service account name, either UPN (username@domain) or DL (domain\username).
LDAP server certificate: if required by your network infrastructure, upload the server's security certificate (PEM, DER, or CRT format) to verify the server's identity.
Directory synchronization frequency: define how often the user database is refreshed and synchronized with Active Directory.
Add or select password from Password Manager: service account password.
3
Select the preferred language, default role assigned to users, and default user permissions.
4
To define roles for specific user groups, click Group mapping. You can configure group mapping at any time, either during the initial integration or later.
If no group mapping is configured, all users within the specified Active Directory domain inherit the default role and permissions for their GitProtect accounts.
5
Before proceeding, you can test the connection by clicking the question mark at the bottom of the configuration panel.
6
Review your settings and click Save. After successfully integrating Active Directory with GitProtect, a GitProtect account is created for each user upon their first login, with permissions based on the default roles or group mapping.
Users can log in to the GitProtect Management Service using either their UPN (username@domain) or DL (domain\username).
Claim type: context for the claim value, in this case http://schemas.microsoft.com/ws/2008/06/identity/claims/role
Claim value: name of the Active Directory (AD) group (for example, Domain Admins).
Role: permission level that will be assigned to all users belonging to the specified AD group.
Permissions: supplementary privileges to grant to the specified AD group beyond their base role (optional).
3
Review your configuration details and click Save. Once done, all users within the specified Active Directory group will automatically inherit the selected roles and permissions.
Access mapping applies dynamically, both during initial user provisioning and as an immediate update to existing GitProtect accounts.
Adding Active Directory service to GitProtect
Group mapping
Useful links and items
The connection will succeed if the certificate specified in the settings—or located in the certificates directory (matching the server name)—is valid and matches the server's certificate. Otherwise, the system falls back to default verification, meaning self-signed certificates will be automatically rejected and the connection will fail.
Choose whether GitProtect should automatically add new repositories to your backup.
Cloud workers cannot access local network storage. Choose a device with the necessary access if backing up locally.
Useful links and items
Restoring Microsoft Exchange and OneDrive data
Restore emails, calendars, contacts, and selected OneDrive folders and files from a backup.
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.
Recovery process
The below steps demonstrate how to restore Microsoft Exchange data and OneDrive folders and files using GitProtect Management Service.
1
Open the Microsoft 365 tab, then click the Explore button next to the organization whose backup you want to restore.
2
In the Microsoft 365 Users tab, search for the user whose data you want to restore, and then click the restore button in the action menu for that user.
3
Next, select the backup plan from which you want to restore data. Click View available plans, and then select a plan from the list.
4
Choose the backup version from all the backups that have already been performed — select the desired date and click the Restore button.
5
Select the restore destination and click Next.
6
In the next pane, browse the tabs, select the data you want to restore, and click Restore selected. Alternatively, click Restore all to restore all available data.
7
Next, depending on the selected restore destination, configure the Restore to and Restore directory settings.
In the Restore directory section, choose one of the following options:
New directory — creates a new directory to restore the data to.
8
In Restore settings, you can limit bandwidth usage and select the default backup agent (worker) that will be used to restore the data (where applicable).
9
After defining all parameters, click the Restore button to start the recovery process. You can monitor the process in the Tasks tab.
Adding Bitbucket organization to GitProtect
This article provides instructions for adding a Bitbucket organization to GitProtect.
Using OAuth
1
Log in to GitProtect Management Service, open the DevOps tab on the left side of the window, and select Bitbucket from the list.
2
Click the Connect button under Bitbucket.
3
A pop-up with Bitbucket login page will appear. Log in using your admin credentials and grant GitProtect access to the specified resources (when prompted).
4
Your Bitbucket organization has now been successfully added to GitProtect. Click Custom policy to adjust your backup policy settings, or click Run backup to execute the backup immediately using the current policy configuration.
1
Log in to GitProtect Management Service, open the DevOps tab on the left side of the window, and select Bitbucket from the list.
2
Click the advanced mode link under Bitbucket and Bitbucket DC tiles.
3
1
Log in to GitProtect Management Service, open the DevOps tab on the left side of the window, and select Bitbucket from the list.
2
Click the advanced mode link under Bitbucket and Bitbucket DC tiles.
3
When adding an organization, you may be prompted to grant additional permissions to the GitProtect application—make sure your browser allows GitProtect to open pop-up windows.
Depending on your browser, you can either adjust the settings to allow pop-ups or permit the authorization window to open once.
Adding GitHub organization to GitProtect
This article explains how to add a GitHub organization to GitProtect.
Using OAuth
1
Log in to GitProtect Management Service, open the DevOps tab on the left side of the window, and select GitHub from the list.
2
Click the Connect button under GitHub.
3
, log in with a user account which has the required permissions for the repositories or projects to protect. If your GitHub login session is active in a different tab, the login will complete automatically.
4
Grant GitProtect access to the specified resources (when prompted).
5
Your GitHub organization has now been successfully added to GitProtect. Click Custom policy to adjust your backup policy settings, or click Run backup to execute the backup immediately using the current policy configuration.
1
Log in to GitProtect Management Service, open the DevOps tab on the left side of the window, and select GitHub from the list.
2
Click the advanced mode link under GitHub and GitHub Enterprise Server tiles.
3
1
Log in to GitProtect Management Service, open the DevOps tab on the left side of the window, and select GitHub from the list.
2
Click the advanced mode link under GitHub and GitHub Enterprise Server tiles.
3
When adding an organization, you may be prompted to grant additional permissions to the GitProtect application—make sure your browser allows GitProtect to open pop-up windows.
Depending on your browser, you can either adjust the settings to allow pop-ups or permit the authorization window to open once.
Installation with an SSL certificate
Learn how to connect to GitProtect Management Service admin panel via encrypted HTTPS protocol.
Kestrel configuration
Remember that once you modify the Management Service settings you must switch the agent's communication protocol to HTTPS for the GitProtect service to work correctly.
You can find more information about Kestrel configuration .
1
Open appsettings.json file located in GitProtect Management Service installation directory.
Modify the following code lines — erase commented_out_ prefix and add the HTTPS configuration as follows:
Path: path to the .pfx file*
Password: certificate password
*IMPORTANT! Remember to use double slash— if you're keeping the certificate in C:\cert.pfx directory, the path should be entered as C:\\cert.pfx instead.
1
Go to your GitProtect worker installation directory and open config.json file.
Default location of the config.json file is:
For Windows:C:\Program Files\Xopero ONE Backup&Recovery Agent
Worker configuration
Activation (license assignment)
1
Login to your GitProtect Management Service console.
2
Click the Activate agent icon in the top menu.
3
A sidebar will appear, showing a list of available agents — you can view basic details like device type, name, IP address, and operating system.
4
Select the device you want to activate (you can select multiple devices if you assign them the same license type) and press the Activate button to proceed.
5
Next, select the license type you want to assign to the chosen device(s) and click Assign license to confirm your selection.
6
Once the license is correctly assigned, your device(s) will be visible in the Devices tab.
The config.json file, by default, is located in the following locations:
For Windows: C:\Program Files\Xopero ONE Backup&Recovery Agent
For Linux: /opt/XoperoONEBackupAgent/
💡You can edit config.json with a simple text editor (i.e., Notepad++).
The GitProtectManagement Service address to which your worker connects is crucial during both installation and configuration. If the IP address or protocol (http/https) of the Management Service changes, the agent's status will switch to offline. To re-establish the connection, update the ServiceUrl value in the configuration file with the updated address.
By default, the LogLevel value is set to Information. You can change it to:
Trace
Debug
Information
By default, application logs are stored in the following directory: C:\ProgramData\Xopero ONE\Xopero ONE Backup&Recovery Agent\Logs. To change the location, modify the AppDataFolder parameter.
The device name defaults to the system's name. To customize it, modify the OverriddenHostName parameter.
If database backup task ends with error DV0249 - "Unable to read backup data", first address any connection stability issues on your end. If the problem persists, you can increase the retry attempts in the GitProtect application—to do this, simply edit the MaxRetriesCount parameter, changing its default value from 2 to a higher value, i.e., 20.
GitProtect.io for GitHub
Register for a free GitProtect trial through GitHub Marketplace.
Registering and deploying GitProtect via GitHub Marketplace enables organizations to seamlessly authenticate and provision enterprise-grade backup protection directly within their existing GitHub environment.
Registration
Complete the procedure below to register a GitProtect account and set up the GitProtect service.
Type gitprotect in the search box and press Enter.
3
Find the GitProtect GitHub Backup & Recovery tile in the search results and click it.
4
On the application page, click the Set up a free trial button in the top-right corner.
5
Select a plan that best suits your needs and click the Install it for free (or Try free for 14 days) button.
6
If prompted, enter and confirm your billing details to proceed, and then click the Complete order and begin installation button.
7
Grant GitProtect access to the specified resources.
8
Wait for the system to create your account and provision the GitProtect service.
9
When prompted, grant GitProtect additional access to your account data.
10
Once the account is created, you will be redirected to the GitProtect Management Service landing page, where you can immediately add repositories to protect and create backup plans for them.
11
The system will generate a unique GitProtect Management Service instance URL for login. For subsequent logins, use this URL or go directly to .
12
Additionally, you will receive a welcome email from GitProtect containing all important information about your account and the GitProtect system (including your unique login URL).
Adding Microsoft 365 tenant to GitProtect
How to integrate a Microsoft 365 organization with GitProtect.
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.
Important notice
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 Enabling SharePoint protection in GitProtect article.
Integration process
The below steps demonstrate how to integrate a Microsoft 365 organization with GitProtect using GitProtect Management Service.
1
Select Microsoft 365 from the left pane.
2
Click Connect under Microsoft 365.
3
Copy the authentication code, then click Log in to Microsoft 365.
4
In the Microsoft authentication tab, paste the copied code and click Next.
5
Select your account and sign in if prompted. Next, click Continue to confirm your sign-in to Xopero Registrator.
6
If the registration is completed successfully, the following message will appear. Close the tab and return to GitProtect Management Service.
7
The Microsoft 365 organization has been successfully added to GitProtect. Click Custom policy to modify your backup policy settings, or click Run backup to start a backup using the current policy configuration.
After adding the organization, you may see the following message. Click Repair to configure permissions for shared mailbox protection.
To start the permission update process, click Continue at the bottom of the configuration pane. If prompted, sign in to your Microsoft 365 account and grant GitProtect the required permissions.
After the required permissions have been granted, you can configure a Microsoft 365 backup plan and start protecting your resources.
Password reset
Find how to reset the root password in GitProtect for on-premise & SaaS deployment models.
If you have access to your GitProtect Management Service
1
Login to Management Service, open Settings (gear ⚙️ icon in the bottom-left corner) and select Accounts.
2
Find your root account and click the edit (✏️) icon.
3
Enter your old password and your new password in the correct fields, then click Change.
4
Hit the Save button to finish. Your password should now be successfully changed.
1
Open your Management Service login page and click Forgot password? link under credentials fields.
2
Enter the email address associated with your root account and hit Send me a recovery link button.
3
Local worker
Enabling SharePoint protection in GitProtect
How to integrate a Microsoft 365 organization with GitProtect and include SharePoint protection.
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
GitHub App
Learn more about GitHub Apps and their features.
GitHub can be integrated with GitProtect using several authorization methods, including a GitHub App, which provides a secure and scalable way to connect GitHub organizations for backup and recovery operations. With granular permissions, repository-level access, and short-lived authentication tokens, GitHub Apps help protect repositories and related metadata while supporting automated backup workflows, repository synchronization, and streamlined management across the GitProtect environment.
A GitHub App is a type of integration you can build to interact with and extend GitHub's functionality. GitHub Apps can provide flexibility and reduce friction in your processes without requiring users to sign in or create a service account.
Like OAuth apps, GitHub Apps use OAuth 2.0 and can act on a user's behalf. Unlike OAuth apps, GitHub Apps can also act independently of a user.
The key advantages of using the GitHub App for integration with GitProtect include enhanced security, better rate limit handling, and more reliable repository management.
Adding Azure DevOps organization to GitProtect
This article explains how to add an Azure DevOps organization to GitProtect.
1
Log in to GitProtect Management Service, open the DevOps tab on the left side of the window, and select Azure DevOps from the list.
2
Click the Connect button under Azure DevOps.
Installation on Linux & MacOS
Prior to worker installation, check if your system is meets all the requirements.
Download the worker installer (bash script) to your Linux system and grant execute permission to the file owner (user or group) using the following chmod command:
Recovery
Overview of Azure DevOps and DevOps Server backup recovery in GitProtect, including restoration of repositories, wikis, and related metadata.
Creating a backup plan
This article provides instructions on how to set up a Bitbucket backup plan.
1
Login to GitProtect Management Service, open the Plans > Backup tab and click the Add plan button in the top bar.
2
Select Bitbucket from the list.
3
LFS recovery for DevOps organizations
Learn how GitProtect restores Git LFS objects alongside repositories to ensure complete data recovery for DevOps organizations.
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.
GitHub
Login methods
GitProtect SaaS
How to sign up for a free GitProtect account in a cloud-based management service deployment.
Warning
Error
Critical
None
In the GitProtect system, the local worker, cloud worker, and feature worker licenses are free. These licenses allow specific operations, except for backing up the device itself — thus, devices with these licenses appear under Settings > Advanced > Workers tab.
Configuration
To modify the config.json file, you must stop the GitProtect worker service. After making your changes, restart the service (you might also need to refresh the changes in the Management Service panel).
Management Service address
Log level
Default log path
Please note that the correct AppDataFolder value format includes double slash after the drive letter (i.e., D:\\).
Device name
Please note that the custom name must be in entered with quotation marks (i.e., "TESTNAME").
Number of retries
GitProtect uses a simple widget to guide users through the entire onboarding process, including configuring the environment, starting and monitoring their first backup, and performing a test restoration.
Your unique Management Service URL will be included in the welcome email.
Original directory — restores the data to its original location. You can also choose to overwrite existing OneDrive files and email messages.
In the Restore to pane, select the user to whom you want to restore the data, and click Save.
In the Restore directory section, choose one of the following options:
New directory — creates a new directory to restore the data to.
Original directory — restores the data to its original location. You can also choose to overwrite existing OneDrive files and email messages.
In the Restore to pane, select the device to use as the restore destination, and click Save.
In the Restore directory section, select the directory where the data will be restored, and then click Apply.
Restore to the original account
The option to create a copy of overwritten OneDrive files is currently unavailable.
Restore to a new account
The option to create a copy of overwritten OneDrive files is currently unavailable.
Restore to a device
Set your authentication method.
In Authentication, select Bitbucket.
For Connect using, choose OAuth App.
In the Settings section, choose whether to enable read-only mode and whether GitProtect should automatically add new repositories to your backup.
If the Read-Only Access switch is enabled, the recovery options will be disabled.
4
Configure your repository sync and default worker. Specify hours for synchronization, or set a time interval for automatic updates.
5
Click Proceed to complete adding your Bitbucket organization and grant GitProtect access to the specified resources (when prompted).
Set your authentication method.
In Authentication, select Bitbucket.
For Connect using, choose Username and App password.
Enter your Bitbucket email address.
Add or select App Password that contains your API token from the Password Manager.
Choose whether GitProtect should automatically add new repositories to your backup.
4
Configure your repository sync and default worker. Specify hours for synchronization, or set a time interval for automatic updates.
5
Click Proceed to complete adding your Bitbucket organization and grant GitProtect access to the specified resources.
Using OAuth (Advanced Mode)
Using an API token
Additional browser permissions
Useful links and items
Set your authentication method.
In Authentication, select GitHub.
For Connect using, choose GitHub App.
Choose whether GitProtect should automatically add new repositories to your backup.
4
Configure your repository sync and default worker. Specify hours for synchronization, or set a time interval for automatic updates.
5
Click Proceed to complete adding your GitHub organization and grant GitProtect access to the specified resources. In the window that pops-up, log in with a user account which has the required permissions for the repositories or projects to protect. If your GitHub login session is active in a different tab, the login will complete automatically.
6
Select repositories you want to protect and click Install & Authorize to proceed.
7
Your GitHub organization has now been successfully added to GitProtect. Click Custom policy to adjust your backup policy settings, or click Run backup to execute the backup immediately using the current policy configuration.
Set your authentication method.
In Authentication, select GitHub.
For Connect using, choose Login and Personal Access Token.
Enter your username.
Add or select PAT from the Password Manager.
Choose whether GitProtect should automatically add new repositories to your backup.
4
Configure your repository sync and default worker. Specify hours for synchronization, or set a time interval for automatic updates.
5
Click Proceed to complete adding your GitHub organization and grant GitProtect access to the specified resources.
Modifying the IP address or the protocol (http, https) of the Management Service will change the active worker's status to offline. It will reconnect once you switch the worker's protocol to HTTPS.
Keep in mind that when you're creating a new root account password you have to meet the password complexity requirements.
By default, the system remembers three most recently used passwords, which cannot be used again when creating a new password — the number of previously used passwords that must remain unique can be adjusted in the Unique new passwords section under ⚙️Settings > Advanced.
If you don't have access to your GitProtect Management Service
Keep in mind when you're creating a new root account password you have to meet the password complexity requirements.
By default, the system remembers three most recently used passwords, which cannot be used again when creating a new password — the number of previously used passwords that must remain unique can be adjusted in the Unique new passwords section under ⚙️Settings > Advanced.
The following steps apply to the on-prem model without a configured SMTP server. When the SMTP server is configured, the on-prem version processes the password reset via email, similarly to the SaaS model.
organization with
GitProtect
using
GitProtect Management Service
.
1
Select Microsoft 365 from the left pane.
2
Click Connect under Microsoft 365 Pro.
If you already have a Microsoft 365 organization added, click the + Add new button in the top-left corner first.
3
In the Add new organization pane, click Advanced configuration at the bottom of the pane.
4
In Advanced configuration, enable the Enable SharePoint protection switch, and specify whether GitProtect should automatically assign licenses to users.
5
Next, click the Add new or select certificate from (…) tile. In the Add certificate pane, select the certificate option that aligns with your deployment model: automatically generate a certificate, upload a custom certificate, or select an existing certificate from the list. Once done, click Save.
6
Set the synchronization interval (if needed), review your settings, and click Save to proceed.
7
Back in the Add new organization pane, copy the authentication code, and then click Log in to Microsoft 365.
8
In the Microsoft authentication tab, paste the copied code and click Next.
9
Select your account and sign in if prompted. Next, click Continue to confirm your sign-in to Xopero Registrator.
10
If the registration is completed successfully, the following message will appear. Close the tab and return to GitProtect Management Service.
11
The Microsoft 365 organization has been successfully added to GitProtect. Click Custom policy to modify your backup policy settings, or click Run backup to start a backup using the current policy configuration.
The following steps demonstrate how to enable SharePoint protection for existing Microsoft 365 organizations using GitProtect Management Service.
1
Select Microsoft 365 from the left pane.
2
Click Edit in the lower-left corner of the organization tile.
3
In Settings section, turn on the Enable SharePoint protection switch, and then click the Add new or select certificate from (…) tile.
4
In the Add certificate pane, select the certificate option that aligns with your deployment model: automatically generate a certificate, upload a custom certificate, or select an existing certificate from the list. Once done, click Save.
5
The system will automatically prompt you to create or run a default backup plan. You can skip this step and configure the SharePoint backup plan later.
6
Back in the Microsoft 365 organization dashboard, click Repair to configure permissions for SharePoint protection.
7
To start the permission update process, click Continue at the bottom of the Edit organization pane. If prompted, sign in to your Microsoft 365 account and grant GitProtect the required permissions.
8
After the required permissions have been granted, you can configure a SharePoint backup plan and start protecting your resources.
Important notice
Adding new Microsoft 365 organization with SharePoint protection
GitHub Apps provide enhanced control and security compared to OAuth apps. Instead of broad scopes, GitHub Apps use fine-grained permissions, giving administrators better control over what the app can access and perform:
Granular permissions — GitHub Apps request only the permissions they need, unlike OAuth apps, which rely on broader permission scopes.
Repository-specific access — users or organization owners can choose which repositories an app can access, whereas OAuth apps can access all repositories available to the authorizing user.
Short-lived tokens — GitHub Apps use tokens that expire quickly, reducing the risk of misuse. In contrast, OAuth app tokens remain valid until explicitly revoked.
These features make GitHub Apps more suitable for organizations with strict security requirements, offering stronger protection against potential security risks.
GitHub Apps that use installation access tokens are initially allowed 5,000 requests per hour. This limit can increase under specific conditions:
GitHub Enterprise Cloud organizations — installations associated with a GitHub Enterprise Cloud organization have a rate limit of 15,000 requests per hour.
Scaling by repositories and users — for installations that are not part of a GitHub Enterprise Cloud organization:
Organizations with more than 20 repositories receive an additional 50 requests per hour per repository.
Organizations with more than 20 users receive an additional 50 requests per hour for each user beyond 20.
The total rate limit is capped at 12,500 requests per hour.
The above rules are designed to ensure fair usage while maintaining system stability and security.
GitHub Apps can be installed by users on their personal accounts and by organization owners within organizations they own. Additionally, repository admins within an organization can install GitHub Apps, provided the app is limited to repositories they administer and does not request permissions that affect the organization or involve repository administration.
However, organization owners have the capability to restrict these installations by outside collaborators who are repository admins. If organization members who are neither owners nor admins choose an organization during the app installation process, instead of directly installing the app, GitHub will notify the organization owner to request installation approval.
After installing a GitHub App, you may also need to authorize it. Installation lets you specify which repositories the app can access and grants it permission to use certain organizational resources.
During installation, the app displays the requested permissions for review and approval. Once authorized, the app can also operate on your behalf.
Throttling limits the number of API calls or operations within a given time window to prevent resource overuse and ensure server stability. If throttling limits are exceeded, further client requests may be temporarily restricted, which can extend backup times.
GitProtect can use up to 10 additional apps to increase request limit and reduce throttling impact.
With the upcoming release of GitProtect (scheduled for May 2026), we are introducing support for GitHub issue types.
To enable this new feature, GitHub requires a manual update to your GitHub App permissions. While your existing backup plans will continue to run without interruption, this manual approval is required to unlock the new capabilities and ensure future compatibility.
Below is a step-by-step walkthrough of the approval process.
1
You will get an email from GitHub containing information about the application and the organization or account requesting elevated access. To grant GitProtect the required permissions, click the Review permission request to accept or reject this change link.
2
After clicking the link, you will be redirected to GitHub, where you can review the requested permissions and approve them.
3
Once the requested permissions are accepted, your environment will be ready for full backup coverage of issue type data when the next GitProtect release goes live.
General information
Advantages
Security
Rate limit
Learn more about rate limits in .
Access control and approval flow
App authorization
You can install a GitHub App without authorizing it, and you can also authorize an app without installing it.
Throttling prevention
You can find more information about throttling and throttling mitigation methods in section.
Updating GitHub App permissions
You will receive an email notification from GitHub for each of your installations and will need to manually review and approve the new issue types permission request within your GitHub account.
In the window that pops-up, log in with a user account which has the required permissions for the repositories or projects to protect. If your Azure login session is active in a different tab, the login will complete automatically.
4
Check the Consent on behalf of your organization checkbox and click Accept to proceed.
5
Your Azure DevOps organization has now been successfully added to GitProtect. Click Custom policy to adjust your backup policy settings, or click Run backup to execute the backup immediately using the current policy configuration.
1
Log in to GitProtect Management Service, open the DevOps tab on the left side of the window, and select Azure DevOps from the list.
2
Click the advanced mode link under Azure DevOps and Azure DevOps Server tiles.
3
Set your authentication method.
In Authentication, select Azure DevOps.
For Connect using, choose Username and Personal Access Token.
Add or select PAT from the Password Manager.
4
Configure your repository sync and default worker. Specify hours for synchronization, or set a time interval for automatic updates.
5
Click Proceed to complete adding your Azure DevOps organization and grant GitProtect access to the specified resources.
6
Your Azure DevOps organization has now been successfully added to GitProtect. Click Custom policy to adjust your backup policy settings, or click Run backup to execute the backup immediately using the current policy configuration.
When adding an organization, you may be prompted to grant additional permissions to the GitProtect application — make sure your browser allows GitProtect to open pop-up windows.
Depending on your browser, you can either adjust the settings to allow pop-ups or permit the authorization window to open once.
Adding an Azure DevOps organization to GitProtect connects your environment to the platform, enabling secure backup of projects, repositories, and related data.
Using OAuth
Using a Personal Access Token (PAT)
Additional browser permissions
Next, run the script using the following command:
Running the script along with sudo command
Accept the END-USER LICENSE AGREEMENT to proceed.
Next, enter the IP address in the Address field (including the protocol and port) and click OK to finish the installation. Your address can be found in GitProtect Management Service — the system will display it once you start downloading the worker installer.
Now that GitProtectworker is installed, you can activate it in the GitProtect Management Service web panel and start protecting your data.
Installation
Download GitProtectworker installation wizard and run it.
To download the worker installer, login to GitProtect Management Service using a web browser, then go to Settings > Advanced > Workers and click Download agent button. The Download agent window will open — click the appropriate worker version to download it.
Click Continue to proceed.
Select Continue in the Read Me section.
Read the END-USER LICENSE AGREEMENT and hit Continue to accept it.
Hit Agree to accept the terms of the software license agreement.
Change the installation directory if needed and click Install to begin the installation.
During the installation process, the creator will ask you for the address of your Management Service — define it in this step. Your address can be found in GitProtect Management Service; the system will display it once you start downloading the worker installer.
Click OK to confirm your configuration.
The GitProtect worker has been successfully installed — you can close the installation wizard.
Prerequisites
Installation
To download the worker installer, login to GitProtect Management Service using a web browser, then go to Settings > Advanced > Workers and click Download agent button. The Download agent window will open — click the appropriate worker version to download it.
The above script should be initiated using an account with administrative privileges— because of that it might be required to use the sudo command simultaneously (as in the above example).
Select (or add) the Bitbucket environment you want to include in the backup process, and choose the repositories to back up.
Optionally, GitProtect allows you to protect the entire Bitbucket environment.
4
Specify a name for the backup plan.
5
Select the appropriate metadata that you want to back up. Here, you can also change the default worker, which is the device directly responsible for the backup process of your repositories.
You can have multiple workers and assign different workers to each backup plan.
It is worth noting that the cloud worker (a cloud-installed GitProtect worker) allows you to perform cloud-to-cloud backups if you want to store your backups in the cloud.
6
Select one of the locations assigned to your GitProtect instance as storage.
7
Customize the scheduler and specify how long your data should be retained. If needed, adjust the advanced settings to suit your needs.
8
If necessary, adjust the advanced settings such as encryption, error handling, or bandwidth limits to fit your requirements.
9
Double-check your data and click Save to create the backup plan.
If LFSobjects are included in your repository’s source code archives, downloading those archives will count toward the repository’s bandwidth usage.
Useful links and items
Example of LFS metadata included in Azure DevOps project recovery process.
Required permissions
Required permissions for integrating GitHub with GitProtect and protecting its resources.
Connecting GitHub with GitProtect requires appropriate permissions to access and protect repositories and their associated metadata. The required permissions depend on the authorization method used, such as a GitHub App or personal access token (PAT), and on the type of data that needs to be protected.
Account permissions
Integrating GitHub with GitProtect to back up and restore repositories, projects, and associated metadata requires an account with full administrative privileges.
Exact roles and permission levels may vary depending on individual repository settings, project configurations, or organization-level security policies. Below are examples of different roles, along with the corresponding permissions and the capabilities they provide in GitProtect.
GITHUB ROLES AND PERMISSIONS
Organization role
Repository role
Capabilities
Permissions for the OAuth app
To ensure seamless integration and correct operation, the GitProtect OAuth application requires the following permissions:
GitProtect GitHub App installation requires the following permissions:
Personal access tokens are generated in GitHub account settings under Settings > Developer settings > Personal access tokens and can be assigned different permissions.
Registering the GitProtect application and executing full repository backup and restore tasks requires a token configured with at least repo and workflow permissions.
The following list outlines the permissions required to back up repository metadata within an organization:
Creating a backup plan
This article contains information on how to set up Azure DevOps & DevOps Server backup plan.
Creating an Azure DevOps (or DevOps Server) backup plan ensures your projects and data are securely protected and easily restorable.
Backup plan setup
1
Login to GitProtect Management Service, open the Plans > Backup tab and click the Add plan button in the top bar.
2
Select Azure DevOps from the list.
3
Select (or add) the Azure DevOps or DevOps Server environment you want to include in the backup process, and choose the repositories to back up.
Protect all — protects an entire Azure DevOps organization.
Select projects — allows you to protect selected Azure DevOps projects (including its metadata).
Select repositories — protects only
4
Specify a name for the backup plan.
5
Select the appropriate metadata that you want to back up. Here, you can also change the default worker, which is the device directly responsible for the backup process of your repositories.
6
Select one of the locations assigned to your GitProtect instance as storage.
7
Customize the scheduler and specify how long your data should be retained. If needed, adjust the advanced settings to suit your needs.
8
If necessary, adjust the advanced settings such as encryption, error handling, or bandwidth limits to fit your requirements.
9
Double-check your data and click Save to create the backup plan.
System components & architecture
Examine the core architecture and primary components of GitProtect software.
The GitProtect architecture relies on a modular, multi-tier framework comprising the central management service, backup agents, and scalable storage targets.
General information
A backup solution is a software system or service that creates and stores copies of data so it can be restored if the original data is lost, corrupted, deleted, encrypted by ransomware, or otherwise becomes unavailable.
Xopero specializes in enterprise backup, disaster recovery, and cyber-resilience solutions. One of our flagship products, GitProtect, provides comprehensive data protection across a wide range of DevOps and Microsoft 365 environments. This solution enables organizations to protect business-critical data from accidental deletion, hardware failures, ransomware, cyberattacks, and other data-loss events.
GitProtect can operate in two different deployment models: SaaS (cloud) and on-premises.
Software architecture
GitProtect is designed to protect data across cloud services (Microsoft 365), SaaS applications (such as Jira and Confluence), and different DevOps platforms. It consists of two primary components: the management panel and the backup agent. The solution also requires a storage repository to store backup data. This storage can be managed by the user or provided by Xopero (i.e., Xopero Cloud Storage).
The management system is used for administration and configuration, while the backup agents handle the actual execution of all backup-related operations. When a backup task is initiated, the management service dispatches the job to the backup agent, which performs the requested operation. Once the task is completed, the agent transmits the execution results and logs back to the management system, where administrators can review them in the web console.
The centralized management interface of GitProtect is the GitProtect Management Service. It enables administrators to comprehensively manage backups and related resources through the web console. In the on-premises deployment model, GitProtect Management Service can be installed on supported Windows and Linux operating systems, deployed in a Docker environment, or hosted directly on compatible NAS devices. In the SaaS deployment model, the management service runs on Xopero's cloud infrastructure.
Regardless of the deployment model, the platform provides identical features and functionality through a unified user interface. The management panelis divided into separate modules, each of them dedicated to a different aspect of backup management, such as backup plans, storage, and backup tasks.
A backup agent is a lightweight software installed on a server, laptop, or cloud instance. It reads source data and transfers it to the designated storage destination.
GitProtect backup agents (also referred to as workers in the GitProtect environment) perform all operations requested by the GitProtect Management Service, including processing data (such as encryption and compression), browsing storage repositories, transferring data directly to the storage, and restoring data.
Agents execute backup and recovery operations directly and do not transfer backup data through the management panel. They are responsible for performing all data-processing and infrastructure-related tasks within the system.
Depending on the deployment model and protected resources, administrators can deploy various backup agents, including the cloud worker, feature worker, and local worker.
A data storage system is a medium designed to persistently retain and manage collections of data so that they can be retrieved and used later. Storage technologies span physical media, such as solid-state drives (SSDs) and hard disk drives (HDDs); deployment models, including cloud and hybrid cloud; and systems purpose-built for workloads such as artificial intelligence (AI) and edge computing.
In GitProtect, a storage repository is a designated destination used to persistently retain, organize, and protect backup data for subsequent retrieval and disaster recovery. The solution features a multi-storage architecture that supports storing backup data on-premises (local disks, SMB, NFS, and iSCSI targets), in cloud repositories (Xopero Cloud Storage, AWS, and S3-compatible storage), or in a hybrid model.
Recovering multiple repositories
Restore multiple Bitbucket repository backup copies at once to a local device or to any Git service integrated with GitProtect.
GitProtect enables multiple Bitbucket repositories recovery, allowing administrators to restore several repositories simultaneously within a selected organization or project scope. The process preserves Git history, branches, tags, and supported metadata, ensuring data integrity and consistency across the restored resources.
The below steps demonstrate how to restore multiple Bitbucket repositories at once using GitProtect Management Service.
1
Get into the restore view using the following method:
Single repository recovery
How to restore a single Bitbucket repository backup copy to a Git service or to localhost.
Single repository recovery for Bitbucket enables restoration of an individual repository together with its complete Git history, branches, tags, and associated metadata, without impacting other projects or repositories within the workspace.
The below steps demonstrate how to quickly restore a single Bitbucket repository using GitProtect Management Service.
1
Get into the restore view using the following method:
Installation on Windows servers and workstations
Login to GitProtect Management Service using a web browser, then go to Settings > Advanced > Workers and click Download agent button.
The Download agent window will open — click the appropriate worker version to download it.
Two-factor authentication (2FA)
Learn how to enable two-factor authentication in GitProtect.
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.
1
Click your profile icon in the top-right corner of your Management Service panel and select Account.
2
Creating a backup plan
1
Login to GitProtect Management Service, open the Plans > Backup tab and click the Add plan button in the top bar.
2
Select Bitbucket from the list.
3
Primary components
Management system
The client management service application is called Xopero ONE Backup&Recovery.
Backup agent
The client backup agent application is called Xopero ONE Backup&Recovery Agent.
Communication between the main GitProtect backup system components. The management system serves solely as a configuration interface — all operational tasks are performed by the backup agents.
If the PAT does not exist, you need to add it. The PAT should be pasted into the password field.
selected repositories
.
Set rules — lets you set rules for GitProtect to automatically select resources to protect.
GitProtect allows you to protect the entire Azure DevOps environment.
You can have multiple workers and assign different workers to each backup plan.
Choose whether GitProtect should automatically add new repositories to your backup.
Cloud workers cannot access local network storage. Choose a device with the necessary access if backing up locally.
read:public_key (access keys)
Full backup and restore.
Admin
Full backup and restore.
Write
Full backup and restore.
Read
Full backup. Restore only to the user's own account.
Member
Admin
Full backup. Restore only to the user's own account.
Maintain
Full backup. Restore only to the user's own account.
Write
Full backup. Restore only to the user's own account.
Triage
Backup excluding collaborators. Restore only to the user's own account.
Collaborator
Read
Backup excluding collaborators. Restore only to the user's own account.
Outside collaborator
Default
Backup excluding collaborators. Restore only to the user's own account.
Owner
Permissions for the GitHub App
Permissions for personal access tokens (PAT)
With minimal privileges, certain metadata may not be included in the backup. Select the permissions based on the specific data you need to protect.
If you grant the token only read permissions, you can perform backups, but restoring data requires generating a new token with write permissions.
Useful links and items
Default
Open the Bitbucket tab (DevOps > Bitbucket), then click the Explore button next to the organization whose backup you want to restore (explore icon in list view).
Select all repositories you want to restore and click Restore in the top menu.
2
Click every chosen repository to select the backup plan and copy from which you want to restore data, then click Next.
By default, the latest backup is always selected, regardless of the plan.
3
Select the destination for the recovery and click Next.
You can choose any device or organization registered in GitProtect (you can find more information about cross-recovery in Useful links and items section).
4
In Data to restore section at the top, click Edit and select data you want to restore.
By default, all items are selected for restoration. However, GitProtect allows you to choose which metadata to restore. You can include or exclude each element by toggling the switch next to it.
If an item cannot be restored to the selected Git platform, it will be marked with an orange dot.
5
In the Throttling prevention section, you can add additional DevOps organizationaccounts to avoid throttling.
To use additional organization accounts, you must first add them in the organization settings (organization view > Edit).
6
Configure the recovery destination settings, depending on where the backup will be restored.
Restore to a Git organization
In Map organizations section, select the target organizations where the repositories will be restored.
If the recovery destination is Azure DevOps, the Map organizations section will be replaced by Target organization and Target project settings.
In Restore settings, you can set custom names for all repositories or add a suffix to the original repository names.
Restoration will never overwrite existing repositories. If you enter a custom name—or leave the name as default—and a repository with that name already exists in your organization, the recovery will fail. To ensure successful recovery, either provide a unique name or select Add suffix to repo name to automatically append a unique identifier to the original repository name.
Adjust the bandwidth and other available settings, depending on the recovery destination.
Check which worker is set as the default for recovery and change it if necessary.
Select the destination device (a registered device).
Make sure the device where you want to restore data has the Git client added to the PATH environment variable. The PATH variable is usually configured automatically after Git installation (a system restart may be required) — if it isn’t, you will have to configure it manually.
Specify the restoration directory and configure other options (for example, whether to overwrite existing data or reduce bandwidth). If needed, you can create a new restoration folder on the selected drive from the Management Service level.
7
After defining all parameters, click the Restore button to begin the recovery process. When the process is complete, a new project/repository/folder will be created in your organization/on your device. You can monitor the restoration process in the Tasks tab.
Open the Bitbucket tab (DevOps > Bitbucket), then click the Explore button next to the organization whose backup you want to restore (explore icon in list view).
Search for the repository you want to restore, then click the restore icon in the action menu of that repository.
2
Select the backup plan from which you want to restore data. Click the drop-down under Backup plans section and choose one of the plans from the list.
3
Choose the backup version from all the backups that have already been performed — select the desired date and click the Restore button.
4
Select the data available to restore and click Restore selected or Restore all to proceed.
5
Select the destination for the recovery and click Next.
You can choose any device or organization registered in GitProtect (you can find more information about cross-recovery in Useful links and items section).
6
In the Data to restore section at the top, you can select which of the previously chosen available data you want to restore.
GitProtect allows you to select specific metadata to restore — each element can be included or excluded by toggling the switch next to it.
If an item cannot be restored to the selected Git platform, it will be marked with an orange dot.
7
In the Restore to section, you can change the previously selected recovery destination if needed.
8
In the Throttling prevention section, you can add additional DevOps organization accounts to avoid throttling.
To use additional organization accounts, you must first add them in the organization settings (organization view > Edit).
9
Configure the recovery destination settings, depending on where the backup will be restored.
Restore to a Git organization
In Map organizations section, select the target organization to which the repository will be restored.
If the recovery destination is Azure DevOps, the Map organizations section will be replaced by Target organization and Target project settings.
In Restore settings, you can set a unique, custom name for the repository (or use the custom name automatically generated by GitProtect).
Restoring never overwrites existing repositories in the organization — if you do not set a new name for the restored repository, it keeps its original name with an automatically generated suffix.
When you set a custom name for the repository, and a repository with that name already exists in the specified organization, the recovery will fail.
If you are restoring your repository to a different Git organization than the original (for example, GitHub), in addition to setting a custom name, you can choose whether to add a label to the restored elements and whether to enable pipelines (where applicable).
Check which agent is set as the default for recovery and change it if necessary.
If needed, you can also adjust the bandwidth.
Select the destination device (a registered device).
Make sure the device where you want to restore data has the Git client added to the PATH environment variable. The PATH variable is usually configured automatically after Git installation (a system restart may be required) — if it isn’t, you will have to configure it manually.
Specify the restoration directory and configure other options (for example, whether to overwrite existing data or reduce bandwidth). If needed, you can create a new restoration folder on the selected drive from the Management Service level.
10
After defining all parameters, click the Restore button to begin the recovery process. When the process is complete, a new repository/folder will be created in your organization/on your device. You can monitor the restoration process in the Tasks tab.
The download will start automatically; additionally, an Installation tab with a step-by-step installation instruction will pop-up in the Management Service.
Under the Install section you will see the address combined a port — save it for later as you will have to use it during worker installation.
Once the installation wizard is downloaded, you can move to the installation process.
Open and run the downloaded setup wizard. Click Next to begin the installation process.
Read and accept the End-User License Agreement, then move to the next step.
Choose the installation directory for the GitProtect client.
Paste the previously copied address to the Address field and hit Next to continue.
Click Install to start the installation.
Once the wizard finishes installation, click the Finish button to close it.
You can now activate your device in GitProtect Management Service.
Login to GitProtect Management Service using a web browser, then go to Settings > Advanced > Workers and click Download agent button.
The Download agent window will open — click the appropriate worker version to download it.
The download will start automatically; additionally, an Installation tab with a step-by-step installation instruction will pop-up in the Management Service.
Under the Install section you will see the address combined a port— save it for later as you will have to use it during worker installation.
Open and run the downloaded setup wizard. Click Next to begin the installation process.
Read and accept the End-User License Agreement, then move to the next step.
Choose the installation directory for the GitProtect client.
Paste the previously copied address to the Address field and hit Next to continue.
Click Install to start the installation.
Once the wizard finishes installation, click the Finish button to close it.
You can now activate your device in GitProtect Management Service.
Toggle Two-factor authentication button and click Save in the bottom-right.
2FA option turned on.
3
You will see the change confirmation in the top-right corner of the screen. Once done, log out of your Management Service, then log back in to trigger 2FA setup.
1
Scan the QR code or copy the secret key to your authenticator app. Enter the code from your authenticator app in the designated fields. Once done, click Verify now to finish the application setup.
2
If the verification is successful, you will see a confirmation message.
Below the message you will find your recovery codes — save them before you go to the management console app. If you fail o save the codes right away, you can generate them later in your Management Service account settings.
3
Your MFA setup is now complete. Next time you login to your Management Service panel, you will be prompted to verify yourself with MFA.
If you lose access to your authenticator app, you can log in to Management Service using one of the recovery codes generated during 2FA setup.
Unused codes do not expire over time; they remain active until used or until new codes are generated, either manually or by re-registering the 2FA.
If you have used several codes or suspect they have been compromised, you can generate a new set by going to ⚙️ Settings > Accounts > Edit account and clicking Generate recovery codes button.
1
Log in to your account (use a recovery code if your authentication device is lost or otherwise unavailable).
2
Go to ⚙️ Settings > Accounts > Edit account.
3
Toggle Two-factor authentication off to disable it and save the change. Then toggle it back on and save the change again.
4
Your 2FA configuration is now reset. During your next sign-in, you will be prompted to complete the authenticator app setup.
2FA (two-factor authentication) is a security method that requires two verification factors to confirm a user’s identity, making accounts much harder to compromise even if a password is stolen.
General information
Enabling 2FA in GitProtect
Account settings in GitProtect.
2FA setup in GitProtect
With 2FA turned on in Management Service, you will be prompted to complete the authenticator app setup during your next login. All subsequent logins will require a successful two-factor verification.
Recovery codes
Each code is valid for a single login only — once used, it expires.
Reconfiguring the authenticator app
Select (or add) the Bitbucket DC environment you want to include in the backup process, and choose the repositories to back up.
Optionally, GitProtect allows you to protect the entire Bitbucket DC environment.
4
Specify a name for the backup plan.
5
Select the appropriate metadata that you want to back up. Here, you can also change the default worker, which is the device directly responsible for the backup process of your repositories.
You can have multiple workers and assign different workers to each backup plan.
It is worth noting that the cloud worker (a cloud-installed GitProtectworker) allows you to perform cloud-to-cloud backups if you want to store your backups in the cloud.
6
Select one of the locations assigned to your GitProtect instance as storage.
7
Customize the scheduler and specify how long your data should be retained. If needed, adjust the advanced settings to suit your needs.
8
If necessary, adjust the advanced settings such as encryption, error handling, or bandwidth limits to fit your requirements.
9
Double-check your data and click Save to create the backup plan.
Restore multiple Bitbucket DC repository backup copies at once to any local device or Git service assigned to the GitProtect platform.
GitProtect enables multiple repositories recovery for Bitbucket DC, allowing administrators to restore several repositories simultaneously within a selected project or instance scope. The process preserves complete Git history, branches, tags, and supported metadata, ensuring consistency and data integrity across restored repositories.
Recovery process
The below steps demonstrate how to restore multiple Bitbucket DC repositories at once using GitProtect Management Service.
1
Get into the restore view using the following method:
Open the Bitbucket tab (DevOps > Bitbucket), then click the Explore button next to the organization whose backup you want to restore (explore icon in list view).
Select all repositories you want to restore and click Restore in the top menu.
2
Click every chosen repository to select the backup plan and copy from which you want to restore data, then click Next.
3
Select the destination for the recovery and click Next.
4
In Data to restore section at the top, click Edit and select data you want to restore.
5
In the Throttling prevention section, you can add additional DevOps organizationaccounts to avoid throttling.
6
Configure the recovery destination settings, depending on where the backup will be restored.
In Map organizations section, select the target organizations where the repositories will be restored.
In Restore settings, you can set custom names for all repositories or add a suffix to the original repository names.
7
After defining all parameters, click the Restore button to begin the recovery process. When the process is complete, a new project/repository/folder will be created in your organization/on your device. You can monitor the restoration process in the Tasks tab.
Protected resources
Overview of protected Azure DevOps and Azure DevOps Server resources, including repositories, wikis, and metadata secured by backup.
Azure DevOps protected resources define which parts of the environment GitProtect can access, backup, and restore.
Backup coverage
The following tables list all Azure DevOps and Azure DevOps Server resources covered by backup.
The list is presented in alphabetical order.
ARTIFACTS
BOARDS
BOARD PROCESSES
*The restored comment is attributed to the account performing the restore; content includes the original comment author information and the original creation date.
**Assignee and identity-type fields are not restored directly; instead, a comment is added identifying the original assignee and related values.
***A work item type consists of a name, description, color, icon, enabled/disabled status, and its internal configuration (layout and states).
PIPELINES
PROJECT
*Configuration and definitions are restored; logs, run history, and artifacts are not. Only YAML pipelines that use Azure Repos are supported.
**Secret variables are not backed up due to an API limitation.
PULL REQUESTS
REPOSITORY
TEST PLANS
*Included in backup, but can be restored only to GitHub and GitLab.
**Test run history is backed up and restored. The run state (for example, in progress or needs investigation) is restored in a separate step after the run is created.
***Automated test settings (associated pipelines) are not restored due to current pipeline restore limitations.
Integration
Licensing overview
Overview of GitProtect licensing models, including license types, usage-based components, and key licensing principles.
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.
General information
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.
To get a license, please contact one of our sales partners or email us directly at .
Cancellation and extension of GitProtect licenses purchased through a marketplace (e.g., Atlassian Marketplace) are handled and billed directly by the marketplace, without GitProtect involvement. If you encounter any issues with the transaction or marketplace functionality, please contact the respective marketplace support team first.
To get a tailored offer for your business, please use the on the GitProtect website.
License types
Below you can find all license types available in GitProtect, categorized by protected resource type.
Microsoft 365
Microsoft 365 — licenses for protecting Microsoft Exchange data (including individual mailboxes, shared mailboxes, calendars, contacts) and OneDrive, assigned based on the number of Microsoft 365 user accounts.
Microsoft 365 PRO — licenses for protecting Microsoft Exchange data (including individual mailboxes, shared mailboxes, calendars, contacts), OneDrive, and SharePoint. Assigned based on the number of Microsoft 365 user accounts.
Licenses for protecting Git repositories (Azure DevOps, Bitbucket, GitHub, GitLab), assigned based on the number of repositories:
GitProtect Enterprise (on-premises) — a license type that enables backup of all on-premises systems installed across the entire company.
GitProtect Enterprise (cloud) — a license type that enables backup of all cloud-hosted systems across the entire company.
GitProtect PRO (cloud) — a license type that enables backup of the entire organization. It is designed for individuals, startups, and small teams.
Jira — protection for cloud-hosted Jira instances, assigned based on the number of users; the license must cover all users in the protected Jira instance.
Confluence — protection for cloud-hosted Confluence instances, assigned based on the number of users; the license must cover all users in the protected Confluence instance.
In addition to standard licenses, GitProtect provides supplementary free backup agent (worker) licenses used to initiate specific operations and processes within the software, depending on the use case or deployment scenario.
Free worker licenses allow you to manage storage, restore backups, and back up resources locally, when combined with a dedicated Microsoft 365, Git, Jira, or Confluence license:
Cloud worker — agent responsible for running backup tasks in SaaS deployments. Each GitProtect environment is assigned one cloud worker.
Local worker — licenses for an agent responsible for running backup tasks in on-premises deployments. It allows the agent to be run on the same host as GitProtect Management Service and enables copying its settings. A maximum of one license is available in the license package.
Feature worker — licenses for an agent responsible for running backup tasks for Microsoft 365, Git platforms, Jira, and Confluence in on-premises deployments. It is always included in the license package in unlimited quantities.
Creating a backup plan
Learn how to create a Microsoft 365 backup plan in GitProtect to configure protection for Microsoft Exchange, OneDrive, and SharePoint.
A reliable backup plan is essential for protecting your Microsoft 365 organization's resources and ensuring business continuity when unexpected events occur.
The following steps demonstrate how to create a Microsoft Exchange and OneDrive backup plan using GitProtect Management Service.
1
Open the Backup tab (Plans > Backup) and click the + Add plan button in the top bar.
2
Single repository recovery
Restore a single Bitbucket DC repository backup copy to a Git service or to localhost.
GitProtect enables single repository recovery for Bitbucket DC, allowing restoration of an individual repository together with its complete Git history, branches, tags, and supported metadata. The recovery process maintains repository integrity while ensuring that other projects and repositories within the Bitbucket DC instance remain unaffected.
The following steps demonstrate how to quickly restore a single Bitbucket DC repository using GitProtect Management Service.
1
Get into the restore view using the following method:
Shared mailboxes require the same licensing as individual user mailboxes, with each shared mailbox requiring one Microsoft user license.
To back up all SharePoint sites, the number of sites must be equal to or greater than the number of protected user accounts.
Git platforms
There is no need to assign a license to all repositories. The license is assigned only to the repositories that are to be protected.
Jira
Confluence
Backup agents (workers)
In on-premises deployment model, a license must be manually assigned to an installed agent.
Backup agents are used for process management and data restoration (e.g., restoring cloud platform data). A device assigned a free worker license cannot perform backups of its own local resources.
To restore a repository to a local device, you must have a Git client and the GitProtect worker installed on that device (you can find more information about workers in Useful links and items section).
You can restore only the repository (without metadata) when restoring data to local resources.
To configure the PATH variable in Windows, open the environment variables, select the PATH variable, and click the Edit button. Copy the path to the git.exe file and add it to the PATH variable.
Restore to a device
To restore a repository to a local device, you must have a Git client and the GitProtect worker installed on that device (you can find more information about workers in Useful links and items section).
You can restore only the repository (without metadata) when restoring data to local resources.
To configure the PATH variable in Windows, open the environment variables, select the PATH variable, and click the Edit button. Copy the path to the git.exe file and add it to the PATH variable.
Adjust the bandwidth and other available settings, depending on the recovery destination.
Check which worker is set as the default for recovery and change it if necessary.
Select the destination device (a registered device).
Make sure the device where you want to restore data has the Git client added to the PATH environment variable. The PATH variable is usually configured automatically after Git installation (a system restart may be required) — if it isn’t, you will have to configure it manually.
Specify the restoration directory and configure other options (for example, whether to overwrite existing data or reduce bandwidth). If needed, you can create a new restoration folder on the selected drive from the Management Service level.
By default, the latest backup is always selected, regardless of the plan.
You can choose any device or organization registered in GitProtect (you can find more information about cross-recovery in Useful links and items section).
By default, all items are selected for restoration. However, GitProtect allows you to choose which metadata to restore. You can include or exclude each element by toggling the switch next to it.
If an item cannot be restored to the selected Git platform, it will be marked with an orange dot.
To use additional organization accounts, you must first add them in the organization settings (organization view > Edit).
Restore to a Git organization
If the recovery destination is Azure DevOps, the Map organizations section will be replaced by Target organization and Target project settings.
Restoration will never overwrite existing repositories. If you enter a custom name—or leave the name as default—and a repository with that name already exists in your organization, the recovery will fail. To ensure successful recovery, either provide a unique name or select Add suffix to repo name to automatically append a unique identifier to the original repository name.
To restore a repository to a local device, you must have a Git client and the GitProtect worker installed on that device (you can find more information about workers in Useful links and items section).
You can restore only the repository (without metadata) when restoring data to local resources.
To configure the PATH variable in Windows, open the environment variables, select the PATH variable, and click the Edit button. Copy the path to the git.exe file and add it to the PATH variable.
Select Microsoft 365 from the list.
3
Select the Microsoft 365 Exchange option.
4
Click Select, then specify whether you want to protect the entire organization or only specific user accounts or shared mailboxes.
GitProtect supports Microsoft 365 groups — they appear in the users list and can be used to filter it. If the Search by group option is unavailable, re-register your Microsoft 365 organization to enable it.
5
Set up a name for your backup plan.
6
In Data to protect section, select the resources that you want to back up. You can also change the default backup agent (worker), which is directly responsible for backing up your Microsoft 365 data.
You can deploy multiple agents and assign different agents to each backup plan.
7
Select one of the data stores assigned to your GitProtect instance to use as the backup storage.
8
Customize the scheduler and specify the retention period for your data.
9
Adjust the advanced settings, such as encryption, error handling, or bandwidth limit, to meet your organization's requirements.
Encryption: lets you secure your backup copy with encryption.
Compression: lets you compress and reduce copy size.
Deduplication: allows you to reduce the backup size.
Error handling: allows you to specify how to handle potential backup operation errors.
Bandwidth limit: allows you to reduce network usage and limit network speed during backup.
Backup scripts: enables configuring pre/post scripts executed during backup.
Microsoft 365 diagnostics: lets you enable pre-backup diagnostics, such as the mail message download test.
Task balancing: balances backup speed and CPU load.
Prevent system sleep: prevents your system from suspending while a backup is in progress.
Email notifications: lets you set up email notifications and its recipients.
S3 Buffer Settings: allows you to specify the buffer size allocated for large resources.
10
Review your configuration and click Save to create the backup plan, or Save&Run to start the first backup run immediately.
The following steps demonstrate how to create a SharePoint backup plan using GitProtect Management Service.
1
Open the Backup tab (Plans > Backup) and click the + Add plan button in the top bar.
2
Select Microsoft 365 from the list.
3
Select the SharePoint sites option.
4
Click Select, then specify whether you want to protect the entire environment or only specific SharePoint sites.
5
Set up a name for your backup plan.
6
In Data to protect section, you can change the default backup agent (worker), which is directly responsible for backing up your SharePoint data.
7
Select one of the data stores assigned to your GitProtect instance to use as the backup storage.
8
Customize the scheduler and specify the retention period for your data.
9
Adjust the advanced settings, such as encryption, error handling, or bandwidth limit, to meet your organization's requirements.
Encryption: lets you secure your backup copy with encryption.
Compression: lets you compress and reduce copy size.
10
Review your configuration and click Save to create the backup plan, or Save&Run to start the first backup run immediately.
Backup plan setup (Microsoft Exchange & OneDrive)
Backup plan setup (SharePoint)
Open the Bitbucket tab (DevOps > Bitbucket), then click the Explore button next to the organization whose backup you want to restore (explore icon in list view).
Search for the repository you want to restore, then click the restore icon in the action menu of that repository.
2
Select the backup plan from which you want to restore data. Click the drop-down under Backup plans section and choose one of the plans from the list.
3
Choose the backup version from all the backups that have already been performed — select the desired date and click the Restore button.
4
Select the data available to restore and click Restore selected or Restore all to proceed.
5
Select the destination for the recovery and click Next.
You can choose any device or organization registered in GitProtect (you can find more information about cross-recovery in Useful links and items section).
6
In the Data to restore section at the top, you can select which of the previously chosen available data you want to restore.
GitProtect allows you to select specific metadata to restore — each element can be included or excluded by toggling the switch next to it.
If an item cannot be restored to the selected Git platform, it will be marked with an orange dot.
7
In the Restore to section, you can change the previously selected recovery destination if needed.
8
In the Throttling prevention section, you can add additional DevOps organization accounts to avoid throttling.
To use additional organization accounts, you must first add them in the organization settings (organization view > Edit).
9
Configure the recovery destination settings, depending on where the backup will be restored.
Restore to a Git organization
In Map organizations section, select the target organization to which the repository will be restored.
If the recovery destination is Azure DevOps, the Map organizations section will be replaced by Target organization and Target project settings.
In Restore settings, you can set a unique, custom name for the repository (or use the custom name automatically generated by GitProtect).
Restoring never overwrites existing repositories in the organization — if you do not set a new name for the restored repository, it keeps its original name with an automatically generated suffix.
When you set a custom name for the repository, and a repository with that name already exists in the specified organization, the recovery will fail.
If you are restoring your repository to a different Git organization than the original (for example, GitHub), in addition to setting a custom name, you can choose whether to add a label to the restored elements and whether to enable pipelines (where applicable).
Check which agent is set as the default for recovery and change it if necessary.
If needed, you can also adjust the bandwidth.
Select the destination device (a registered device).
Make sure the device where you want to restore data has the Git client added to the PATH environment variable. The PATH variable is usually configured automatically after Git installation (a system restart may be required) — if it isn’t, you will have to configure it manually.
Specify the restoration directory and configure other options (for example, whether to overwrite existing data or reduce bandwidth). If needed, you can create a new restoration folder on the selected drive from the Management Service level.
10
After defining all parameters, click the Restore button to begin the recovery process. When the process is complete, a new repository/folder will be created in your organization/on your device. You can monitor the restoration process in the Tasks tab.
How to restore a DevOps organization wiki and its metadata separately.
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.
Recovery process for Bitbucket, GitHub, and GitLab
The following steps demonstrate how to quickly recover your wiki using GitProtect Management Service.
1
Get into the restore view using the following method:
Open the appropriate DevOps tab, then click the Explore button next to the organization whose backup you want to restore (explore icon in list view).
Search for the repository containing the wiki you want to restore, then click the restore icon in the action menu of that repository.
2
In the Backup plans section, select the appropriate backup plan, then go to the Backup copies section to choose the point in time from which you want to restore your wiki.
3
Select the Restore now button in the Restore wiki section to configure the restoration settings.
4
Select the destination for the recovery and click Next.
5
In the Restore to section, select the repository where you want to restore the wiki. If you are restoring the wiki to an Azure DevOps or Azure DevOps Server organization, also select the target project.
6
In the Restore settings section, you can limit the bandwidth if required by your network infrastructure and change the device that will perform the restoration.
7
Once all parameters are defined, click Restore to start the recovery process. You can monitor the progress in the Tasks tab; once finished, the wiki will be available in the defined organization account.
The following steps demonstrate how to quickly recover your Azure DevOps project wiki using GitProtect Management Service.
1
Get into the restore view using the following method:
Open the appropriate DevOps tab, then click the Explore button next to the organization whose backup you want to restore (explore icon in list view).
In the Projects & repositories tab, search for the project containing the wiki you want to restore, then click the restore icon in the action menu of that project.
Single repository recovery
Learn how to restore a single Azure DevOps and DevOps Server repository backup.
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.
1
Get into the restore view using the following method:
Group mapping
In this article you will learn how to configure group mapping for SAML authentication.
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:
Claim type — name of the custom claim defined for the application on the Entra ID side to identify the group (the custom group claim name). In this example, claim type value is set to xoperogroup
Deduplication: allows you to reduce the backup size.
Error handling: allows you to specify how to handle potential backup operation errors.
Bandwidth limit: allows you to reduce network usage and limit network speed during backup.
Backup scripts: enables configuring pre/post scripts executed during backup.
Task balancing: balances backup speed and CPU load.
Prevent system sleep: prevents your system from suspending while a backup is in progress.
Email notifications: lets you set up email notifications and its recipients.
Restore to a device
To restore a repository to a local device, you must have a Git client and the GitProtect worker installed on that device (you can find more information about workers in Useful links and items section).
You can restore only the repository (without metadata) when restoring data to local resources.
To configure the PATH variable in Windows, open the environment variables, select the PATH variable, and click the Edit button. Copy the path to the git.exe file and add it to the PATH variable.
2
In the Backup plans section, select the appropriate backup plan, then go to the Backup copies section to choose the point in time from which you want to restore your wiki.
3
Select the destination for the recovery and click Next.
You can choose any organization registered in GitProtect (you can find more information about cross-recovery in Useful links and items section).
If your destination is GitHub, make sure that your repository has at least one wiki page created.
4
Select the Restore now button in the Restore wiki section to configure the restoration settings.
5
In the Restore to section, select the repository where you want to restore the wiki. If you are restoring the wiki to an Azure DevOps or Azure DevOps Server organization, also select the target project.
6
In the Restore settings section, you can limit the bandwidth if required by your network infrastructure and change the device that will perform the restoration.
7
Once all parameters are defined, click Restore to start the recovery process. You can monitor the progress in the Tasks tab; once finished, the wiki will be available in the defined organization account.
You can choose any organization registered in GitProtect (you can find more information about cross-recovery in Useful links and items section).
If your destination is GitHub, make sure that your repository has at least one wiki page created.
Open the Azure DevOps tab (DevOps > Azure DevOps), then click the Explore button next to the organization whose backup you want to restore (explore icon in list view).
Go to the Repositories tab and search for the repository you want to restore, then click the restore icon in the action menu of that repository.
2
Select the backup plan from which you want to restore data. Click the drop-down under Backup plans section and choose one of the plans from the list.
3
Choose the backup version from all the backups that have already been performed — select the desired date and click the Restore button.
4
Select the data available to restore and click Restore selected or Restore all to proceed.
5
Select the destination for the recovery and click Next.
You can choose any device or organization registered in GitProtect (you can find more information about cross-recovery in Useful links and items section).
6
In the Data to restore section at the top, you can select which of the previously chosen available data you want to restore.
7
In the Restore to section, you can change the previously selected recovery destination if needed.
8
In the Throttling prevention section, you can add additional DevOps accounts to avoid throttling.
To use additional organization accounts, you must first add them in the organization settings (organization view > Edit).
9
Configure the recovery destination settings, depending on where the backup will be restored.
Restore to a Git organization
In Map organizations section, select the target organization to which the repository will be restored.
If the recovery destination is Azure DevOps, the Map organizations section will be replaced by Target organization and Target project settings.
In Restore settings, you can set a unique, custom name for the repository (or use the custom name automatically generated by GitProtect).
Restoring never overwrites existing repositories in the organization — if you do not set a new name for the restored repository, it keeps its original name with an automatically generated suffix.
When you set a custom name for the repository, and a repository with that name already exists in the specified organization, the recovery will fail.
If you are restoring your repository to a different Git organization than the original (for example, GitHub), in addition to setting a custom name, you can choose whether to add a label to the restored elements (where applicable).
Check which worker is set as the default for recovery and change it if necessary.
If needed, you can also adjust the bandwidth.
Select the destination device (a registered device).
Make sure the device where you want to restore data has the Git client added to the PATH environment variable. The PATH variable is usually configured automatically after Git installation (a system restart may be required) — if it isn’t, you will have to configure it manually.
Specify the restoration directory and configure other options (for example, whether to overwrite existing data or reduce bandwidth). If needed, you can create a new restoration folder on the selected drive from the Management Service level.
10
After defining all parameters, click the Restore button to begin the recovery process. When the process is complete, a new repository/folder will be created in your organization/on your device. You can monitor the restoration process in the Tasks tab.
Claim value — a unique Entra ID group identifier (ID) to be mapped (not its name).
Group mapping configuration.
If you did not customize the name of the group claim, when configuring group mapping in GitProtect Management Service, use the full, original claim type name as defined in the schema: http://schemas.microsoft.com/ws/2008/06/identity/claims/groups
The only account not subject to group mapping permissions is the root admin — logging in using SAML with different group permissions doesn't change the root admin access level; user remains the root admin after signing in, and so do their root admin assigned permissions.
Recovering multiple projects
Restore multiple Azure DevOps and DevOps Server project backup copies at once.
Restoring multiple Azure DevOps projects enables organizations to quickly recover projects, repositories, and source code at scale, ensuring consistent and reliable restoration across the development environment.
Recovery process
The below steps demonstrate how to restore multiple Azure DevOps projects at once using GitProtect Management Service.
Deleted artifacts cannot be restored while they remain in the recycle bin — they can be restored, but you must remove them from the recycle bin first.
Azure does not allow restoring deleted packages to the same feed. Once a package is deleted, it must remain deleted. Restoring to a new feed does not have this limitation, so all packages should be restored there.
1
Get into the restore view using the following method:
Open the Azure DevOps tab (DevOps > Azure DevOps), then click the Explore button next to the organization whose backup you want to restore (explore icon in list view).
In the Projects & repositories tab, select all projects you want to restore, and then click Restore in the top menu.
2
Click every chosen project to select the backup plan and copy from which you want to restore data, then click Next.
3
Select the destination for the recovery and click Next.
4
In Data to restore section at the top, click Edit and select data you want to restore.
5
In the Throttling prevention section, you can add additional DevOps accounts to avoid throttling.
6
Configure the recovery destination settings, depending on where the backup will be restored.
Select the target organization (where applicable).
In Restore settings,you canset custom names for all projects and repositories in the project, or add a suffix to their original names.
7
After defining all parameters, click the Restore button to begin the recovery process. When the process is complete, a new project/repository/folder will be created in your organization/on your device. You can monitor the restoration process in the Tasks tab.
GitProtect.io for Jira
Learn how to sign up for a free GitProtect trial through Atlassian Marketplace.
Registering for GitProtect through Atlassian Marketplace allows you to quickly connect your Jira instance to a dedicated GitProtect service for seamless backup and management.
General information
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 app is linked to a single GitProtect service instance, which is created at the moment the app is installed on your Jira site.
Registering your Jira site with GitProtect via Atlassian Marketplace automatically starts a free trial — you can change your subscription model using the panel.
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.
Registration
Follow the steps below to complete account registration and deploy the GitProtect.io for Jira application.
To register a GitProtect account and connect it to Jira, you must use a personal access token (PAT).
1
Log in to your Atlassian account and go to the Atlassian Marketplace ().
2
Type gitprotect in the search box and press Enter.
3
Find the GitProtect.io for Jira tile in the search results and click it.
4
On the application page, click the Try it free button in the top-right corner.
5
Select the site where GitProtect.io will be installed and click Review in the bottom-right corner.
6
Review your configuration settings and click the Start free trial button.
7
Atlassian will add the GitProtect.io app to your selected Jira site.
8
When the GitProtect.io app is successfully added to your Jira site, a notification pop-up will appear. Select Configure to open the app view page.
9
Wait for the installation to complete.
10
Another pop-up will appear. Enter your personal access token (Jira API key) and click Save to proceed.
11
After the installation is complete, you will see a confirmation message. Click Not now to continue to the GitProtect.io app main page, or select Run Plan to start your first backup using the default settings.
12
Your GitProtect registration and deployment are now complete. Proceed to the section to learn about app features and how to create and manage your Jira backups.
In the GitProtect.io app view in Jira you can change the plan execution time, manually trigger a backup job, and check your backup status.
To fully manage your Jira backups—including setting up backup plans, managing storage, monitoring running tasks, reviewing logs, adding additional accounts, configuring notifications, and using all GitProtect features—log in to the GitProtect Management Service using the More features button in the top-right corner of the app page.
Accessing the Management Service does not require additional credentials. You are automatically logged in through the GitProtect integration with Jira.
How to restore multiple Azure DevOps and DevOps Server repository backup copies at once.
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.
1
Get into the restore view using the following method:
Post-registration actions
You can learn more about using the GitProtect.io for Jira app in this section.
To restore a repository to a local device, you must have a Git client and the GitProtect worker installed on that device (you can find more information about workers in Useful links and items section).
You can restore only the repository (without metadata) when restoring data to local resources.
To configure the PATH variable in Windows, open the environment variables, select the PATH variable, and click the Edit button. Copy the path to the git.exe file and add it to the PATH variable.
If you are restoring your project to the Azure DevOps or DevOps Server organization:
Choose whether to restore repositories from the project's copy:
When the Restore only repositories located in this project backup switch is turned off during the restore process, along with the project, all of its protected repositories are restored, regardless of whether the repositories were protected by the same plan or by different plans. The latest available backups are used.
When the switch is turned on, a different restore mechanism is applied. In this case, only repositories backed up by the same plan as the project are restored.
Adjust the bandwidth and other available settings, depending on the recovery destination.
Check which worker is set as the default for recovery and change it if necessary.
Select the destination device (a registered device).
Make sure the device where you want to restore data has the Git client added to the PATH environment variable. The PATH variable is usually configured automatically after Git installation (a system restart may be required) — if it isn’t, you will have to configure it manually.
Specify the restoration directory and configure other options (for example, whether to overwrite existing data or reduce bandwidth). If needed, you can create a new restoration folder on the selected drive from the Management Service level.
By default, the latest backup is always selected, regardless of the plan.
You can choose any device or organization registered in GitProtect (you can find more information about cross-recovery in Useful links and items section).
By default, all items are selected for restoration. However, GitProtect allows you to choose which metadata to restore. You can include or exclude each element by toggling the switch next to it.
To use additional organization accounts, you must first add them in the organization settings (organization view > Edit).
Restore to a Git organization
If the custom name—or the original project and repository names—already exists within the selected Git organization, the restoration will fail. To ensure successful recovery, choose unique names or select the Add suffix to repo/project name option, so the restored items to retain their original names with an automatically generated suffix.
Due to required changes, the latter mechanism is not available for backups created with GitProtect versions earlier than 2.0.5 or for workers running versions lower than 2.0.5.
Restore to a device
To restore a repository to a local device, you must have a Git client and the GitProtect worker installed on that device (you can find more information about workers in Useful links and items section).
You can restore only the repository (without metadata) when restoring data to local resources.
To configure the PATH variable in Windows, open the environment variables, select the PATH variable, and click the Edit button. Copy the path to the git.exe file and add it to the PATH variable.
Open the
Azure DevOps
tab (
DevOps
>
Azure DevOps
), then click the
Explore
button next to the organization whose backup you want to restore (explore
icon in list view).
Go to the Repositories tab, select all repositories you want to restore, and then click Restore in the top menu.
2
Click every chosen repository to select the backup plan and copy from which you want to restore data, then click Next.
By default, the latest backup is always selected, regardless of the plan.
3
Select the destination for the recovery and click Next.
You can choose any device or organization registered in GitProtect (you can find more information about cross-recovery in Useful links and items section).
4
In Data to restore section at the top, click Edit and select data you want to restore.
By default, all items are selected for restoration. However, GitProtect allows you to choose which metadata to restore. You can include or exclude each element by toggling the switch next to it.
5
In the Throttling prevention section, you can add additional Azure DevOps accounts to avoid throttling.
To use additional organization accounts, you must first add them in the organization settings (organization view > Edit).
6
Configure the recovery destination settings, depending on where the backup will be restored.
Restore to a Git organization
In Map organizations section, select the target organizations where the repositories will be restored.
If the recovery destination is Azure DevOps, the Map organizations section will be replaced by Target organization and Target project settings.
In Restore settings,you canset custom names for all repositories or add a suffix to the original repository names.
Restoration will never overwrite existing repositories. If you enter a custom name—or leave the name as default—and a repository with that name already exists in your organization, the recovery will fail. To ensure successful recovery, either provide a unique name or select Add suffix to repo name to automatically append a unique identifier to the original repository name.
Adjust the bandwidth and other available settings, depending on the recovery destination.
Check which worker is set as the default for recovery and change it if necessary.
Select the destination device (a registered device).
Make sure the device where you want to restore data has the Git client added to the PATH environment variable. The PATH variable is usually configured automatically after Git installation (a system restart may be required) — if it isn’t, you will have to configure it manually.
Specify the restoration directory and configure other options (for example, whether to overwrite existing data or reduce bandwidth). If needed, you can create a new restoration folder on the selected drive from the Management Service level.
7
After defining all parameters, click the Restore button to begin the recovery process. When the process is complete, a new project/repository/folder will be created in your organization/on your device. You can monitor the restoration process in the Tasks tab.
Overview of protected Bitbucket resources, including repositories, wikis, and metadata secured by backup.
Bitbucket protected resources define which parts of your environment GitProtect can access, secure, and restore.
Backup coverage
The following list includes all Bitbucket resources covered by backup.
The list is presented in alphabetical order.
ACCESS KEYS
BRANCHING MODEL
BRANCH RESTRICTIONS
DOWNLOADS
ISSUES
PIPELINES
PULL REQUESTS
REPOSITORY
WEBHOOKS
Required permissions
Full list of permissions required for integrating Azure DevOps and Azure DevOps Server with GitProtect.
Required permissions for Azure DevOps and Azure DevOps Server specify the access levels GitProtect needs to securely back up and restore your data.
Permissions for Azure DevOps
User access levels
The account used for integration must have an appropriate access level assigned within Azure DevOps:
Basic.
Visual Studio Subscriber — professional or enterprise tier.
GitHub Enterprise — similar to basic.
Stakeholder (not recommended) — this level has limited access and cannot properly protect repositories.
To integrate Azure DevOps with GitProtect using OAuth, make sure the account has an administrator role. Otherwise, you may encounter permission errors or find that the approval button is inactive.
When integrating Azure DevOps via OAuth, the following scopes are required:
The ability to authorize the GitProtectOAuth application depends on your organization's User consent settings within Azure DevOps. The following options are available:
Consent policy
Authorization requirement
To ensure both backup and restore operations succeed, the following permissions are required:
Organization level:
General:
Create new projects (restore)
Boards:
For on-premise installations, use the personal access token (PAT) method.
Restoring SharePoint sites
Learn how to restore SharePoint sites from a backup.
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.
Recovery process
The below steps demonstrate how to restore SharePoint sites and their metadata using GitProtect Management Service.
1
Open the Microsoft 365 tab, then click the Explore button next to the organization whose backup you want to restore.
2
In the SharePoint Sites tab, search for the site whose data you want to restore, and then click the restore button in the action menu for that site.
3
Next, select the backup plan from which you want to restore data. Click View available plans, and then select a plan from the list.
4
Choose the backup version from all the backups that have already been performed — select the desired date and click the Restore button.
5
Select the restore destination and click Next.
6
In the next pane, select the data you want to restore, and then click Restore selected. Alternatively, click Restore all to restore all available data.
7
Next, depending on the selected restore destination, configure the Restore to and Restore directory settings.
In the Overwrite data section, choose one of the following options:
Don't overwrite site and its data.
8
In Restore settings, you can limit bandwidth usage and select the default backup agent (worker) that will be used to restore the data (where applicable).
9
After defining all parameters, click the Restore button to start the recovery process. You can monitor the process in the Tasks tab.
To restore a repository to a local device, you must have a Git client and the GitProtect worker installed on that device (you can find more information about workers in Useful links and items section).
You can restore only the repository (without metadata) when restoring data to local resources.
To configure the PATH variable in Windows, open the environment variables, select the PATH variable, and click the Edit button. Copy the path to the git.exe file and add it to the PATH variable.
(vso.project_manage)
Create process (restore)
Edit process (restore)
Project level:
General:
View project-level information (backup)
Repositories level:
Create branch (restore)
Create repository (restore)
Read (backup)
Allow user consent for apps from verified publishers, for selected permissions
Any user can authorize the app, provided that all requested permissions are classified as low impact by your administrator.
Do not allow user consent
Only users with the Application Administrator or Global Administrator role can authorize the integration.
Let Microsoft manage your consent settings (Recommended)
GitProtect can only protect projects that the integrated user account has explicit access to.
OAuth integration
GitProtect supports only organizational accounts (Microsoft Entra ID) — personal accounts are not supported. For private accounts, use PAT instead.
Installation permissions for OAuth
Personal Access Token (PAT) integration
Prerequisites:
Required scopes:
When performing a backup with minimal permissions, some metadata might be excluded. To ensure complete protection, select the permissions based on your data protection needs. Note that with read-only permissions, backups can be made, but restoring requires a new token or password with write access.
Granular permission settings
Permissions for Azure DevOps Server
Personal Access Token (PAT) integration
Prerequisites:
Required scopes:
When performing a backup with minimal permissions, some metadata might be excluded. To ensure complete protection, select the permissions based on your data protection needs. Note that with read-only permissions, backups can be made, but restoring requires a new token or password with write access.
Authorization is subject to Microsoft's current security guidelines. While this currently allows for GitProtect integration, availability may change based on Microsoft's evolving policies.
Overwrite only if existing resources are older than restored.
Always overwrite.
In the Site permissions section, specify whether GitProtect should restore site permissions along with other site data.
In the Restore to pane, select the site where you want to restore the data, and click Save.
In the Overwrite data section, choose one of the following options:
Don't overwrite site and its data.
Overwrite only if existing resources are older than restored.
Always overwrite.
In the Site permissions section, specify whether GitProtect should restore site permissions along with other site data.
In the Restore to pane, select the Microsoft 365 organization where you want to restore the data, and click Save.
Next, enter a custom name for the new site.
In the Site permissions section, specify whether GitProtect should restore site permissions along with other site data.
In the Restore to pane, select the device to use as the restore destination, and click Save.
In the Restore directory section, select the directory where the data will be restored, and then click Apply.
Restore to the original site
Restore to an existing site
Restore to a new site
If the site URL is already in use, SharePoint will modify the new URL by adding a few characters to make it unique (typically, a number at the end).
Restore to a device
Next, use the following command to view the list of containers (or view the list in Docker Desktop):
If you see no errors, that means the Management Service implementation was done correctly. You can open the GitProtect Management Service web panel using the following address:
Before you start using Management Service you must create an administrator account and assign a license to your unit.
Login to your QNAP web panel and open the App Center application. Go to QNAP Store > All Apps and search for Container Station.
Download the Container Station application. Once downloaded, open the app and select the path you'll be using as your Docker container data directory.
Click Start Now to proceed.
In the Container Station application, open the Containers menu option, and click the Create button.
In Image Configuration, choose Advanced mode. For Image type select Docker image, and in the Image field, paste the following:
Ensure Try pulling the image from the registry before creating the container. checkbox is checked, then hit Next.
In the Configure Container tab, configure the GitProtect Docker container and hit Next to continue.
Name — set a custom name for the container
Auto start — defines if the container should startup automatically (i.e., in case of QNAP restart)
Publish network ports — enter a port number in the Host field— this will be the port used to connect to GitProtect service on the container on port 80 (the recommended host port number is 28555)
Double-check your configuration settings and hit Finish.
Container Station will download the latest GitProtect image and create the container based on it.
Once the container creation process is completed, your new container will be available in the Container Station application (under Containers menu option).
Connect to GitProtect using your web URL address in the following format (you can find it under Container Details > General > Web URL):
http://<QNAPaddress>:<port>
To finish the XMS setup, create a new administrative account, provide the license code, and select data to protect.
Login to your QNAP web panel and open the App Center application. Go to QNAP Store > All Apps and search for Container Station.
Download the Container Station application. Once downloaded, open the app and select the path you'll be using as your Docker container data directory.
Click Start Now to proceed.
Open the Container Station application and click ➕ Create in the left-hand side menu.
Copy and paste xopero/gitprotect-service in the search field and hit Enter to search for the Management Service Docker image (it should be the first search result in Docker Hub tab).
Click the Install button next to the Docker image to start the container creation process.
In the Create Container window, configure the GitProtect Docker container.
Name — set a custom name for the container
Auto start — defines if the container should startup automatically (i.e., in case of QNAP restart)
CPU Limit — allows you to set the CPU percentage usage available for the container
Memory Limit — RAM memory allocated to the container
Scroll down a little and click the ⚙️ Advanced Settings>>
In the ⚙️ Advanced Settings>> go to Network and click the Add button on the right. Enter a port number in the Host field under the Port Forwarding section— this will be the port used to connect to GitProtect service (the recommended, default port number is 28555).
Click the Create button— this will display the setup summary. Double-check your configuration and click OK to create the container.
Once the container creation process is completed, your new container will be available in the Container Station application (under Container menu option).
Connect to GitProtect Management Service by launching it via Container Station, or using your web URL address in the following format:
http://<QNAPaddress>:<port>
To finish the Management Service setup, create a new administrative account, provide the license code, and select data to protect.
Open the Docker Hub, navigate to the Container menu, and click Create button.
Expand the Image section and select Add image. Then, search for xopero/gitprotect-service. Once located, select the image, click Download, and choose the version tagged as latest. Confirm the selection to proceed.
Once you download the image, select it from the Image drop-down menu in General Settings. Next, define a name for the container and enter it in the Container Name field. Configure container resource limits if necessary.
Check the Enable auto-restart checkbox to ensure the container automatically restarts when the device reboots, and proceed to the next step.
In Volume Settings, click ➕ Add Folder button. To ensure data persistence during container updates or maintenance operations, mount the management databases to an external directory. The databases are stored in /app/Xopero and should be mapped to a designated location outside the container to prevent data loss or inconsistencies.
In the Environment section, define the required variables:
ASPNETCORE_URLS — Management Service ports for http and https protocol (i.e., http://+:PORT_NUMBER;https://+:PORT_NUMBER)
Select host from the Network drop-down menu to enable the container to share the same network namespace as the container's host.
Confirm the configuration and click Next. In Summary, double-check the settings and hit Done to finish the container creation process.
Once you've created the container, you can connect to your XMS using one of the following addresses:
Replace <docker_name>.tar with the name of your Management Service Docker image file.
In the above command, replace drive_location_database with the location to mount the database on (from the container to the local directory) — this is important for upgrading the container later. In place of container_name, enter the name of your container and in place of ms_port, enter the service port which will be used by GitProtect (by default, the port is set to 28555).
To install the GitProtect worker within a Docker container, use the images available on Docker Hub:
Create a host directory for the GitProtect Management Service container databases (which are located at /app/Xopero inside the container) to store databases outside the container:
Required permissions
Permissions required for integrating Microsoft 365 with GitProtect.
The required Microsoft 365 permissions define the access levels GitProtect needs to securely back up and restore your data.
To integrate a Microsoft 365 organization with GitProtect, ensure it uses a Microsoft 365 business license.
To back up a single Microsoft 365 account, the account must have a Microsoft 365 license assigned. This also applies to shared mailboxes. License assignments can be managed in the Microsoft 365 admin center.
Each Microsoft 365 account and shared mailbox requires one GitProtect license to back up its data.
The backup process requires a backup agent (worker), which communicates with the Microsoft 365 API, downloads the requested data, and performs the backup. You can use either a cloud or local worker. Any device with the Xopero ONE Backup&Recovery Agent installed can act as a worker.
Select the latest image version and click Next to continue.
Environment setup
Deployment
Environment setup
Deployment
The management console is available on port 28555 for the encrypted protocol (https), and on port 28556 for the unencrypted (http) protocol.
xopero/gitprotect-service:latest
Run the container with the correct volume mounting and environment variables using the following command:
Check if the container works correctly by using the following command:
Once all the above steps are completed, the worker will report to the GitProtect Management Service panel for activation.
Download the Container Station app from the AppCenter.
Login to your QNAP web panel and open the AppCenter application. In QNAP Store, select All Apps and search for the Container Station.
Download and open the application. Select the path that will be used as a directory for your Docker container data, and click Start Now to proceed.
Once done, download the GitProtect worker Docker image, which is available .
Open the Container Station application and navigate the Import tab.
Click the ➕Import button to upload the previously downloaded Docker image file.
In Create Import Task window, select the source type and file path of the GitProtect workerDocker image and hit Next to continue.
Within the Create Container tab, the form contains several fields, with the most crucial being:
Name — here you can set a custom name for the container
Auto start — defines if the container will star automatically in case of, for example, QNAP restart
CPU Limit — allows you to specify the percentage of CPU usage allocated for the container
Memory Limit — RAM limit for the container
Click the ⚙️Advanced Settings >> button and navigate to the Environment section.
To add a new environment variable, click the Add button, name it ManagementServiceUrl, and set its value to your GitProtect Management Service address*.
‼️*ManagementServiceUrl – your GitProtect Management Service address in one of the following formats (depending on the deployment model):
a. http://ipaddress:port, i.e., http://192.168.0.1:28555
b. https://XMSID.ads.xopero.com, i.e., https://a00b0dc0-0116-0000-0000-d0000028960e.ads.xopero.com
Go to the Shared Folders section — here you can mount your QNAP volumes to the GitProtectworkerDocker container.
To back up data from your QNAP device, choose Add under Volume from host section — it lets you specify which data the GitProtect container can access. Select a directory from the host in Volume from host field and enter the path visible inside the container in the Mount Point field.
Once you're done with the above steps, click Create to continue.
In the Summary window double-check your settings, then click OK to finish the configuration.
You can now connect to your GitProtect Management Service admin panel to activate the agent.
Deployment
To deploy the GitProtect worker on a Synology device using Docker, use the Container Manager application. If it's not installed, download it from the Package Center.
Navigate to the Container tab and click the Create button. Expand the Image section and click Add image, then search for xopero/xone-agent image.
All GitProtect service images are hosted on Docker Hub.
Select the image, click Download, and choose the version tagged as latest. Click Select to confirm.
Once the image is downloaded, select it from the Image field drop-down menu.
Next, define a custom name for the container. Additionally, configure container resource limits if needed.
Check the Enable auto-restart option to ensure the container automatically restarts when the device reboots, then click Next to proceed.
In the Volume Settings section, click the ➕Add Folder button, and select directories that require protection. The container needs to have external directories mounted to access them while performing backups.
Additionally, to ensure data persistence during container updates or maintenance operations, mount worker databases to an external directory. These databases are located in /app/Xopero and should be mapped to a designated location outside the container to avoid data loss or inconsistency.
Next, in the Environment section, define the required variables:
ManagementServiceUrl — your GitProtect Management Service address in one of the following formats (depending on the deployment model):
a. http://ipaddress:port, i.e., http://192.168.0.1:28555
b. https://XMSID.ads.xopero.com, i.e., https://a00b0dc0-0116-0000-0000-d0000028960e.ads.xopero.com
XoperoOverriddenHostName — specify worker's name to facilitate identification
Click Next to confirm the configuration. In Summary window, double-check your settings and if they're all correct, hit Done to finalize the process.
docker run -v /host/path:/container/path -e ENV_VAR=value image_name
docker run -d \ --name <container_name> \ -e ManagementServiceUrl="<your_gitprotect_service_URL>" \
Example
docker run -d \ --name gitprotect-worker\
To add your Microsoft 365 organization to GitProtect, you must use a global administrator account. Only a global administrator has the necessary permissions to back up data from all user accounts in the organization.
The following tables list Xopero apps and their permissions, which are automatically installed in the end user's Entra ID when integrating Microsoft 365 with GitProtect.
This application is used at the beginning of the integration to install and grant the necessary permissions for the Xopero ONE MS365 PRO app.
API name
Claim value
Permission
Type
Microsoft Graph
Directory.AccessAsUser.All
Access directory as the signed-in user.
delegated
This application is required to back up and recover data from Microsoft 365 tenants and is installed automatically in Entra ID by Xopero ONE Registrator.
API name
Claim value
Permission
Type
Microsoft Graph
Mail.ReadWrite
Read and write mail in all mailboxes.
application
API name
Claim value
Permission
Type
Office 365 Exchange Online
full_access_as_app
Use Exchange Web Services (EWS) with full access to all mailboxes.
application
API name
Claim value
Permission
Type
Office 365 Exchange Online
full_access_as_app
Use Exchange Web Services (EWS) with full access to all mailboxes.
application
General requirements
You do not need to assign any licenses to cloud workers — the appropriate license is assigned automatically by the GitProtect system.
Account permissions
Learn more about Microsoft 365 administrator roles in .
Permissions required to integrate Bitbucket with GitProtect to protect its resources.
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:
Replace GitProtect Management Service address with your GitProtect Management Service address*.
You can mount multiple directories to the container using Add Volume button and repeating the operation.
To back up data from your QNAP device, choose Bind Mount Host Path under Add Volume drop-down menu — it lets you specify which data the GitProtect container can access. Select a directory from the host and enter the path visible inside the container in the Container field.
Environment setup
Deployment
Selecting a file from a local source enables you to choose files stored on your device. Alternatively, you can use the NAS option to access files directly from QNAP.
You can mount multiple directories to the container using Add button in Volume from host section and repeating the operation.
For instance, if you need to back up a directory named Backup inside a public shared folder, set the Volume from the host field to /Public/Backup. The Mount Point can be different, i.e., /Backup.
To protect data stored in the Public directory, select this folder and specify the same path to ensure consistency between the host and the container's file systems.
You can mount multiple directories to the container by clicking ➕ Add Folder and repeating the operation.
Every API token created for Bitbucket integration with GitProtect requires specific permission scopes to restrict data access and define the exact operations the token can execute.
To ensure successful backup and recovery tasks, API token must be provisioned with the below required permissions.
OAuth permissions
Bitbucket API token scopes
GitProtect does not support unscoped API tokens for Bitbucket integrations.
Applying minimal privileges may cause certain metadata (such as issues) to be omitted from the backup. Furthermore, while read-only permissions are sufficient for running backups, restoring data requires write access, which will necessitate generating a new token with elevated privileges during a recovery operation. To prevent backup omissions and ensure seamless, immediate data recovery, it is strongly recommended to select all required permissions when creating an API token for Bitbucket.
Backup permission scopes
Restore permission scopes
Useful links and items
Microsoft Graph
offline_access
Maintain access to data you have granted access to.
delegated
Microsoft Graph
profile
View user's basic profile.
delegated
Microsoft Graph
openid
Sign users in.
delegated
Microsoft Graph
User.ReadWrite.All
Read and write all users' full profile information.
application
Microsoft Graph
Application.ReadWrite.All
Read and write all applications.
application
Microsoft Graph
Group.Read.All
Read all groups.
application
Microsoft Graph
Contacts.ReadWrite
Read and write contacts in all mailboxes.
application
Microsoft Graph
Group.Create
Create groups.
application
Microsoft Graph
Files.ReadWrite.All
Read and write files in all site collections.
application
Microsoft Graph
Calendars.ReadWrite
Read and write calendars in all mailboxes.
application
Microsoft Graph
Tasks.ReadWrite
Create, read, update, and delete user's tasks and task lists.
delegated
Microsoft Graph
Directory.ReadWrite.All
Read and write directory data.
delegated
Microsoft Graph
Group.ReadWrite.All
Read and write all groups.
delegated
Microsoft Graph
offline_access
Maintain access to data you have granted access to.
Overview of Microsoft 365 resources protected by backup, including applications such as Microsoft Exchange, OneDrive, and SharePoint.
Microsoft 365 protected resources define which parts of the environment GitProtect can access, backup, and restore.
The following list includes all Microsoft 365 resources covered by backup.
Backup coverage
The list is presented in alphabetical order.
Microsoft Exchange
*Protection includes both individual and shared mailboxes. Shared mailboxes require the same licensing as individual user mailboxes, with each shared mailbox requiring one Microsoft user license.
OneDrive
*Includes information about permission settings.
SharePoint
*These elements can be backed up, but they cannot be fully restored to their original state.
**The size limit for restored files is 2 MB.
Single project recovery
Recover a single Azure DevOps and DevOps Server project backup copy, including its repositories and other metadata.
GitProtect enables single project recovery for Azure DevOps, allowing organizations to restore individual projects along with their selected metadata, ensuring data integrity and consistency while minimizing disruption to other projects and repositories.
Recovery process
The below steps demonstrate how to quickly restore a single Azure DevOps project using GitProtect Management Service.
Deleted artifacts cannot be restored while they remain in the recycle bin — they can be restored, but you must remove them from the recycle bin first.
Azure does not allow restoring deleted packages to the same feed. Once a package is deleted, it must remain deleted. Restoring to a new feed does not have this limitation, so all packages should be restored there.
1
Get into the restore view using the following method:
Open the Azure DevOps tab (DevOps > Azure DevOps), then click the Explore button next to the organization whose backup you want to restore (explore icon in list view).
In the Projects & repositories tab, search for the project you want to restore, then click the restore icon in the action menu of that project.
2
Select the backup plan from which you want to restore data. Click the drop-down under Backup plans section and choose one of the plans from the list.
3
Choose the backup version from all the backups that have already been performed — select the desired date and click the Restore button.
4
Select the destination for the recovery and click Next.
5
Select the available metadata to restore and click Restore selected or Restore all to proceed.
6
In the Data to restore section at the top, you can select which of the previously chosen available data you want to restore, if needed.
7
In the Restore to section, you can change the previously selected recovery destination if needed.
8
In the Throttling prevention section, you can add additional DevOps accounts to avoid throttling.
9
Configure the recovery destination settings, depending on where the backup will be restored.
Select the target organization (where applicable).
If you are restoring your project to Azure DevOps or DevOps Server organization:
10
After defining all parameters, click the Restore button to begin the recovery process. When the process is complete, a new project/repository/folder will be created in your organization/on your device. You can monitor the restoration process in the Tasks tab.
Set a unique, custom name for the project in Restore settings (or use the custom name automatically generated by GitProtect).
Choose whether to restore repositories from the project's copy:
When the Restore only repositories located in this project backup switch is turned off during the restore process, all of project's protected repositories are restored, regardless of whether the repositories were protected by the same plan or by different plans. The latest available backups are used.
When the switch is turned on, a different restore mechanism is applied. In this case, only repositories backed up by the same plan as the project are restored.
If you are restoring your project to a different Git organization than the original (for example, GitHub), you can set custom names for all repositories in the project or add a suffix to the original repository names. You can also choose whether to add a label to the restored elements (where applicable).
Adjust the bandwidth settings.
Check which worker is set as the default for recovery and change it if necessary.
Select the destination device (a registered device).
Make sure the device where you want to restore data has the Git client added to the PATH environment variable. The PATH variable is usually configured automatically after Git installation (a system restart may be required) — if it isn’t, you will have to configure it manually.
Specify the restoration directory and configure other options (for example, whether to overwrite existing data or reduce bandwidth). If needed, you can create a new restoration folder on the selected drive from the Management Service level.
You can choose any device or organization registered in GitProtect (you can find more information about cross-recovery in Useful links and items section).
GitProtect allows you to select specific metadata to restore — each element can be included or excluded by toggling the switch next to it.
The available data to restore depends on the restoration destination.
To use additional organization accounts, you must first add them in the organization settings (organization view > Edit).
Due to required changes, the latter mechanism is not available for backups created with GitProtect versions earlier than 2.0.5 or for workers running versions lower than 2.0.5.
If the custom name or the original repository name already exists in the selected Git organization, the restore will fail. To complete the restoration successfully, you must choose unique repository names or select the Add suffix to repo name option so the restored repositories keep their original names with an automatically generated suffix.
Restore to a device
To restore a repository to a local device, you must have a Git client and the GitProtect worker installed on that device (you can find more information about workers in Useful links and items section).
You can restore only the repository (without metadata) when restoring data to local resources.
To configure the PATH variable in Windows, open the environment variables, select the PATH variable, and click the Edit button. Copy the path to the git.exe file and add it to the PATH variable.
Third-party libraries
Review third-party software dependencies and open-source licenses in GitProtect.
GitProtect incorporates third-party software libraries to power core system functions, including data encryption, network communication, storage interface operations, and data compression.
Libraries list
The table below outlines all third-party libraries used by GitProtect.
In this article you will learn how to configure your GitProtect login with SAML.
SAML provides secure single sign-on by integrating an identity provider (IdP) with GitProtect, allowing users to authenticate with centralized credentials while ensuring controlled access and compliance.
Overview
GitProtect integration works via the SAML 2.0 protocol, meaningany platform supporting this protocol can be integrated with GitProtect.
The configuration process is straightforward and requires only the entity ID, metadata URL, reply URL, and logout URL (the names may vary depending on the naming conventions used by specific platforms). In some cases, a certificate and a private key are also required.
Configuration
Do not test the integration in the IdP panel (for example, the Azure Portal) as it will initiate login from the IdP panel.
Open your Auth0 admin dashboard, go to Dashboard > Applications > Applications, and hit Create Application button in the top-right corner of the screen.
In Create application window enter a unique, custom application name (in this example we'll be using XoperoAuth0), select Regular Web Applications option, and click Create:
In the newly created application window go to Settings tab, scroll down to the very bottom, and click Advanced Settings collapsible to expand it.
Go to the Endpoints tab and locate SAML section. Copy the SAML Metadata URL and save it for later— it will be needed for GitProtect configuration.
Scroll back to top and open the Addons tab, then toggle the SAML2 WEB APP button.
In the window that opens up open the Settings tab and enter the Application Callback URL as follows:
In the same tab, scroll down inside the code input field and uncomment 31st, 32nd and 33rd line, then edit line 32 as follows:
Once done, scroll down to the bottom of the addon window and click Enable button, then close the window to finish app configuration.
Login to your Management Service web panel, go to Settings (bottom-left corner in the left-hand side menu) and select External Identity Providers.
Click Add new provider button and fill in the details:
Name: your own custom name, i.e., Auth0
Entity ID: should be the same name you've set as application name in Auth0 (in this example it's XoperoAuth0)
Next, paste the previously copied SAML Metadata URL in the Metadata URL field.
Add certificate and password if required.
Set up a default Language and Role for users with Auth0SAML authentication permissions.
Double-check the settings and hit Save at the bottom of Add identity provider tab.
Login to , select Entra ID, and click Enterprise apps.
Click the New application button and then Create your own application.
Enter a custom name for the app and select Integrate any other application you don’t find in the gallery (Non-gallery).
Log in to your CyberArk account. Expand Apps & Widgets dropdown menu and select Web Apps.
Click Add Web Apps button in the top-right corner.
Go to Custom
Login to your Google admin console. Next, click the burger menu icon in the top-left corner of the screen and go to Apps > Web and mobile apps. Click Add app and select Add custom SAML app from the drop-down menu.
In the app details page create a custom name for your app and type it in App name field, then click Continue.
Log in to the JumpCloud Admin Portal, navigate to USER AUTHENTICATION > SSO Applications, and then click + Add New Application.
In Create New Application Integration window search for Custom Application, select it, and hit Next.
PKCS #12 file with X.509 certificate and private key (usually a .pfx file; can be password protected) must be included in IdP configuration in GitProtect. X.509 certificate file (usually a .crt file) for signature verification on IdP side must be included in application configuration defined in Okta panel.
Both files contain the same certificate. The PKCS #12 file also contains a private key to this certificate.
In Admin dashboard (in the right-top corner of the window) expand the Applications tab and select the Applications option.
Login to your OneLogin admin console and go to Applications > Applications > Add App.
Search for SAML Custom Connector (Advanced) and select the first result from the search results.
Next, enter a unique, custom name for the app in Display Name field and hit Save
To log in to GitProtect using a SAML-integrated identity provider, always start from the GitProtect panel. Do not log in from the IdP panel (for example, the Okta panel) to the application configured for GitProtect — the only exception is JumpCloud, which provides a built-in option to log in directly from its panel.
To enable an existing GitProtect user to log in via an identity provider (IdP), you must turn on the IdP login toggle for that account (⚙️ Settings > Accounts > Edit). Once an account is set to use an identity provider (IdP) for authentication, it cannot be switched back. To change the authentication method, you must delete the account and add it again.
Click Save to finish the setup. You can now log out and test your configured SAML login integration.
Confirm the configuration and click Create button.
Open the Single sign-on tab and select SAML method.
Click the Edit button in Basic SAML Configuration section to edit it.
Set up a unique Identifier (Entity ID) i.e., SAMLTestAzure
Enter the following URL in Reply URL (Assertion Consumer Service URL) section:
Go to SAML Response tab and scroll down to Script to set custom claims section. Enter the following script and press the Save button:
Head over to Permissions tab, click Add button, select all users you want to authorize to use SAML integration, and Save your settings.
Login to your Management Service web panel, go to Settings (bottom-left corner in the left-hand side menu) and select External Identity Providers.
Click Add new provider button and fill in the details:
Name: your own custom name, i.e., CyberArk
Entity ID: should be the same name you've set in Application ID in CyberArk (in this example it's XONESAMLID)
Next, paste the previously copied Metadata URL in the Metadata URL field.
Add certificate and password if required.
Set up a default Language and Role for the users with CyberArkSAML authentication permissions.
Click Save to finish the setup. You can now log out and test your configured SAML login integration.
XMS login page with CyberArk SAML integrity set up.
Next, click DOWNLOAD METADATA button under Option 1: Download IdP metadata. Upload the downloaded file to your web server and save its URL (it will be needed later for GitProtect configuration).
Click Continue and in the next window screen fill the Service provider details as follows:
Entity ID: custom, globally unique name (in this example we'll be using SAMLGOOGLE)
Start URL (optional): your GitProtectManagementServiceURL
Once done, click Continue and on the next page hit Finish.
Back on the admin console main page, click the burger menu in the top-left corner, go to Apps > Web and mobile apps, then select your newly created SAML app.
Click User access and select either On for everyone or Off for everyone based on your organization's needs.
Once done, hit Save to finish the configuration process.
Login to your XMS web panel, go to Settings (bottom-left corner in the left-hand side menu) and select External Identity Providers.
Click Add new provider button and fill in the details:
Name: your own custom name, i.e., Google
Entity ID: should be the same name you've set in Google (in this example it's SAMLGOOGLE)
Next, paste the previously copied metadata URL in the Metadata URL field.
Add certificate and password if required.
Set up a default Language and Role for the users with GoogleSAML authentication permissions.
Click Save to finish the setup. You can now log out and test your configured SAML login integration.
Check Manage Single Sign-On (SSO) checkbox and select Configure SSO with SAML option., then hit Next.
In Enter general info set a unique custom application name (in this example we'll be using XONE), type it in Display Label field, and click Save Application.
In your new application settings go to SSO tab and fill the fields as follows:
IdP Entity ID: your unique application name (in this example it's XONE)
SP Entity ID: your unique application name (in this example it's XONE)
Click the Copy Metadata URL button under JumpCloud Metadata at the top and save it for later— it will be needed for GitProtect configuration in XMS.
Scroll down, set SAMLSubject NameID to email, and for SAML Subject NameID Format select urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress from the drop down menu.
In Sign section select Assertion. The IDP URL should read:
https://sso.jumpcloud.com/saml2/xone
Correctly filled Login URL example.
In Attributes section add a new logout response by filling the fields as follows:
JumpCloud Attribute Name: select email from the drop-down menu
Click Save to update the connector and move to the User Groups tab. Select the groups/users you want to enable JumpCloud SAML authorization for GitProtect login to.
Double-check if the data you entered is correct and save your configuration.
Login to your Management Service web panel, go to Settings (bottom-left corner in the left-hand side menu) and select External Identity Providers.
Click Add new provider button and fill in the details:
Name: your own custom name, i.e., JumpCloud
Entity ID: should be the same name you've set in SSO IDP Entity ID in JumpCloud (in this example it's XONE)
Next, paste the previously copied Metadata URL in the Metadata URL field.
Add certificate and password if required.
Set up a default Language and Role for the users with JumpCloudSAML authentication permissions.
Click Save to finish the setup. You can now log out and test your configured SAML login integration.
Hit Create App Integration button and select SAML 2.0.
In General Settings enter a unique application name and move to Configure SAML section.
In Configure SAML tab set the Single sign-on URL parameter as follows:
In Audience URL type your unique application name that you've previously set in General Settings tab.
Click Show advanced settings and upload the certificate file to Signature Certificate field. Check Allow application to initiate Single Logout checkbox in the Enable Single Logout section— it's necessary.
You will now see two additional fields under Enable Single Logout— fill them as follows:
SP Issuer: your unique application name that you've previously set in General Settings tab (in this example it's MyOktaApp)
Next, go to Group Attribute Statements section and fill it as follows:
Name: xoperogroup
Starts with: XONE
Double-check if the data you've entered is correct and click Next. In the next window select I'm an Okta customer adding an internal app option, then hit Finish.
Open the created application and go to Sign On tab.
In SAML Signing Certificates section select your uploaded certificate and click Actions > View IdP metadata. Copy the URL of the opened page— it will be required later in GitProtect configuration.
Once done, go to the Assignments tab.
Assignments tab view.
Assign the application to a selected user, or group. Hit Done to finish the configuration.
Login to your Management Service web panel, go to Settings (bottom-left corner in the left-hand side menu) and select External Identity Providers.
Click Add new provider button and fill in the details:
Name: your own custom name, i.e., Okta
Entity ID: should be the same name you've set in General Settings in Okta (in this example it's MyOktaApp)
Next, paste the previously copied IdP metadata URL in the Metadata URL field.
Add the required certificate and a password to the Password Manager.
Set up a default Language and Role for the users with Okta SAML authentication permissions.
Click Save to finish the setup. You can now log out and test your configured SAML login integration.
.
Open the Configuration settings of your custom app, fill the displayed fields as follows and hit Save to save the configuration:
Audience (EntityID): a unique, custom name to identify the app on the IdP side (in this example we'll be using XOPEROSAML)
Click the SSO menu option on the left. Change SAML Signature Algorithm to SHA-256. Copy the Issuer URL value and save it for later— it will be needed for GitProtect configuration.
Save all your settings. Open Users settings in the left-hand side menu, select user(s) you want to have permission to use OneLogin for GitProtect authentication, then in the window that pops-up, check the Allow user to sign in checkbox and hit Save.
In the Applications tab, use the (+) button to add proper permissions to your custom application.
Login to your Management Service web panel, go to Settings (bottom-left corner in the left-hand side menu) and select External Identity Providers.
Click Add new provider button and fill in the details:
Name: your own custom name, i.e., OneLogin
Entity ID: should be the same name you've set in Configuration (Audience (EntityID)) in OneLogin (in this example it's XOPEROSAML)
Next, paste the previously copied Issuer URL in the Metadata URL field.
Upload the previously downloaded OneLogin .pfx certificate file and add a password to it if required.
Set up a default Language and Role for the users with OneLoginSAML authentication permissions.
Click Save to finish the setup. You can now log out and test your configured SAML login integration.
Go to User > Roles and create roles you would like to use (i.e., XONE viewers, XONE admins, etc.). Assign these roles to different users.
Next, in Applications tab, edit the SAML application. Go to Parameters and use the (+) icon to create a new parameter. In Name field enter http://schemas.xmlsoap.org/claims/Group. Check both Flags (Include in SAML assertion and Multi-value parameter) and save your settings.
In Default if no value selected section select User Roles and Semicolon Delimited input (Multi-value output) from the drop-down menu, and save the parameter.
In your GitProtect console go to ⚙️ Settings > External Identity Providers and select the IdP you want to edit.
Click the Group mapping button in the bottom left. In Claim type field enter http://schemas.xmlsoap.org/claims/Group, and in Claim value field enter the name of the role, e.g., XONE viewers. Select roles and permissions you want this group to have, then save. Repeat this step for each role/permission you want to create.
In the above address, change GitProtectManagementServiceURL to your unique Management Service URL. You can find it in your login URL— it's the first part of the address (i.e., in https://12a345bc-67de-8901-2345-f6gh78901i2j.ada.xopero.com/authorization/login the part highlighted in red is the URL you need to copy).
In the above address, change GitProtectManagementServiceURL to your unique Management Service URL. You can find it in your login URL— it's the first part of the address (i.e., in https://12a345bc-67de-8901-2345-f6gh78901i2j.ada.xopero.com/authorization/login the part highlighted in red is the URL you need to copy).
Configuration in GitProtect
Configuration in Microsoft Entra
Configuration in CyberArk
Configuration in Google
Configuration in JumpCloud
Requirements and limitations
If the PKCS #12 file is password protected, add this password to the IdP configuration in GitProtect web panel.
Configuration in Okta
Configuration in OneLogin
Using IdP authentication method
Enabling IdP login for the root admin account will prevent logging into the system when an external provider is unavailable.
In the above address, change GitProtectManagementServiceURL to your unique Management Service URL. You can find it in your login URL— it's the first part of the address (i.e., in https://12a345bc-67de-8901-2345-f6gh78901i2j.ada.xopero.com/authorization/login the part highlighted in red is the URL you need to copy).
Configuration in GitProtect
In the above address, change GitProtectManagementServiceURL to your unique Management Service URL. You can find it in your login URL— it's the first part of the address (i.e., in https://12a345bc-67de-8901-2345-f6gh78901i2j.ada.xopero.com/authorization/login the part highlighted in red is the URL you need to copy).
Configuration in GitProtect
In the above address, change GitProtectManagementServiceURL to your unique Management Service URL. You can find it in your login URL— it's the first part of the address (i.e., in https://12a345bc-67de-8901-2345-f6gh78901i2j.ada.xopero.com/authorization/login the part highlighted in red is the URL you need to copy).
Configuration in GitProtect
The Signature Algorithm by default is RSA-SHA256— leave it as is.
If you also want to login to GitProtect from the JumpCloud panel, additionally, add your XoperoONEManagementServiceURL in Login URL field.
In the above address, change GitProtectManagementServiceURL to your unique Management Service URL. You can find it in your login URL— it's the first part of the address (i.e., in https://12a345bc-67de-8901-2345-f6gh78901i2j.ada.xopero.com/authorization/login the part highlighted in red is the URL you need to copy).
Configuration in GitProtect
In the above address, change GitProtectManagementServiceURL to your unique Management Service URL. You can find it in your login URL— it's the first part of the address (i.e., in https://12a345bc-67de-8901-2345-f6gh78901i2j.ada.xopero.com/authorization/login the part highlighted in red is the URL you need to copy).
In the above address, change GitProtectManagementServiceURL to your unique Management Service URL. You can find it in your login URL— it's the first part of the address (i.e., in https://12a345bc-67de-8901-2345-f6gh78901i2j.ada.xopero.com/authorization/login the part highlighted in red is the URL you need to copy).
Configuration in GitProtect
You can read more about adding a new password to the Password Manager in KB article.
Learn more about roles in KB article.
In the above address, change GitProtectManagementServiceURL to your unique Management Service URL. You can find it in your login URL— it's the first part of the address (i.e., in https://12a345bc-67de-8901-2345-f6gh78901i2j.ada.xopero.com/authorization/login the part highlighted in red is the URL you need to copy).
To properly configure logout, the private key of the entity that receives the logout request is required. You must upload a file with the .pfx extension to GitProtect for OneLogin integration to work properly. Unfortunately, the .pfx file cannot be downloaded directly from OneLogin— you have to use your own certificate or generate it for implementation.
OneLogin offers a form where you can generate a self-signed certificate:
Manually edited login details always override those set by rules or with provisioned attributes.
Configuration in GitProtect
It's important to understand that with this integration method, you cannot initiate the login from the OneLogin application page. Instead, the login must always be triggered directly from the GitProtect side.
Group mapping
You can use group mapping if you have many users whom you want to assign different permissions to.
Each new login to GitProtect resets permissions to default— if you change permissions for a user it will only apply during the active session. Relogging the user will make permissions return to default.
Group mapping configuration must be done both in OneLogin and GitProtect— start by configuring the OneLogin side.
Learn how to register for a free GitProtect account with the cloud-based GitProtect Management Service.
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.
Automatic registration is available only for the cloud version of the management console. To register an account with the on-premises version of the software, please contact us at: .
Signing up creates a new account with a 14-day free GitProtect service trial.
Enter your business email address and click Join free.
3
Enter all required information (full name, company, phone number, and data residency location) and set a strong password for your new account. Once completed, verify that the information is correct and click the Create account button.
4
Wait for the system to create your account.
5
Once the account is created, you will be redirected to the GitProtect Management Service landing page, where you can immediately add organizations to protect and create backup plans for them.
6
The system will generate a unique GitProtect Management Service instance URL for login. For subsequent logins, use this URL or go directly to .
7
Additionally, you will receive a welcome email from GitProtect containing all important information about your account and the GitProtect system (including your unique login URL).
You can also use one of the Sign up with (...) options to register with your business account.
GitProtect uses a simple widget to guide users through the entire onboarding process, including connecting their first resource, configuring the environment, starting and monitoring their first backup, and performing a test restoration.
Your unique Management Service URL will be included in the welcome email.
An overview of Microsoft 365 backup plans in GitProtect.
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.
General information
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.
Selective backup configuration
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 Microsoft 365 groups — they appear in the users list (for example, when creating a backup plan) and can be used to filter it.
Microsoft 365 groups
If you cannot see the Groups field andthe Search by group option is unavailable in GitProtect Management Service, re-register your Microsoft 365 organization to enable these options.
How GitProtect restores repositories and metadata across Git providers for rapid disaster recovery and DevOps migrations.
GitProtect enables cross-recovery across DevOps ecosystems by letting organizations restore repositories and associated metadata between different hosting providers such as GitHub, GitLab, Bitbucket and Azure DevOps. Recovered content covers repositories and many forms of metadata, including pull requests, wikis, issues and other repository artifacts where supported by the source and target platforms.
The following tables outline which resources and metadata can be cross-restored between platforms.
Available resources
For a complete list of protected resources and metadata, refer to the Protected resources article for the relevant DevOps platform.
Different vendors provide various types of metadata, which may not be common to all providers. As a result, during the restore process, some metadata might not be available for restoration.
In the tables below, the term GitLab refers collectively to both GitLab self-managed and GitLab SaaS environments. Similarly, the term Azure DevOps refers collectively to both Azure DevOps Server and SaaS environments.
