Backing up a mission-critical database is a different problem from backing up a file server. Speed and storage efficiency matter, but consistency matters more, because a database image captured mid-transaction can restore into a state that needs repair before it will open. Catalogic vStor, the software-defined backup appliance behind DPX, handles Oracle and SQL Server protection two ways: application-consistent backups driven by DPX, or native backups managed by the DBA with vStor underneath them.
Either route gets the same storage behaviour, including compression, snapshots, immutability, and replication.
What is DPX vStor?
vStor is a scalable, software-defined backup appliance built on ZFS, and it serves as the primary backup destination for Catalogic DPX. It deploys on a physical machine or as a virtual appliance under VMware or Hyper-V, and version 4.16 is supported storage for Block backup, agentless backup, and S3 object storage backups.
Its role in a database context is twofold. It is where the backup lands, and it is what makes recovery fast, because snapshots held on the appliance can be mounted rather than copied back.
Two Ways to Protect a Database with vStor
Most backup products pick one model and make you live with it. vStor supports both, which matters more than it sounds, because in most organizations the database team and the backup team have different opinions about who should own recovery.
Application-Consistent Backups Through DPX
DPX provides application-aware backup and recovery for Oracle Database and Microsoft SQL Server, among other workloads. For Oracle block backup, DPX places tablespaces into backup mode and snapshots the filesystems underneath them, so what lands on vStor is a coherent point-in-time image rather than a copy taken while writes were in flight. A restore from that backup opens without additional repair work.
This is the route to take when the backup team owns recovery. Jobs are scheduled and monitored alongside everything else in the environment, and the DBA does not have to be on the call to bring a database back.
Native Database Backups on vStor
Some DBAs would rather keep backups under their own control, using Oracle RMAN or the native SQL Server backup utilities, and there are good reasons for that. The recovery procedure stays in the hands of the people who run it, and it matches what is documented in the runbook they already have.
That workflow continues to work with vStor as the storage target. The dumps land on the appliance and pick up its compression, snapshotting, immutability, and replication without changing how they are produced. DPX also offers RMAN cataloging control for Oracle environments where the two need to stay aligned.
Choosing Between Them
The deciding question is who gets paged when the database is down. Where that is the backup team, application-consistent DPX jobs are simpler to operate and easier to standardize across an estate. Where it is the DBA, native tooling keeps the recovery path familiar.
You do not have to pick one for everything. Running application-consistent jobs against the estate generally and native backups against the two or three databases whose owners insist on it is a normal outcome, and vStor is indifferent to the mix.
How DPX Protects Oracle
Oracle protection runs through the DPX Client installed on the database node, configured with the OracleConfig utility after installation. The TNS Listener has to be running, and the database has to be in ARCHIVELOG mode for backup and recovery operations. Block Data Protection additionally wants a JDBC driver, and Instant Access and RMAN cataloging need an iSCSI Initiator on the host.
Supported versions are worth checking rather than assuming. On Linux, DPX covers Oracle 26ai, 23ai, and 21c on Oracle Linux 8.6 through 8.10, plus Oracle 12c across several distributions and qualified support for 11.2.0.4 on selected platforms. On Windows, Oracle 19c is supported on Server 2022 through 2012, and 12c and 12c R2 on Server 2016 through 2012. Feature coverage is not uniform across that matrix: block-level backup and Instant Availability are unavailable for Oracle on Windows Server 2019, and on Linux they vary by distribution, with exceptions on Oracle Linux 7.1 to 7.2 and RHEL 7.0 to 7.1.
Some configurations fall outside Block Data Protection entirely, including RAC, ASM, raw volumes, Windows ReFS filesystems, and clusters. Check the Oracle Database compatibility page against your environment before building a recovery plan on a feature.
How DPX Protects Microsoft SQL Server
DPX supports both file-level and block-level backup for SQL Server. The DPX agent goes on the SQL host, and the account running backups needs sysadmin privileges.
For high-availability configurations, DPX extends block-level backup support to SQL Server AlwaysOn Availability Groups, and it handles both Active/Active and Active/Passive clusters. That covers most of what production SQL estates actually look like, which is not always true of backup products that support “SQL Server” in the abstract.
Storage Behaviour That Applies Either Way
Whichever backup method produces the data, vStor treats it the same once it arrives.
Compression is on by default. ZFS compression reduces the footprint without configuration. Confirm the appliance has resources for the additional load, and note that VMware agentless protection jobs are more prone to failure when compression is enabled, which is a consideration for mixed estates rather than for database backups specifically.
Deduplication is not on by default, and that is deliberate. It is worth enabling where there is significant duplication within a source or across sources, and it is genuinely resource-intensive. The documentation is direct about this: ensure ample memory, cache storage, and CPU are available, because insufficient resources lead to longer snapshot removal times and reduced write speeds. For database backups, where compression usually does most of the work already, enabling deduplication reflexively is a common way to make a backup appliance slower than it needs to be.
Immutable snapshots. vStor’s Snapshot Deletion Lock prevents snapshots being deleted or modified without authorization. Flexible protection can be adjusted or removed with MFA; fixed protection cannot be changed at all until its retention period expires. All deletion lock controls require MFA to be enabled on the vStor account, so that is a prerequisite rather than an optional hardening step. The same protection extends to volumes, individual files, and replicated data, where it creates WORM storage on the replication target. There is more on how this fits a wider strategy on the immutable backup storage page.
Replication. Database backups replicate to a partnered vStor at a secondary site, on-premises or in the cloud, so a current copy exists somewhere the primary site’s problems cannot reach.
Recovery: Instant Availability and Granular Restore
Data reduction and immutability decide whether you can recover. Recovery speed decides whether it matters in time, which is the RTO side of the problem.
Instant Availability is the mechanism that shortens it. Rather than copying a database back before it can be used, DPX presents the backup so the database can be brought up against it. DPX supports Instant Availability for Microsoft SQL Server, Exchange Server, SharePoint Server, and Oracle Database, subject to the version limitations noted above.
For cases where the whole database is not what you need, granular recovery applies here as it does elsewhere. vStor Snapshot Explorer mounts a snapshot as a browsable volume in the vStor interface, so individual files can be retrieved without staging a full restore. More on the restore paths generally is on the rapid recovery page.
Checking a Recovery Point Before You Restore It
When the reason for a restore is a suspected compromise, the most recent recovery point is the one most likely to be contaminated, and restoring it puts the problem back into production.
vStor can run a GuardMode scan against a mounted snapshot to check for ransomware infection or malicious encryption before anything is restored. It flags suspicious files by entropy, by magic number mismatches where a file’s signature does not match its type, and by blocklist pattern matching. The documented practice is to always scan mounted snapshots before restoring to production, and where infection is found, to scan progressively earlier snapshots until a clean recovery point is located.
This is what makes immutability useful rather than merely reassuring. Retaining recovery points that cannot be tampered with gives you something to scan backwards through, and cyber-resilient recovery covers how that fits an incident response.
Database Backup FAQ
What is an application-consistent database backup?
An application-consistent backup captures the database in a coherent state, with transactions settled rather than in flight. DPX achieves this for Oracle block backup by placing tablespaces into backup mode and snapshotting the filesystems beneath them. The result restores and opens without repair work, which a crash-consistent image cannot be relied on to do.
Can I keep using Oracle RMAN or native SQL Server backups?
Yes. Native backups produced by RMAN or the SQL Server utilities can land on vStor as their storage target, and they inherit the appliance’s compression, snapshots, immutability, and replication. DPX also provides RMAN cataloging control for Oracle environments that need the catalog kept in step.
Which Oracle and SQL Server versions does DPX support?
Oracle coverage runs from 11.2.0.4 through 26ai depending on platform, and feature support varies within that range: block-level backup and Instant Availability are not available for Oracle on Windows Server 2019, for instance. SQL Server support includes AlwaysOn Availability Groups for block-level backup and both Active/Active and Active/Passive clusters. Check the current compatibility documentation for your specific combination.
Should I enable deduplication for database backups?
Usually not by default. Compression is enabled out of the box and does most of the work on typical database backups. Deduplication is worth turning on where there is substantial duplication within or across sources, and it needs memory, cache, and CPU headroom to match, or you will see slower writes and longer snapshot removal times.
How does vStor make database backups immutable?
Through Snapshot Deletion Lock, in two forms. Flexible protection can be changed or lifted using MFA. Fixed protection cannot be altered until its retention period expires. Both require MFA to be enabled on the vStor account, and the same locking applies to volumes, files, and replicated copies, which become WORM storage on the target.
How fast can a database be recovered?
Instant Availability avoids the copy-back step by presenting the backup for the database to run against, which removes the largest component of recovery time for a large database. It is supported for SQL Server, Exchange, SharePoint, and Oracle, with version-specific exceptions. Where only part of the data is needed, mounting the snapshot in Snapshot Explorer is faster still.
Where to Go Next
The argument for vStor in a database environment is that it does not force a choice between the backup team’s tooling and the DBA’s. Application-consistent DPX jobs and native RMAN or SQL Server dumps land on the same appliance and inherit the same compression, immutability, and replication.
That matters most in mixed estates, where different databases belong to different teams with different habits and standardizing on one backup method is a negotiation nobody wins. Standardizing on the storage layer instead is achievable.
To go further: the DPX backup and recovery platform covers how database protection sits alongside VM, physical, and full-system recovery, and a demo will walk through Oracle or SQL Server protection against a real environment.