Accessing copies of databases is an often tedious and resource intensive process. The provisioning of dozens or hundreds of database copies for DevOps, analytics, or testing is generally expensive in terms of both human hours and storage resources. Long RTOs for mission-critical databases can be a major bottleneck in business continuity when recovering from a backup or in the event of disaster. Virtual database copies provide a means for eliminating these bottlenecks and headaches.
In the below DevOps example, a user requires fifteen copies of a 10TB DB; five separate tracks each with a Dev, Test, and QA stage.
Rather than manually create fifteen full copies of the database, consuming days of time and over 150TB of storage, the Actifio user creates a single physical copy of the DB (the gold copy), and then mounts five virtual copies to each of the Dev environments. These environments are then protected with incremental backups, storing just the unique changes. Once ready for testing, virtual copies of the virtual Dev environment are created for the test environments, with the process repeating for test -> QA.
Maintaining incremental snapshots of each environment allows for near-instant access from any point in-time throughout the dev cycle. This configuration minimizes storage consumption and admin time to the greatest degree possible; consuming ~25TB of storage (assuming 10% changes from each environment protected and stored) —over 80% less storage than fifteen full copies— and created in minutes or hours rather than days or weeks.
To understand how this works, it’s helpful to take a look at how the single gold copy is created and incrementally updated from production. A more thorough dive into data capture can be found here, but at a high level, Actifio takes an initial full backup of the database, leveraging RMAN for Oracle, VSS for SQL, or LVM snaps for SAP HANA, MySQL, PostgreSQL, Maria, and others, storing data in its native format. All subsequent snapshots capture just the block level incremental changes, with the option to capture logs to roll forward to more granular points-in-time.
How Actifio Works for Databases in Linux
Once captured, Actifio maintains a bitmap of which block belongs to each point-in-time snapshot of the database, storing just the unique data across all snaps.
When a user accesses a virtual DB copy, Actifio creates a virtual disk with a set of pointers to all relevant blocks, and maps this disk to a target host. This virtual disk has a unique ID, and is independent of the stored snapshots. This allows users to maintain immutable snapshots as backups, while leveraging virtual copies of the snaps for DevOps, patch testing, or recovery. All new writes are stored as part of the virtual disk, and a protection template can be applied to this virtual copy, allowing for child of child, and on and on for many generations… copies to be generated, as in the first diagram’s example.
These virtual DB copies can either be presented directly from production snapshots or presented from a LiveClone, which allows for the DB to be masked/obfuscated, subsetted, or otherwise modified before being brought online in downstream environments.
The LiveClone process can be wrapped in automation through Workflows, which enables the inclusion of pre/post scripts as well as scheduling for fully automated daily or weekly refreshes. Using Workflows, developers can access masked multi-TB DBs on their own without requiring days of waiting for compute and storage resources and for DBAs to mask and copy the database, using any data masking tool. Dev/QA/UAT teams can access DBs from production or from any stage of the dev cycle, at any point in time, in minutes, enabling weekly or bi-weekly instead of quarterly or annual refreshes. This greatly reduces time to market and resource expenditure.
In summary, Actifio can significantly reduce storage requirements required for backup and cloning of enterprise databases like SAP HANA, Oracle, MS SQL Server, and others. This is achieved by very efficient incremental forever backup, which enables the ability to create virtual full DB copies. These immutable, read/write copies can then be masked/obfuscated, subsetted, or otherwise modified before being brought online in downstream environments.
