Test Database Backup Optimisation

CT-TDB: Eliminate Redundant
Non-Production Backup Costs

Offload Oracle RMAN backups from expensive Exadata ASM disk groups onto the Clonetab appliance. Provision non-production databases from lightweight NFS snapshots — no more full copies per environment.

See How It Works Book Free Demo
Platform Overview

Your Non-Production Storage is Overprovisioned

In traditional Oracle environments, every non-production database requires a full RMAN backup to be stored on the same high-cost Exadata ASM disk group as production. Multiply that by several non-prod environments and a multi-day retention window — and the storage bill becomes indefensible.

CT-TDB is Clonetab's targeted solution for this exact problem. It intercepts the backup flow and redirects all RMAN backup data — full and incremental — onto the Clonetab appliance via provisioned LUNs, keeping Exadata exclusively for production workloads.

"Move backups off Exadata. Clone from snapshots. Stop paying for storage you shouldn't need."

~90 TB
Traditional storage (10 TB prod, 3 non-prods, 5-day retention)
~60 TB
With CT-TDB — ~40 TB saved by offloading backups

Supported Environments

📦 Databases

Oracle Database (all editions), including Exadata-hosted instances

🏗️ Storage Layer

Exadata ASM disk groups with ACFS mounted file systems

☁️ Deployment

On-Premises, OCI, AWS, Azure — wherever Clonetab is deployed

🔗 Backup Tool

Oracle RMAN — full and incremental backup management

~40 TB

Storage Saved

vs. traditional on 10 TB prod, 3 non-prods

0

Exadata Backup Space

All RMAN backups redirected off Exadata

1×

Storage per Non-Prod

No redundant backup copies per environment

<1hr

Clone Provisioning

NFS snapshot mounts replace slow full copies

How It Works

From Backup Offload to Clone Provisioning

CT-TDB replaces the traditional "backup everything to Exadata" model with a two-phase approach: redirect backups onto the Clonetab appliance, then provision non-production environments via NFS snapshot mounts.

CT-TDB Architecture: Source → Clonetab Appliance → Target

RMAN backups flow from the Source database through the Clonetab Appliance, then provision multiple non-production target environments via NFS

CT-TDB Architecture Diagram showing Source, Clonetab Appliance and Target servers connected via NFS
🏭 Source (Exadata)

The production Oracle database running on Exadata. RMAN backups are redirected away from this server via an NFS connection to the Clonetab Appliance, freeing the expensive ASM disk group for production I/O only.

⚙️ Clonetab Appliance

The central hub running the Cloning Engine, CT Engine, Apache Tomcat, XE, and Ctmon. Receives all RMAN full & incremental backups on dedicated LUNs, manages snapshot retention, and orchestrates volume clones for non-production provisioning.

🎯 Target (Non-Prod)

Multiple non-production environments (DEV, QA, TST and beyond) mounted from the appliance via NFS. Each target gets an isolated, production-quality clone — provisioned in under an hour, with zero backup data stored on Exadata.

NFS

Two NFS connections power CT-TDB: the inbound NFS mount carries RMAN backup data from the Source to the Clonetab Appliance; the outbound NFS mount delivers snapshot clones to the Target non-production servers — enabling fast, lightweight provisioning without copying data back to Exadata.

❌ Before CT-TDB — All Storage on Exadata

🏭
Production DB
10 TB · Exadata
→
💾
RMAN Backup
Exadata ASM disk group
→
📋
Full Copy × 3
30 TB non-prod
→
📦
Retention Snaps
+50 TB (5 days)
→
💸
~90 TB Total
On Exadata

✅ After CT-TDB — Backups Off Exadata, Clones via NFS

🏭
Production DB
Stays on Exadata
→
🖥️
Clonetab Appliance
RMAN backups + LUNs
→
📸
Snapshot Clone
Volume clone from snap
→
🔗
NFS Mount
Mounted on target
→
🧪
Non-Prod × N
~60 TB total

Step-by-Step: The CT-TDB Flow

1

LUN Provisioning on Clonetab Appliance

LUNs are provisioned on the Clonetab appliance to receive all RMAN backup data. This dedicated storage replaces the Exadata ASM disk group as the backup target, completely freeing Exadata for production I/O.

2

RMAN Full & Incremental Backup to Appliance

Oracle RMAN manages all full and incremental backups, now directed to the Clonetab appliance via NFS mounts. Snapshot retention (e.g. 5 days) is also maintained on the appliance — no Exadata disk group space consumed.

3

Volume Clone from Snapshot

When a non-production environment is requested, Clonetab creates a volume clone from the latest snapshot on the appliance. This is near-instantaneous and requires no additional backup copy to be created.

4

NFS Mount on Target Non-Production Instance

The snapshot clone is mounted on the target non-production host via NFS mounts. This gives the non-prod environment immediate access to the data without requiring a full physical copy to be transferred first.

5

Data Replication to Non-Production Instance

From the NFS mount point, data is replicated into the non-production instance. Each environment receives its own dedicated copy, ensuring full isolation. Storage is proportional to the number of non-prod instances, but backup overhead is completely eliminated.

Core Capabilities

Six Pillars of CT-TDB

CT-TDB combines RMAN-native backup offload, snapshot-based cloning, and NFS provisioning to deliver a leaner, faster non-production lifecycle on Oracle Exadata environments.

RMAN Backup Offload

All full and incremental RMAN backups are redirected to the Clonetab appliance. Exadata ASM disk groups are reserved entirely for production — eliminating the largest source of non-production storage waste.

Snapshot-Based Volume Cloning

Non-production environments are built from volume clones of the latest appliance snapshot, not from slow full data transfers. Clone creation is near-instantaneous regardless of database size.

LUN-Based Appliance Storage

LUNs are provisioned on the Clonetab appliance to host backup data. This purpose-built storage layer is separate from Exadata, giving your infrastructure team clean cost accounting and capacity management.

NFS Mount Provisioning

Snapshot clones are mounted on target non-production instances via NFS mounts. This gives instant read access to the data before the full replication completes, dramatically reducing time-to-ready for test environments.

Exadata Cost Protection

By eliminating backup and retention storage from Exadata, CT-TDB directly reduces licence and infrastructure costs. Customers no longer need to justify expensive Exadata disk group expansions to support non-production refresh cycles.

Clonetab-Integrated Orchestration

CT-TDB is fully orchestrated through the Clonetab platform. Scheduling, monitoring, post-clone automation, and audit logging all work seamlessly alongside CT-Core, CT-Clone, and other Clonetab modules.

Storage Efficiency

Lower Costs, Same Production Quality

CT-TDB doesn't compromise on data fidelity. Non-production environments are provisioned from RMAN backups of the live production database — the same source used for disaster recovery. What changes is where that backup lives.

No Backup Copies on Exadata

RMAN backup data — which accounts for the majority of non-prod storage demand — moves entirely off the expensive ASM disk group onto the Clonetab appliance.

Snapshot Retention on the Appliance

Multi-day snapshot retention (e.g. 5-day policies that add 50 TB in traditional setups) is maintained on the appliance at a fraction of the cost.

Scales Linearly with Non-Prod Count

Each non-production environment still requires its own full data copy, so storage grows proportionally — but the backup and retention overhead is completely eliminated.

Storage Breakdown: 10 TB Prod · 3 Non-Prods · 5-Day Retention

  • Production (Exadata)10 TB
  • 3 Non-Prod copies30 TB
  • Backup + retention (traditional)+50 TB ❌
  • Backup + retention (CT-TDB appliance)Offloaded ✓
  • Total on Exadata~40 TB (was ~90 TB)

Exadata Storage Required — Before vs After CT-TDB

Without CT-TDB~90 TB
90 TB
With CT-TDB~40 TB
~40 TB

*Based on 10 TB production, 3 non-production instances, 5-day retention. Actual savings depend on number of non-prod environments and retention policy.

~40 TB
Removed from Exadata
All backup + retention data redirected to Clonetab appliance

Storage Saved Scales with Non-Prod Count

3
Non-prods
~40 TB
saved
6
Non-prods
~60 TB
saved
8
Non-prods
~80 TB
saved
Side-by-Side

CT-TDB vs. Traditional Model

Based on 10 TB production, 3 non-production instances, 5-day snapshot retention.

Metric Traditional CT-TDB
Production database location Exadata ASM disk group Exadata ASM disk group (unchanged)
RMAN backup location Exadata ASM disk group (+cost) Clonetab appliance (offloaded)
Snapshot retention (5 days) ~50 TB on Exadata On appliance (no Exadata cost)
Non-prod provisioning method Full copy from Exadata backup Volume clone via NFS mount
File system ACFS (Exadata) NFS mounts
LUN provisioning On Exadata disk group On Clonetab appliance
Backup tool Oracle RMAN Oracle RMAN (unchanged)
Non-prod storage per instance Full copy required Full copy required (no change)
Total Exadata storage ~90 TB ~40 TB
Exadata storage saved — ~40 TB (~44% reduction)

CT-TDB is available now. For further savings with Oracle ZFS Storage Appliance on OCI, see CS-TDB.

Business Impact

Measurable Results That Matter

~44%

Exadata Storage Reduction

Backup & retention offloaded from disk group

0

Backup Copies on Exadata

All RMAN data redirected to Clonetab appliance

<1hr

Clone Provisioning

NFS snapshot mounts vs. full copy transfers

100%

Production Fidelity

Non-prod cloned from live RMAN backup

1

Reduce Infrastructure Spend

Eliminate the need to provision additional Exadata storage for backup copies — often the biggest objection from customers during non-prod environment planning.

2

Accelerate Dev & Test Cycles

Teams can request and receive non-production refreshes in under an hour instead of waiting for slow full-copy transfers from Exadata, unblocking development and testing workflows.

3

Foundation for Further Savings

CT-TDB is the first step. Customers who move to the CS-TDB CSTD module with Oracle ZFS Storage Appliance on OCI can unlock an additional ~40 TB in savings through cloud-native compression.

Ideal For

Who Benefits Most from CT-TDB

Exadata Customers

Enterprises on Oracle Exadata who are being asked to justify large ASM disk group expansions to support non-production refresh workflows — CT-TDB eliminates that request entirely.

Large Non-Prod Footprints

Teams running 4–8+ non-production instances from a single production source where retention snapshots multiply the storage bill rapidly — CT-TDB cuts the multiplier to zero for backup data.

Frequent Refresh Cycles

Development and QA teams who need regular (daily or weekly) production-quality refreshes — CT-TDB makes frequent cloning operationally and financially viable where it previously was not.

Frequently Asked Questions

Your Questions Answered

Does CT-TDB require changes to how RMAN is configured?
Yes, but minimally. RMAN backup targets are redirected from the Exadata ASM disk group to the Clonetab appliance via NFS mounts. The core RMAN backup strategy — full plus incremental — remains unchanged. Clonetab handles the configuration as part of the CT-TDB setup process.
Will CT-TDB affect production database performance?
No. The production database continues to run on Exadata with no changes to its storage configuration or I/O profile. CT-TDB only changes where RMAN backup data is written, which is a background process. Production workloads are completely isolated from the backup offload flow.
Is a full data copy still required per non-production environment?
Yes. With CT-TDB, each non-production instance receives its own full data copy replicated from the NFS-mounted snapshot. Storage per non-prod environment remains proportional to database size. What CT-TDB eliminates is the additional backup and retention storage — not the per-environment copy. For thin-provisioned NFS snapshot mounting (no full copy per env), that capability is available in the CS-TDB CSTD module.
How does CT-TDB handle snapshot retention policies?
Snapshot retention is managed on the Clonetab appliance, not on Exadata. You can configure multi-day retention windows (e.g. 5, 7, 14 days) and all snapshot data stays on the appliance. In a traditional setup, a 5-day retention on a 10 TB database adds ~50 TB to your Exadata disk group. With CT-TDB, that cost is eliminated entirely.
Does TDE encryption affect CT-TDB?
TDE (Transparent Data Encryption) does not affect CT-TDB's backup offload or cloning capabilities. RMAN backups work normally regardless of whether TDE is enabled. TDE only becomes relevant when considering compression in the CS-TDB CSTD module — encrypted data is not compressible, so the ZFS compression benefit is unavailable when TDE is active.
How does CT-TDB relate to CT-Clone and CT-Core?
CT-TDB is a storage optimisation module that sits alongside the existing Clonetab product suite. CT-Core handles DBA automation and orchestration; CT-Clone handles snapshot-based cloning and virtualisation. CT-TDB specifically addresses where backup data is stored and how non-production environments are provisioned from it — complementing rather than replacing the capabilities of CT-Core and CT-Clone.

Ready to Free Up Your Exadata Storage?

See how CT-TDB offloads your Oracle RMAN backups off Exadata, reduces disk group demand by up to 44%, and provisions non-production environments from lightweight NFS snapshot mounts.

Book Free Live Demo Download Brochure