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:

1. 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.

2. Select projects: using checkboxes, you can choose specific projects to protect.

3. Select repositories: using checkboxes, you can choose specific repositories to protect.

1. Exclude repositories: using checkboxes, you can exclude specific repositories, allowing the plan to cover all other repositories by default.

2. 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.

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, owners, creation dates, branches, or specific patterns, offering granular control over the backup scope and ensuring that only relevant repositories and projects are processed.

Selection rules and rule patterns

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.

Azure DevOps & Bitbucket

1. 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:

   1. * matches zero or more characters

   2. ? matches exactly one character

2. Project name: protects all repositories within the specified project.

GitHub

1. 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:

   1. * matches zero or more characters

   2. ? matches exactly one character

2. 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.

GitLab

1. 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:

   1. * matches zero or more characters

   2. ? matches exactly one character

2. 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.

3. Group path: protects all repositories within the specified group or subgroup path.

Selection rule examples

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.

Regular expression patterns (regex)

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.

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.

Restoring LFS metadata

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.

Useful links and items

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.

Recovery process for Azure DevOps & DevOps Server

The following steps demonstrate how to quickly recover your Azure DevOps project wiki using GitProtect Management Service.

Useful links and items

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.