BorgBackup + Restic → Druva
BorgBackup + Restic ↔ Druva: integration to migration path.
Backup is load-bearing — the day you need a restore is the worst day to discover a gap, so we never flip a switch. Borg and Restic deploy alongside Druva Phoenix first, every server is backed up by both tools under dual-write, and only then does OSS take over the server tier — wave by wave, each step reversible in minutes, with no forced re-credentialing and no flag day.
The honest end state is two-tier, not a full Druva retirement: OSS owns servers and VMs, while Druva inSync keeps your endpoints and Druva's connectors keep M365, Salesforce, Workday and the rest. We say so up front, because the rest only matters if you can trust it.
The idea
Run both, prove the restore, then retire one tier.
The topology that makes this zero-downtime is a hard partition by workload class with a dual-write overlap. Borg backs up your Unix servers over SSH to a hardened, append-only backup host; Restic backs up everything cross-platform to an S3-compatible bucket with Object Lock Compliance. Both run on schedules matching Druva's cadence while Druva Phoenix stays the source of truth — so for months the server tier is protected twice. Only after a production-scale restore drill passes per tier do we flip OSS to primary, soak for 30 days, then uninstall the Phoenix agent host by host. Druva inSync and the SaaS-app connectors never move.
The phases
Seven steps. Each one reversible.
Baseline & inventory
We read out every Druva Phoenix server backup-set via the Druva API and cross-reference your CMDB: OS, workload class, RPO/RTO, retention, change rate, last good restore. Legal-hold and compliance-archive workloads are flagged out of scope so they stay on Druva.
Stand up Borg+Restic; lab restore drill
Hardened backup host (SSH key-only, append-only) and an S3 bucket with Object Lock Compliance go live. One canary server is backed up with both tools and restored byte-for-byte to a lab VM. Druva is untouched.
Dual-write a cross-section
At least 10% of the fleet (or 20 servers) is backed up by both Druva Phoenix and Borg/Restic on matching schedules. We run a restore drill per tier — database, filesystem, VM image — with workload-owner sign-off. Druva stays the source of truth.
Flip primary per workload wave
We flip OSS to primary in waves, lowest blast radius first: dev, staging, internal prod, customer-facing prod, then databases and hypervisors. Druva keeps running as secondary for a 30-day soak per host.
Long-tail + harden immutability
Remaining workloads onboard. GFS retention lands via borg prune / restic forget, Object Lock windows are set per tier, and Tier 0/1 packs cross-region replicate for the off-site leg. A compliance-evidence drill restores the oldest retained backup.
Retire Druva Phoenix per host
The Phoenix agent is uninstalled in waves after a final retention check and compliance drill per regulated host. The Phoenix server-backup SKU is removed at the contract anniversary. inSync and the SaaS-app connectors remain on full contract.
Final closure (server tier)
A contract amendment — not a termination — removes the Phoenix server SKU while inSync and SaaS-app SKUs are retained. OSS is now the only server-backup posture; documentation, audit evidence, and the DR runbook reflect it.
Feature parity
Where OSS matches Druva — and where it honestly does not.
| Capability | BorgBackup + Restic | Druva | Parity |
|---|---|---|---|
| Server / VM / FS / DB backup | Borg repos over SSH; Restic snapshots to S3 | Druva Phoenix server backup | At parity |
| Endpoint CDP | None at fleet scale — user-installed agent, no central console | Druva inSync endpoint CDP, bandwidth- and VPN-aware, block-level | SaaS only |
| SaaS-app backup (M365 / Salesforce) | None — no MS Graph or Salesforce Bulk API client | Druva connectors for M365, GWS, Salesforce, Workday, ServiceNow | SaaS only |
| Deduplication | Borg Buzhash CDC (tunable chunker, 4–10x); Restic Rabin CDC | Druva global cross-tenant dedup (10–20x claimed) | Partial |
| Encryption | Borg repokey-blake2 (AES-256 + BLAKE2b MAC); Restic AES-256 + Poly1305 | Druva AES-256, vendor-held DEK; KMIP is a paid SKU | At parity |
| Immutability (Object Lock / WORM) | Borg append-only repos + S3 Object Lock Compliance on the Restic backend | Druva immutable storage tier (vendor-managed lock) | At parity |
| Ransomware anomaly detection | None first-party — roll your own from restic stats / borg info deltas into SIEM | Druva DefenseLine (unusual-encryption-rate flagging) | SaaS only |
| E-discovery / governance archive | Restore-then-search; no full-text index | Druva governance archive, full-text e-discovery, chain-of-custody | SaaS only |
| Retention / GFS | borg prune --keep-* / restic forget --keep-* (hourly to yearly) | Druva policy-engine GFS retention | At parity |
| Restore testing | borg check --verify-data / restic check --read-data-subset; operator-run drills | Druva console-driven verification (lighter-touch) | At parity |
| Restore granularity | File-level borg extract / restic restore --include | File-level plus Druva search index | Partial |
| Deployment model | Self-hosted backup host + S3 / MinIO / Wasabi / B2 bucket | Druva fully-managed SaaS | SaaS only |
| Cost model | Pay-for-bytes object storage + backup-host compute | Per-protected-source + per-GB SKU | Partial |
| Compliance (SEC 17a-4 / HIPAA / SOC 2) | S3 Object Lock Compliance meets SEC 17a-4(f); audit boundary now includes self-hosted infra | Druva vendor-attested governance + audit export | Partial |
What we're honest about
The gaps no OSS tool closes.
Endpoint CDP stays on Druva — this is non-negotiable
Borg and Restic on laptops means a user-installed agent, repo reachability, and no central console. They do not scale to thousands of endpoints with bandwidth-aware, VPN-aware, block-level continuous backup. That is inSync's job, and inSync keeps it. We do not attempt to replace it.
SaaS-app backup has no OSS answer — the loudest gap
Neither tool speaks MS Graph, the Salesforce Bulk API, Workday RaaS, or the ServiceNow Table API. M365, Google Workspace, Salesforce, Workday, and ServiceNow backup stays with Druva's connectors. We flag this in every conversation rather than pretend an OSS replacement exists.
No first-party anomaly detection or e-discovery
Druva DefenseLine flags unusual encryption rates before they reach the immutable tier; Druva's governance archive offers full-text search with chain-of-custody. The OSS path is roll-your-own from restic stats and borg info deltas into your SIEM, and restore-then-search for legal review — a project, not a checkbox. If you rely on these, keep Druva for those workloads.
Self-hosting means you own uptime, keys, and two control planes
Once Phoenix is gone on the server tier, your RTO equals your runbook plus on-call response — there is no vendor SLA backstop. You also run two consoles: Druva for endpoint and SaaS, OSS for servers. We mitigate with a hardened backup host, a paper break-glass passphrase copy, and one aggregated SIEM dashboard — managed, not just installed.
Why this beats a flag day
Reversible per phase. Druva stays until OSS earns it.
Every server-tier phase rolls back in under 15 minutes while the Druva agent is still installed — re-declare Druva primary and its retention is restored, no rebuild required. Nothing decommissions Druva Phoenix until OSS has run as primary for a 30-day soak with a passing restore drill and workload-owner sign-off, and the Phoenix SKU only leaves the contract at the anniversary, after that soak. A flag-day cutover gives you neither the soak nor the rollback; this gives you both.
See which of your workloads migrate cleanly — and which stay on Druva.
A 30-minute call with a senior backup engineer. We separate your server tier from your endpoint and SaaS-app backup, size the Borg+Restic storage honestly, and tell you exactly where Druva inSync and the connectors must stay — before you commit to anything.
Map my migration →