Cloudback Only Counts If the Restore Hurts

Picture the drill most teams never schedule. Org admin deletes the wrong repository. Ransomware eats the SaaS tenancy. A migration script half-succeeds. Someone opens the backup product, clicks Restore, and waits for the feeling of safety.

What comes back—if you are on Cloudback and the archive is good—is real: a bare Git history with LFS, issues and sub-issues, PR reviews, Projects v2, release assets, wiki, collaborators, webhook configs. What does not come back is equally documented and almost never mentioned in the buying meeting: encrypted Actions secrets and environment variable values (GitHub’s API will not hand them over), webhook secret tokens (you re-enter them), deploy keys and autolinks (not implemented yet), fork-sourced PRs and commit-less PRs that may archive but refuse to recreate, Discussion categories that cannot be restored. Linear wants an empty target workspace and a separate write-scoped OAuth hop. GitHub restore needs a second app with write permission; the daily backup app stays read-oriented on purpose.

If that paragraph feels like a vendor dunking on itself: it is Cloudback’s own backup-contents and restore docs talking. The useful product is not “we backup GitHub.” It is “we backup what the APIs allow, and we make restore a ceremony you can rehearse.” Everything else is theater with a status badge.

Clones are not custody

A git clone on three laptops is not a disaster-recovery policy. It is a comfort ritual. Commits survive. The living project—review threads, board state, release binaries, Linear issue graphs—does not live in those clones. Platform availability is also not custody: if the damage is inside the forge (bad admin, ransomware on the same cloud objects you call “backup”), sameness of tenancy is the vulnerability.

Cloudback’s bet, operated by MYRTLELABS S.A.S. (site cloudback.it), is scheduled AES-256 ZIP archives across GitHub, GitLab, Azure DevOps, and Linear, optional customer-owned storage, and self-service restore including GitHub↔GitLab conversion. Marketing claims 1.7k+ customers, 14k+ repos, 4M+ backups—vendor scale signals, not audited census. Bitbucket stays roadmap. That is enough company context. The fight is elsewhere.

The restore is the product. The ZIP is inventory.

Buy Cloudback for the awkward parts:

• Separate restore authority. On GitHub, install the restore app only when you restore; uninstall after. That friction is a feature. If write access lived on the nightly job forever, your “backup” would also be a high-privilege attack surface.
• RSA Lockbox as a paste tax. Default mode: Cloudback holds archive passwords. RSA Lockbox (customer-managed; announced on the product blog March 2026) encrypts each password to your RSA public key via RSA-OAEP/SHA-256. Restore or download means pasting the private key into a dialog; Cloudback decrypts in memory and discards it. Customer-Held Lockbox parks the .lockbox sidecar next to the ZIP in your bucket. Lose the key—or delete the sidecar—and those archives are dead weight. External KMS / password API modes are still planned, not shipping. Compliance teams love the CMEK story; ops teams discover they now own a restore-time human bottleneck. Good. Bottlenecks you know beat keys nobody can find at 2 a.m.
• Linear’s empty-room rule. Workspace restore rebuilds in dependency order (files → teams → labels → projects → cycles → initiatives → issues → comments → relations → documents/views/templates). The target must be empty. That is not UX cruelty—it is how you avoid a Frankenstein graph.
• GitHub↔GitLab cross-restore. Documented entity matrix: mirror-push for repos; issues, labels, milestones, boards; partial comment fidelity on PR/MR; GitLab-only fields (weight, time tracking) shoved into GitHub issue bodies. Useful for migration and forge outage. Not a universal converter for Azure DevOps or Linear. Do not sell it internally as one.

Default schedule is daily; retention defaults to 30 days and can stretch toward the 30–360 day band Cloudback markets. Deduplication skips unchanged archives. On-demand runs exist for “we are about to do something stupid.” Alerts can hit email, Slack, Discord, Teams, or custom webhooks. Terraform provider, Operations API, and an MCP server (April 2026 blog) exist for people who refuse click-ops. None of that matters if nobody has ever clicked Restore into a disposable org.

Secrets, retention, and the procurement argument you should actually have

Security and platform eng will argue past each other unless you force a concrete agenda:

1. Secret continuum. Cloudback cannot resurrect Actions secrets. Your runbook must say where the real secret store lives (vault, cloud KMS, sealed config) and who rewires webhooks after restore. Buying backup does not retire secrets management. Anyone who claims otherwise is lying with a feature matrix.
2. Custody. Cloudback-managed regions: US, EU, UK, Sydney, Singapore. Or BYO: S3 (including Glacier and Object Lock for WORM), Azure Blob, GCS, OneDrive, Wasabi, Alibaba OSS, OpenStack Swift, composite multi-destination writes. “We don’t store your data” on the homepage is marketing for BYOS—still true that Cloudback can hold managed copies if you let it. Pick one story and audit it.
3. Immutability vs. convenience. Object Lock plus customer-held keys is the anti-ransomware posture. It is also how you lock yourself out. Decide retention windows before you enable WORM on the bucket that holds the only copy of the Lockbox sidecars.
4. Evidence. Site, Marketplace, and terms claim SOC 2 Type II. Audit log with 60+ event types and 180-day retention shows up in pricing/security copy. Vanta integration ships; Drata is still “coming soon” on the homepage—do not put Drata in the RFP as live. Support SLAs on the marketing site (vendor-reported): initial response under 4h in 95% of cases, average resolution under 12h in 95%, first-contact resolution above 87%. Ask for the current SOC 2 report under NDA if your auditor is not impressed by badges.

This is the procurement fight: not “is backup important,” but “who holds keys, where do archives sit, what is explicitly unrestorable, and when do we rehearse.”

Unit math without the brochure trance

Cloudback prices units, not seats. Public pricing / docs:

| Plan | Units | Monthly fixed | | --- | --- | --- | | Free | 1 per connected account (100 MB) | $0 | | Basic | 10 | $10 | | Team | 100 | $75 | | Enterprise | 1,000 | $500 |

Annual / multi-year discounts exist. Pay-as-you-go overage: $1.00 / $0.75 / $0.50 per extra unit on Basic / Team / Enterprise. Every paid plan includes all features—no enterprise feature wall. Scale docs stop around 10,000 repos before “talk to sales.”

Consumption: 1 unit per GitHub or Azure DevOps repo, 1 per GitLab project. Linear is the foot-gun: 2 units per member for seats 1–5, 4 for 6–25, 6 beyond 25 (minimum 2). Cloudback’s own example: 10-member workspace = 30 units (5×2 + 5×4). Mix platforms from one pool. Bill via Paddle, GitHub Marketplace, Azure Marketplace, Coupa, or invoice. Free tier is a smoke test, not a policy.

Rewind (BackHub lineage) and GitProtect will show up in every 2025–2026 “best GitHub backup” roundup. Rewind often wins if you already standardize multi-SaaS backup there. GitProtect often wins on-prem / Bitbucket / heavier compliance packaging. Cloudback’s honest edges are Linear in the same dashboard, aggressive BYOS breadth, RSA Lockbox, unit pricing with unlocked features, and GitHub↔GitLab restore. Do not pick from blog comparison tables; pick from a restore drill and an invoice against your repo + Linear headcount.

Half-page restore runbook (rehearse this, or you do not have backups)

Treat Cloudback as restore theater until someone has run the following into a disposable org—not a slide, not a green check.

0. Pre-flight (same day, before anyone clicks Restore). Confirm which archive you will use (date, destination bucket, managed vs BYOS). Confirm who holds the RSA Lockbox private key and where the .lockbox sidecar lives if you are on Customer-Held. Confirm a second GitHub restore app is installable with write scope, and that Linear’s target workspace is empty (or you will create one that is). Name the person who will re-enter secrets; that person must be online for the drill.

1. RSA Lockbox paste tax. Install / open restore. When the dialog asks for the private key, paste it. Cloudback decrypts the archive password in memory and discards the key. Time how long key retrieval took. If retrieval meant paging three people or opening a password manager nobody owns, that is the real RTO—not ZIP download speed. If the key is missing or the sidecar was deleted under Object Lock confusion, stop: those archives are dead weight. Document the failure; do not improvise a “we’ll decrypt later.”

2. GitHub (or GitLab / Azure DevOps) restore into a clean target. Restore the chosen repos. Expect history, issues, PR reviews, Projects, release assets, wiki, collaborators, webhook configs. Expect blanks where the API never gave values: Actions secrets and environment variable values, webhook secret tokens, plus anything still unimplemented (deploy keys, autolinks) or known-fragile (some fork-sourced / commit-less PRs, Discussion categories). Write a literal checklist of every blank field the UI leaves for you.

3. Secret re-entry (the part the dashboard never greens). From your real secret store (vault / KMS / sealed config—not Cloudback), re-create Actions secrets and environment values. Re-enter webhook tokens and re-verify deliveries. Re-attach anything the restore left as config-without-credential. Do not mark the drill done until one CI workflow and one inbound webhook have succeeded against the restored repos.

4. Linear empty-workspace path (if Linear is in scope). Point restore at an empty workspace. Accept the dependency order (files → teams → labels → projects → cycles → initiatives → issues → comments → relations → documents/views/templates). If the target is not empty, abort and use a fresh workspace—do not “merge” into a living graph. Complete the write-scoped OAuth hop. Spot-check one initiative → issue → comment → relation chain.

5. Tear-down and paper. Uninstall the GitHub restore app. Rotate or revoke any temporary credentials used in the drill. File one page: archive identity, Lockbox retrieval time, list of secrets re-entered by hand, Linear empty-room confirmation, what still failed. Price units against that headcount/repo mix only after this page exists.

Cloudback will not invent API access GitHub refuses, forgive a lost private key, or make Bitbucket real before the roadmap graduates. It will turn compressed nightly hope into a rehearsable machine—Marketplace install, BYO bucket, Lockbox, bulk restore, optional Terraform—if this runbook has a date on it. Without that date, you bought inventory, not custody.