Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
This article explains how to add a GitHub organization to Xopero ONE.
Log in to XMS, open the DevOps tab on the left side of the window, and select GitHub from the list.
Click the Connect button under GitHub.
, 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.
Grant Xopero ONE access to the specified resources (when prompted).
Your GitHub organization has now been successfully added to Xopero ONE. Click Custom policy to adjust your backup policy settings, or click Run backup to execute the backup immediately using the current policy configuration.
Log in to XMS, open the DevOps tab on the left side of the window, and select GitHub from the list.
Click the advanced mode link under GitHub and GitHub Enterprise Server tiles.
Log in to XMS, open the DevOps tab on the left side of the window, and select GitHub from the list.
Click the advanced mode link under GitHub and GitHub Enterprise Server tiles.
When adding an organization, you may be prompted to grant additional permissions to the Xopero ONE application— make sure your browser allows Xopero 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.
Set your authentication method.
In Authentication, select GitHub.
For Connect using, choose GitHub App.
Choose whether Xopero should automatically add new repositories to your backup.
Configure your repository sync and default worker. Specify hours for synchronization, or set a time interval for automatic updates.
Click Proceed to complete adding your GitHub organization and grant Xopero ONE 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.
Select repositories you want to protect and click Install & Authorize to proceed.
Your GitHub organization has now been successfully added to Xopero ONE. 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 Xopero should automatically add new repositories to your backup.
Configure your repository sync and default worker. Specify hours for synchronization, or set a time interval for automatic updates.
Click Proceed to complete adding your GitHub organization and grant Xopero ONE access to the specified resources.
Learn more about the backup process for GitHub.
Xopero ONE is designed to protect DevOps ecosystems, including GitHub.
To ensure your entire GitHub 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 GitHub 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 GitHub account while keeping a copy in storage, which helps bypass GitHub limits.
Incremental and differential backups help save storage space. In
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).
Xopero ONE is a multi-storage system that allows you to store your data:
Learn about GitHub API rate limits.
Rate limits are enforced for security reasons to prevent a large number of requests from blocking or destabilizing the application.
GitHub limits the number of API requests that you can make within a specific time period to prevent abuse, protect against denial-of-service conditions, and maintain platform stability. Primary rate limit thresholds are determined by your authentication method, though specific resource-intensive endpoints—such as search APIs—enforce stricter request quotas.
You can learn more about GitHub API rate limits in the official GitHub documentation.
This article explains how to restore a single repository to a Git service or localhost.
Get into the restore view using the following method:
Open the GitHub tab (DevOps > GitHub), then click the Restore button next to the organization whose backup you want to restore.
Search for the repository you want to restore, and click the Restore button in the action menu of that repository.
Next, select the backup plan from which you want to restore data. Click View available plans and choose one of the plans from the list.
Choose the backup version from all the backups that have already been performed — select the desired date and click the Restore button.
Select the destination for the restore process. You can choose one of the assigned organizations from any Git service or any device. After selecting the repository and the metadata you want to include, click the Restore selected or Restore all button to proceed.
In the next aside, click Edit next to Data to restore if you need to adjust it.
Next, select the destination where you want to restore the data.
In Map organizations section, select the target organization to which the repository will be restored.
In Restore settings you can set a custom name for the repository that will be created during the restore process and limit the internet bandwidth.
You can enter a new repository name in one of the following formats:
In Device used to restore the data section, choose the device that will be responsible for performing the restoration.
After defining all parameters, click the Start now button to begin the restore process. When the process is complete, a new repository will be created in your organization account.
Extensive testing and analysis have shown that restoring repositories with many issues and pull requests significantly prolongs the restoration process. This delay is caused by limitations within GitHub’s infrastructure and the API used for repository restoration.
To speed up the repository access, it is recommended to exclude issues and pull requests during the initial restore. Once the repository is restored, you can perform a subsequent restore—including issues and pull requests—under a different repository name. This approach ensures quick access while still allowing full restoration of repository content.
If you enter only the repository name (e.g., test) and the source organization is registered in Xopero ONE, the repository will be restored there. If the organization is not registered, the repository will be restored to your account.
Select the destination device.
Make sure the device where you want to restore data has the Xopero ONE agent installed and 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, set it manually to the path of the git.exe file: C:\Program Files\Git\bin\git.exe
Select the directory where you want the data to be restored.
In this article, you will learn how to restore multiple repositories to a Git service or localhost.
Get into the restore view using the following method:
Open the GitHub tab (DevOps > GitHub), then click the Restore button next to the organization whose backup you want to restore.
Select the repositories you want to restore and click the Restore selected button in the top menu.
By clicking an individual repository, an aside will appear where you can select a backup plan and a backup version to restore. Click Select under your chosen backup copies to continue.
Select the destination for the restore process. You can choose one of the assigned organizations from any Git service or any device.
Next, select the destination where you want to restore the data.
In Map organizations section, select the target organizations where the repositories will be restored.
In the Restore settings, you can configure the following options:
When you toggle Restoring repos with custom name switch, a window will appear allowing you to rename one or more repositories.
In Device used to restore the data section, choose the device that will be responsible for performing the restoration.
After defining all parameters, click the Start now button to begin the restore process. When the process is complete, new repositories will be created in your organization account.
Extensive testing and analysis have shown that restoring repositories with many issues and pull requests significantly prolongs the restoration process. This delay is caused by limitations within GitHub’s infrastructure and the API used for repository restoration.
To speed up the repository access, it is recommended to exclude issues and pull requests during the initial restore. Once the repository is restored, you can perform a subsequent restore—including issues and pull requests—under a different repository name. This approach ensures quick access while still allowing full restoration of repository content.
Select the destination device.
Make sure the device where you want to restore data has the Xopero ONE agent installed and 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, set it manually to the path of the git.exe file: C:\Program Files\Git\bin\git.exe
Select the directory where you want the data to be restored.
Additionally, in the Restore settings, you can limit bandwidth usage during the recovery process.
Required permissions for integrating GitHub with Xopero ONE and protecting its resources.
Connecting GitHub with Xopero ONE 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.
Integrating GitHub with Xopero ONE 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 Xopero ONE.
To ensure seamless integration and correct operation, the Xopero ONE OAuth application* requires the following permissions:
*The Xopero ONE OAuth application for GitHub is called GitProtect.
Xopero ONE GitHub App* installation requires the following permissions:
*The Xopero ONE GitHub App is called GitProtect.
Personal access tokens are generated in GitHub account settings under Settings > Developer settings > Personal access tokens and can be assigned different permissions.
Registering the Xopero ONE 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:
read:public_key (access keys)
Owner
Default
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.
This article outlines the classic projects restoration process.
According to the official GitHub page, projects (classic) are being discontinued.
You can only create a new project (classic) for an organization, repository, or user that already has at least one project (classic). If you are unable to create a project (classic), create a project v2 instead.
When repositories containing projects (classic) are restored to an organization that does not support this feature, direct restoration in the original format is not possible. Instead, the system converts the restoration from projects (classic) to projects v2.
Key considerations include:
The conversion retains elements such as the project name, issue cards, and pull request cards.
Certain metadata, such as columns or notes, cannot be restored due to GitHub API limitations.
The system flags these conversions in the restoration summary for transparency.
Overview of protected GitHub resources, including repositories, wikis, and metadata secured by backup.
GitHub protected resources define which repositories and data Xopero ONE can access, secure, and restore.
The following list includes all GitHub resources covered by backup.
Learn more about GitHub Apps and their features.
GitHub can be integrated with Xopero ONE 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 Xopero ONE 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 Xopero ONE include enhanced security, better rate limit handling, and more reliable repository management.
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.
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 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.
Xopero ONE can use up to 10 additional apps to increase request limit and reduce throttling impact.
With the upcoming release of Xopero ONE (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.
You will get an email from GitHub containing information about the application and the organization or account requesting elevated access. To grant Xopero ONE the required permissions, click the Review permission request to accept or reject this change link.
After clicking the link, you will be redirected to GitHub, where you can review the requested permissions and approve them.
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.
Once the requested permissions are accepted, your environment will be ready for full backup coverage of issue type data when the next Xopero ONE release goes live.
This article contains information on how to set up a GitHub backup plan.
Login to XMS, open the Plans > Backup tab and click the Add plan button in the top bar.
Select GitHub from the list.
Select (or add) the GitHub environment you want to include in the backup process, and choose the repositories to back up.
Specify a name for the backup plan.
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.
Select one of the locations assigned to your Xopero ONE instance as storage.
Customize the scheduler and specify how long your data should be retained. If needed, adjust the advanced settings to suit your needs.
If necessary, adjust the advanced settings such as encryption, error handling, or bandwidth limits to fit your requirements.
Double-check your data and click Save to create the backup plan.
Learn about recovering GitHub teams in Xopero ONE.
When restoring repositories, one type of metadata that can be restored is teams. Xopero ONE ensures that teams and their associated users are reinstated.
Before starting the restoration process, a prompt will inform you of this action—accepting the prompt will restore teams and send invitations as needed. Canceling the prompt will exclude teams from the restoration process.
The maximum number of external collaborators that can be restored for a single repository in one operation is limited to 50. This restriction is due to GitHub API limitations, which define how many collaborators can be processed in a single batch. This constraint is independent of Xopero ONE and cannot be bypassed by the backup solution.
