How to Size Nonstop Backup Storage and Licensing with ETI-NET BackBox^TM and QoreStor^TM

Executive Summary

Reliable backup and recovery are fundamental requirements for organizations operating mission-critical workloads on the HPE Nonstop platform. These environments frequently support high-value transaction processing systems such as banking networks, payment gateways, stock exchanges, retail POS systems, and telecommunications infrastructure. Because these systems often operate 24×7 with extremely high availability requirements, backup infrastructure must be equally reliable, scalable, and efficient.

ETI-NET BackBox combined with QoreStor provides a modern architecture for protecting Nonstop environments. By leveraging global deduplication, compression, and intelligent storage tiering, organizations can dramatically reduce the required physical storage footprint while maintaining high-performance backup and recovery capabilities.

However, correctly sizing both storage capacity and software licensing is critical to achieving optimal performance and cost efficiency. Under-sizing a backup system can lead to incomplete backups, insufficient retention periods, or storage exhaustion. Over-sizing infrastructure can unnecessarily increase capital and licensing costs.

This white paper presents a practical methodology for sizing Nonstop backup storage and licensing when deploying BackBox with QoreStor. It outlines key sizing variables, expected data reduction ratios, common Nonstop data types, and recommended capacity planning formulas. The goal is to provide a repeatable sizing framework that organizations can use when planning new deployments or expanding existing backup environments.

Understanding the Nonstop Backup Environment

A typical HPE Nonstop environment contains several components that influence backup sizing requirements. These include:

• Number of Nonstop domains (Host Systems)
• Total database and file system capacity
• Backup frequency (daily, weekly, monthly)
• Retention policies and regulatory requirements
• Incremental versus full backup strategy
• Data compression and deduplication efficiency
• On-site copies for high availability & performance
• Off-site replication for disaster recovery & long-term storage

Unlike traditional enterprise servers, Nonstop environments often generate extremely large volumes of structured transaction data. Financial transaction systems, for example, may process millions of records per hour. Because the majority of this data follows structured record formats, there is often a high level of similarity between backup sets.

This redundancy makes Nonstop data highly suitable for deduplication technologies.

When using ETI-NET BackBox with QoreStor, backup streams are written to a deduplicated storage repository. QoreStor identifies duplicate data segments across backup jobs and stores only unique data blocks, significantly reducing physical storage requirements.

As a result, backup storage sizing must account for:

• Number of Nonstop Host Domains connected to the respective VTC
• Total logical backup volumes (pre-deduplication)
• Physical storage consumption (post-deduplication)

Typical Nonstop Backup Data Types

Understanding the types of data being protected is essential for predicting compression and deduplication efficiency. Nonstop environments typically contain several categories of data with different reduction characteristics.

Common backup data types include:

Database Files

Large structured database files typically store transactional records. Examples include payment authorizations, financial ledger entries, and customer transaction logs.

These files often contain repeating record structures, which compress and deduplicate extremely well.

 Enscribe Files

The Enscribe file system is commonly used in Nonstop applications to store structured record data. Many legacy applications rely on Enscribe files for high-performance transaction storage.

Enscribe data tends to exhibit very strong deduplication characteristics.

 OSS Files

The OSS (Open System Services) environment provides POSIX-compatible file systems used for modern applications, middleware, and integration components.

OSS directories often contain:

• logs
• configuration files
• scripts
• application components

Compression ratios vary depending on file type.

 Application Binaries

Compiled application executables, shared libraries, and middleware components typically change infrequently. These files produce very high deduplication ratios across backup cycles.

 Logs and Audit Trails

Transaction logs and audit records are common in payment processing and financial compliance systems. Log files may grow rapidly but typically contain highly repetitive text patterns.

 Configuration and Control Files

These files are usually small but important for system recovery and application configuration.

 Typical Compression and Deduplication Ratios

The efficiency of deduplication and compression varies depending on data type. Industry experience from Nonstop deployments using deduplication storage platforms indicates the following typical ranges.

Across mixed enterprise Nonstop environments, a conservative planning ratio of 8:1 to 12:1 total data reduction is typically recommended.

For most capacity planning exercises, a 10:1 overall reduction estimate provides a safe and predictable sizing baseline.

Key Inputs Required for Sizing

Before performing storage calculations, several baseline parameters must be collected.

1. Total Source Data

The starting point is the total amount of data stored on the Nonstop system that must be protected. This typically includes:

• Database files
• Enscribe files
• OSS files
• Application binaries
• Configuration files

For example:

Total protected data: 10 TB

2. Backup Frequency

Backup schedules determine how many backup sets must be stored simultaneously.

Typically, Nonstop backup policies include:

• Daily incremental backups
• Weekly full backups
• Monthly or quarterly retention copies

Backup frequency determines how many backup sets must be stored simultaneously.

Example policy:

• Daily incremental – 14 days retention
• Weekly full backups – 8 weeks retention
• Monthly full backups – 12 months retention

3. Daily Data Change Rate

The change rate represents the percentage of data modified each day. In transaction processing environments this is typically between 2% and 10%.

Example:

Daily change rate: 5%

For a 10 TB system:

Daily change volume:

10 TB × 5% = 0.5 TB per day

4. Deduplication and Compression Ratio

One of the primary benefits of using QoreStor is global deduplication across all backup sets.

Typical reduction ratios observed in Nonstop environments include:

For sizing purposes, a conservative estimate is recommended.

Example assumption:

10:1 data reduction

Step-by-Step Storage Sizing Methodology

Step 1 – Calculate Logical Backup Volume

Logical backup volume represents the total amount of data generated before deduplication and immutability.

Example system:

Total data: 10 TB

Weekly full backup:

10 TB

Daily incremental backup:

1 TB

Monthly Logical Backup Volume

Weekly full backups:

10 TB × 4 = 40 TB

Daily incremental backups:

1 TB × 30 = 30 TB

Total monthly logical backup volume:

70 TB

Step 2 – Apply Deduplication Reduction

Using a conservative 10:1 reduction ratio:

70 TB ÷ 10 = 7 TB

This represents the approximate physical storage required to maintain one month of backups.

Step 3 – Apply Retention Policy

If backups are retained for 12 months, the storage requirement grows depending on deduplication efficiency across months.

Due to cross-backup deduplication, older backup sets typically consume minimal additional storage.

A common rule of thumb:

• First month: full storage requirement
• Additional months: 20–30% incremental storage growth

Example calculation:

Month 1: 7 TB
Months 2–12 (11 months):

7 TB × 25% × 11 = 20 TB

Total estimated storage:

7 TB + 20 TB = 27 TB

Step 4 – Add Operational Headroom

Production backup systems should maintain at least 20–30% free capacity for operational flexibility.

27 TB × 1.3 = 35 TB

Final recommended storage capacity:

≈40 TB

Example Sizing Scenario

Result:

BackBox / QoreStor Storage Architecture Considerations

QoreStor with BackBox supports multiple storage tiers, allowing organizations to optimize performance and cost.

Typical deployment tiers include:

Tier 1 – Capacity Tier

• Active backup landing zone
• Recent backup sets
• High-capacity disk storage
• Deduplicated backup retention

Tier 2 – Cloud Tier (viewed as extension of Capacity Tier)

• Object storage (S3 compatible)
• Long-term archival retention as well as off-site

Object storage systems (such as S3-compatible platforms) can be used for long-term archival retention, off-site disaster recovery, and immutability.

Through Cloud Tiering, deduplicated backups stored in the Capacity Tier can be automatically copied from on-premises storage to cloud tier repositories through QoreStor.

Immutability through S3-compatible storage requires additional capacity planning. Check with ETI-NET in the event immutability is required.

Network and Throughput Planning

Storage capacity is only part of the sizing process. Backup throughput must also be considered.

Key variables include:

• Number of concurrent backup streams
• Network bandwidth
• Disk performance
• Deduplication processing capacity

Typical guidelines:

Proper throughput planning ensures backup windows remain within operational limits.

Licensing Considerations

BackBox Licensing

BackBox licensing is determined by:

• Number of Nonstop systems protected (Hosts)
• Number of BackBox Virtual Tape Controllers (VTC) supporting Nonstop Host systems

QoreStor Licensing

Because deduplication occurs downstream in QoreStor, licensing calculations are based on physical data, stored on the VTC after compression and deduplication.

QoreStor licensing model is based on:

• 8TB (post deduplication) base software license
• Incremental TB licenses (check with HPE / ETI-NET)
• Replication and Cloud tiering functionality

Sizing must account for:

• Maximum logical ingest capacity
• Future data growth
• Replication overhead

Growth Planning

Backup infrastructure should always account for expected data growth over the lifecycle of the deployment.

Typical enterprise data growth rates range from 15% to 30% annually.

Example:

Initial protected data:

10 TB

Three-year growth projection:

Year 1: 40 TB
Year 2: 50 TB
Year 3: 60 TB

Storage sizing should therefore be calculated using projected future capacity rather than current usage alone.

Best Practices for Nonstop Backup Sizing

Organizations deploying ETI-NET BackBox with QoreStor should follow several best practices.

Use Conservative Deduplication Estimates

Actual reduction ratios often exceed expectations, but planning should use conservative numbers.

Maintain Free Capacity

Running a deduplication system near full capacity can reduce performance and increase risk.

Maintain at least 20–30% free space.

Plan to run OBB17 to reclaim backup storage space daily, at a time when backups are not performed.

Note: QoreStor will automatically perform reclamation of storage space at a time when the activity is low to not impact the backup process.

Plan for Recovery Scenarios

Backup sizing should consider worst-case recovery situations where multiple backup sets must be accessed simultaneously.

Validate Backup Windows

Throughput must be tested to ensure backups complete within operational windows.

Conclusion

Accurately sizing backup storage and licensing for Nonstop environments require careful consideration of data volume, change rates, retention policies, and expected deduplication efficiency.

Deploying ETI-NET BackBox together with QoreStor provides an efficient and scalable architecture for protecting critical systems running on the HPE Nonstop.

By applying conservative reduction estimates, planning for long-term data growth, and maintaining operational headroom, organizations can implement a backup infrastructure that balances reliability, performance, and cost efficiency.

Properly sized backup systems ensure that backups complete reliably, storage consumption remains predictable, and recovery operations can be executed rapidly when required. For enterprises operating high-volume transaction systems, this approach delivers the resilience and scalability necessary to protect their most critical workloads.