Single repository recovery
This article explains how to restore a single repository to a Git service or localhost.
Recovery process
Get into the restore view using one of the following methods:
Method 1:
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.
Method 2:
Open the Storages tab, and click the browse storage button in the storage action menu.
Click the Device section — you will then see all repositories that have been backed up and sent to the selected storage. Select one of the available repositories to proceed.
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.
By default, the system restores the entire repository (including all files and source code), while the repository metadata is optional. 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.
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.
A. Restore to a Git organization
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:
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. If you enter the name of a repository that already exists in your organization, the restore will fail.
Restoring will never overwrite existing repositories in the organization. If you enter an existing repository name, the restored repository will keep its original name with an automatically generated suffix.
B. Restore to a device
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.
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.
If a repository already exists in the selected folder, you can choose to overwrite the existing data.
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.
Closed or merged pull requests are recovered as closed issues.
Restoration time
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.
Useful links and items
Last updated