Day 2 and beyond: the life of a SQL Server volume group on Everpure Cloud Azure Native
Provisioning is the easy part. You create a Volume Group, mount it to your Azure VM through the Everpure Cloud VM Extension, and SQL Server comes up on its new storage. The interesting questions come later. To show them, we’ll follow one example workload through its first few weeks. The scenario is made up and very simple, but the operations are real.
Week one: “Can I get a copy of prod?”
Our SQL Server VM has one Volume Group with three volumes: data, logs and tempdb. The app team wants to test a schema change against real data. Because whole Volume Groups can now be cloned, the entire database gets copied in one step, and the clone can be mounted straight to a separate test VM. A developer who only needs the data volume can clone just that one instead. Two things to know: clones stay in the same Storage Pool, so plan VNet, zone and region placement first, and a new clone takes a few minutes to become available.
Week two: “We’re running out of space.”
The data volume is filling up faster than planned. Growing it is a quick edit of provisioned capacity in the Azure portal. Capacity can only go up, though, so size with intent, and remember to extend the disk and filesystem inside the guest OS afterwards. If the real complaint is speed rather than space, that’s a Volume Group performance change, because capacity and performance are separate in Everpure Cloud Azure Native.
Week three: “Someone deleted the wrong thing.”
During cleanup, someone removes the wrong volume. This is where the biggest change pays off: deletion now has two steps. A soft-deleted volume is kept as inactive for 3 days, so you filter the volume list for Status = Inactive and restore it. Whole Volume Groups work the same way, with their dependent resources coming back on restore, and Purge removes anything permanently once you’re sure. Still, unmount and check dependencies before deleting anything. The 3-day window is for genuine mistakes, not for skipping checks.
Where snapshots fit in
Clones copy what’s there now. Volume Group snapshots capture every volume at the same point in time, and protection policies keep taking them on a schedule. Either way, grouping volumes by application means every clone, snapshot and restore treats the database as one unit (in a storage consistent way).
For step-by-step instructions, see the Volume and Volume Group Lifecycle documentation.
