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.
This process may include sending invitations for users to rejoin the organization.
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.
This article outlines the classic projects restoration process.
Support for backing up projects (classic) has been removed. It is now available only for restoring previously backed-up projects (classic) — when restored, projects (classic) are automatically converted into projects v2.
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.
Data that cannot be converted remains in the backup copy. Future updates to the GitHub API may enable improved restoration capabilities, allowing additional metadata to be recovered.
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.
You can also use the Explore button to restore your data.
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 organization/name (e.g., xsupport/test), the repository will be restored with the chosen name in the specified organization. If the entered organization does not exist, the repository will be restored to the source organization.
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.
Xopero ONE allows you to select specific metadata to restore — each element can be included or excluded by toggling the switch next to it. Additionally, there is a Wiki recovery option below these settings. If your repository already exists in GitHub, you can choose to restore only the Wiki.
Support for backing up projects (classic) has been removed. It is now available only for restoring previously backed-up projects (classic) — when restored, projects (classic) are automatically converted into projects v2.
During restoration to GitHub, the Use existing projects instead of creating new ones option becomes available. When restoring projects v2, this option restores the data into the existing projects rather than creating new ones.
If the recovery destination is Azure DevOps, the Map organizations section will be replaced by Target organization and Target project settings.
Closed or merged pull requests are recovered as closed issues.
Restoring never overwrites existing repositories in the organization — if you do not choose a repository name, or if you enter the name of a repository that already exists in your organization, the restore will fail. To complete the restoration successfully, you must choose a unique repository name or select the Add suffix to repo name option so the restored repository keeps its original name with an automatically generated suffix.
To restore a repository to a local device, you must have a Git client installed on that device.
You can restore only the repository (without metadata) when restoring data to local resources.
To configure the PATH variable, 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 a repository already exists in the selected folder, you can choose to overwrite the existing data.
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.
You can also use the Explore button to restore your data.
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.
Support for backing up projects (classic) has been removed. It is now available only for restoring previously backed-up projects (classic) — when restored, projects (classic) are automatically converted into projects v2.
During restoration to GitHub, the Use existing projects instead of creating new ones option becomes available. When restoring projects v2, this option restores the data into the existing projects rather than creating new ones.
If the recovery destination is Azure DevOps, the Map organizations section will be replaced by Target organization and Target project settings.
Closed or merged pull requests are recovered as closed issues.
Restoring never overwrites existing repositories in the organization — if you do not choose a repository name, or if you enter the name of a repository that already exists in your organization, the restore will fail. To complete the restoration successfully, you must choose a unique repository name or select the Add suffix to repo name option so the restored repository keeps its original name with an automatically generated suffix.
To restore a repository to a local device, you must have a Git client installed on that device.
You can restore only the repository (without metadata) when restoring data to local resources.
To configure the PATH variable, 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 a repository already exists in the selected folder, you can choose to overwrite the existing data.
