Hi
We are trying to use Commvault for very large SQL Server VM (about 50 TB) running on Nutanix. The main requirement is to recover quickly after a security incident by restoring to a clean pre‑incident point while keeping RTO extremely low, which is hard when full database re‑hydration is required.
Today, SQL point‑in‑time restores in Commvault appear to work in the traditional way: the database is rebuilt by streaming data from backup (full/diff) and then applying logs, writing out the entire MDF/NDF/LDF set again. For a 50 TB database, fully moving data from backup media back to production storage is not realistic for tight RTO objectives.
What we would like is a workflow that:
- Treats the SQL data disks (on Nutanix) more like snap‑based clones instead of full copy restores.
- Lets us promote or mount a snapshot at the individual disk/volume level, not only at whole‑VM level.
- Then uses Commvault only to apply transaction logs on top of that snapped data for point‑in‑time recovery, instead of re‑hydrating the entire database from backup.
In other words, we are asking for a Commvault feature (or clear guidance if it already exists) that combines:
1. Fast, disk‑level or volume‑level recovery (from hardware or hypervisor snapshots, not just VM‑level), suitable for huge SQL data files.
2. A “logs‑only” PITR mode that assumes the data files come from a promoted snapshot, so Commvault just orchestrates log replay and catalog consistency.
Some other vendors offer workflows closer to this “snap‑clone + logs” model for very large SQL databases, and we would like to see an equivalent capability (or best‑practice pattern) in Commvault for environments with tens of terabytes per database.
Could Commvault please confirm:
- Whether a disk‑level snap‑clone with Nutanix + logs‑only PITR flow is currently possible (and how to configure it end‑to‑end), or
- If not, whether this is on the roadmap as an enhancement for large SQL workloads where full re‑hydration is not feasible?
