Single project recovery
This article explains the project backup recovery process for Azure DevOps and Azure DevOps Server.
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.
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.
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.
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 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).
Select the available metadata to restore and click Restore selected or Restore all to proceed.
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.
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.
In the Restore to section, you can change the previously selected recovery destination if needed.
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).
Configure the recovery destination settings, depending on where the backup will be restored.
Restore to a Git organization:
Select the target organization (where applicable).
If you are restoring your project to Azure DevOps or DevOps Server organization:
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 repositories from this project's copy 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.
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 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).
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.
Adjust the bandwidth settings.
Check which worker is set as the default for recovery and change it if necessary.
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.
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.
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.
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.
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.
Useful links and items
GitProtect workerCross-recovery for DevOps organizationsLFS recovery for DevOps organizationsWiki recovery for DevOps organizationsThrottling preventionLast updated