GitProtect 2.0.5: More Access Control and Predictability
GitProtect 2.0.5 version focuses on a more predictable recovery and access control. The console now enforces 2FA when users enter through SSO or SAML. So, access to backup and restore actions requires a second factor at the point of use. Additionally, bulk restores no longer depend on a single token’s rate limit, and Jira jobs are less brittle as well, with automatic detection of expired Personal Access Tokens.
The new version is not a redesign. It’s tightening the places that may usually creak under more pressure. Learn more about the details below.
Platform-level 2FA for SSO/SAML logins
Until now, 2FA lived mostly at the identity provider. In 2.0.5, GitProtect asks for a second factor at the console even when the user’s access is via SSO or SAML. That closes the common gap where a leaked session token or a loose IdP policy lets someone straight into backup and restore controls.
The direction is clear: make 2FA universal, then remove exceptions that linger forever. You’ll notice it most on bad days, when one extra prompt stops a destructive change from going through.
🎥 Are you a visual learner? Check out how to set up your 2FA and ensure even better security of your DevOps data – Enhancing security with 2FA
Faster multi-repo restores under API limits
Backups have long supported additional credentials to raise API request ceilings for GitHub, GitLab, Bitbucket, and Azure DevOps. GitProtect 2.0.5 version applies the same idea to restore. When you need to bring back dozens or hundreds of repositories, Git providers enforce strict rate limits – one token bottlenecks throughput.
With credential pooling at restore time, calls spread across tokens, so wall-clock drops and the job stays inside the change window. The model is straightforward: more lanes, same traffic rules, fewer jams.
Restore an Azure DevOps project with matched repos from a selected backup
GitProtect version 2.0.5 introduces a new setting – Restore repositories from this project’s backup copy.
This ensures that all repositories recovered with the project come from the exact same backup set. In practice, it means that when restoring an Azure DevOps project, only repositories included in that specific backup are restored — guaranteeing data consistency at the time of backup.
🎥 Watch on practice how with GitProtect 2.0.5 Update, you can strengthen the Git restore process – Enhancing the Git restore process with Azure DevOps and GitProtect
Jira PAT expiry awareness
Atlassian moved Personal Access Tokens to fixed lifetimes and is retrofitting older keys. The practical effect used to be predictable. A backup job would pass, pass, pass… the fail after a quiet expiry.
GitProtect 2.0.5 detects expired Jira PATs and emails the right people before it bites. You rotate the token, run a quick validation backup, and carry on. No drama and no mystery tickets.
What to track after the upgrade
Treat these as proof points, not some guessed paperwork.
| Area | Proof point | Evidence source | Pass criteria | Review cadence |
| Access control | 2FA coverage for interactive user holds at 100% | IdP (Okta, Entra, KeyCloak, etc.) 2FA report and GitProtect/Xopero auth logs | – 100% enrolled and enforced, – 0 standing exceptions | Monthly attestation |
| Recovery (Git) | Multi-repo restore drills complete without rate-limit stalls using pooled credentials | Drill transport, restore job logs, provider API telemetry | – Drill finishes inside the change window, – 0 throttle-included pauses or retries beyond baseline | Quarterly drill |
| Jira backup continuity | PAT expiry triggers an alert on job fails, rotation kicks in, and the next run succeeds | Alert emails, token inventory with expiry, subsequent backup job ID, and status | – Alert received pre-expiry, token rotated before cutoff, – next scheduled job succeeds with no errors | Rolling (track each rotation) |
The practical takeaway
GitProtect 2.0.5 hardens the one thing you can’t outsource – control over your backup console. The new version removes two operational sandtraps, meaning throttled bulk restores and expiring Jira tokens.
It doesn’t ask you to rebuild your architecture.
Turn on 2FA for everyone who clicks Restore. Stage a batched restore to measure the new ceiling, and add PAT rotation to your calendar if you haven’t already. In turn, you can expect short steps, visible gains, and fewer surprises.
Other updates include:
- improved task labels and search, which makes it easier to distinguish backup tasks from restore or storage replication tasks,
- enhanced field verification and reuse, which keeps the Jira environment organized and simplifies field management,
- clarified error message displayed during the Git repository restore process to help users identify the problem faster and resolve it more effectively,
- optimized loading in Jira Granular Restore.
We invite you to explore the latest features of GitProtect!
Try them for yourself by logging into your GitProtect account or start a free trial today!
