Zerto · Continuous Data Protection & Disaster Recovery Platform

Korean GS certification for this solution,
obtained by Softworks itself

Supplying a foreign DR solution to the Korean public sector requires GS certification. Softworks — not the vendor or a distributor — obtained this certification directly, earning GS Grade 1, and completed registration with the Public Procurement Service (PPS). This work goes beyond supplying the product: we take responsibility for how it performs.

Why Softworks

How Softworks works with Zerto

We obtained Korean GS certification ourselves

Testing and validating an overseas vendor’s product against the Korean certification framework, and writing the documentation to pass it, requires understanding how the product works down to its internal architecture. This certification led to PPS MAS registration: Softworks opened the very procurement path through which public institutions can acquire Zerto.

Failover drills are part of the project scope

The work runs from DR scenario design to failover runbook creation, an actual failover drill and submission of a results report, and includes updating the runbook to address issues found in the drill.

We include ransomware recovery in DR scenarios

Zerto analyzes I/O patterns in real time to detect abnormal encryption activity and tags the affected checkpoints. Softworks does not stop at the “alert” stage: our design also covers procedures for recovering to the point just before infection and an isolated validation environment for post-incident forensics.

We have deployed DR in network-separated environments

We have deployed both In-House DR and Remote DR in public sector and financial infrastructure where internet and internal networks are separated. In network-separated environments, DR depends on how the replication path and control points are designed.

We design configurations that keep DR resources from sitting idle

Zerto does not need compute resources on the DR side until the moment of recovery. Using this, we propose configurations that also use DR site resources for development and testing.

Also used as a migration tool

For data center relocation, hypervisor migration and cloud migration, we use Zerto replication as the migration method to minimize downtime. When evaluating VMware alternatives, it connects to migration paths to other hypervisors such as HPE VME.

Scope of Work

From assessment to operations: what Softworks covers

Assess

Assessment

Business criticality classification (BIA) · RPO / RTO targets per service · regulatory requirements review

Design

DR site configuration · protection group (VPG) design · replication bandwidth sizing · failover and failback scenarios

Build

Deployment

Zerto deployment and replication setup · initial synchronization · failover runbook creation

Drill

Drills

Actual failover drill · issue identification and procedure improvement

Operate

Operations

Replication status monitoring · scheduled drills on your behalf · scenario updates

Knowledge Base

We convert objectives into four figures before design

Starting the design with the question “What RPO would you like?” leads nowhere. Softworks first converts the target recovery point and recovery time into four figures: circuit bandwidth, journal capacity, spare host resources and retention period. Only then does design begin. Journal capacity is not estimated at the quotation stage; it is calculated back from measured data.

BIA-based tieringTolerable downtime defined per business service before design begins
Journal sizing from measured dataChange rate measured, then sized back from the retention period
Failover drill reportMeasured recovery times submitted in a report
Network-separated DR deploymentsBoth In-House and Remote DR delivered

Accumulated Assets

Business criticality classification (BIA) template
Recovery point and recovery time objectives by service tier
Replication bandwidth sizing sheet based on measured change rates
Journal capacity formula (change rate × retention period)
Protection group boundary design patterns (by business workflow)
Standard failover and failback runbooks
Failover drill scenario and results report template
Cross-platform migration prerequisites checklist
Regulatory compliance report output items

Field Issues

Six challenges commonly seen in the field

Challenges in the Field	The Softworks Approach
“We have DR in place, but we have never actually failed over”	We run failover drills on your behalf once or twice a year and submit measured recovery times in a report. Our scope extends to updating the runbook based on issues found in the drills
“We have no recovery point objectives for each business service”	We classify services into tiers through business impact analysis and design a different level of protection for each tier. The configuration is finalized after objectives are converted into figures for circuits, journal capacity and host resources
“Services made up of multiple VMs recover to different points in time”	VMs are grouped into protection groups so they recover to the same point in time even across different datastores and hosts. The key is to set group boundaries by business workflow, not by VM list
“We assume ransomware is outside the scope of DR”	Abnormal encryption is detected in the replication path and the affected checkpoint is marked. Because detection time determines how much must be recovered, our procedures also cover recovery to the point just before infection and an isolated validation environment
“We can’t afford the cost of DR circuits”	Only changed blocks are compressed and sent, not the full data set. We measure change rates to size bandwidth and apply different replication policies by service tier
“We want to move to another hypervisor, but worry there is no way back”	The constraints of cross-platform migration come not from replication setup but from guest-side prerequisites. We confirm these requirements before contract, and keep the existing site protected during migration to preserve a path back

“We have DR in place, but we have never actually failed over”

Setup that starts systems only on an isolated network while production replication continues

“Services made up of multiple VMs recover to different points in time”

Protection groups that bind VMs spread across hosts along service boundaries, with different objectives per group

“We assume ransomware is outside the scope of DR”

Alert screen showing the affected protection group, VMs and volumes when abnormal encryption is detected

Detection at the moment encryption occurs, independent of backup timing

“We want to move to another hypervisor, but worry there is no way back”

Cross-platform migration while protection stays in place

Vendor Insight

Disaster recovery through HPE Zerto materials

The gap left by a backup-only setup

Backup is the layer that stores data; disaster recovery is the layer that brings services back up. Below are the limits of a backup-based setup as stated in vendor materials.

12–24 hoursRecovery point objective of a backup-based setup (changes made after the last backup cannot be recovered)
Up to 4 hoursData-loss window that remains even with snapshots (shorter intervals increase storage load)
32–56 hoursDistance to the last clean point in a ransomware incident
16–18 daysTime taken for a full recovery from a backup-based vault

After converting the same environment to a CDP architecture

5–15 secondsRecovery checkpoint intervalWritten to the journal in exact write order
4 hours agoLast clean pointSharply reduced from 32–56 hours
2 hoursFull recovery timevs. 16–18 days from a backup-based vault in the same environment
5 MbpsMinimum replication bandwidthOnly changed blocks are compressed, encrypted and sent

The path of a single replicated write

Nothing is installed in the guest operating system. Because it intercepts and replicates writes passing through the hypervisor, it works the same way regardless of operating system or application.

Separation of protected and recovery sites, per-host replication engines, and management and replication networks

InterceptWrite replication without guest agents
RecordWritten to the journal in order
GroupConsistency at the business-service level
VerifyFailover testing without disrupting operations

Incident types each layer protects against

SecondsDisaster recovery (CDP)Prevents service outages and loss of recent data
DailyBackupHandles long-term retention and item-level recovery
Retention periodImmutable copiesProtect the final copy from deletion and encryption

Figures shown in the console

Below are console screens published in Zerto’s official product documentation. Operations are measured by whether these figures match the targets stated in the contract.

Dashboard
Replication lag is visible to the second
Protection group count, protected capacity, compression ratio and average replication lag are shown on one screen. Softworks defines the normal range for each value at deployment, and when a value falls outside it, first determines whether the cause is the circuit or the storage.
Protection groups
Each protection group shows its own recoverable range
Journal retention, current recovery points and long-term retention status are shown per group, so you can check the objectives set for each service tier directly on this screen.

What we check first on site

Category	Feature	Description
Circuit	We measure bandwidth instead of estimating it	We measure change rates to calculate the bandwidth required. Because only changed blocks are sent instead of full snapshots, the sizing basis differs from backup.
Journal	The retention period determines journal capacity	The journal does not grow indefinitely. It is kept only for the retention period, rotating with the oldest points rolling off first. The recoverable range equals the retention period.
Protection groups	We set group boundaries by business workflow	Grouping by VM list leaves recovery points out of sync. You must first define which VMs make up a single business service.
Cross-platform migration	We confirm prerequisites before contract	Between what the product supports and what can actually be migrated on site lie guest-side prerequisites, such as boot mode and driver requirements.

SourceFigures are from HPE Zerto product technical documentation and standard proposals. Recovery times and clean points are based on a vendor-cited case of a specific scale (300 VMs · 300 TB) and vary by customer environment. Diagrams and screens are published in Zerto’s official product documentation (Zerto Knowledge Portal) and are not from customer environments.

Components

Six components of Zerto

The path of a single write: intercepted, recorded in the journal, grouped by business service, verified and recovered. The decisions Softworks makes at each layer are summarized alongside.

Replication engine

Nothing is installed in the guest operating system

A replication engine on each host intercepts writes passing through the hypervisor before they reach storage. No agent is installed in the guest operating system, so it works regardless of operating system or application, and because it creates no snapshots, it does not affect production performance.

Writes intercepted before they reach storage

What Softworks Does

We design resource allocation and placement for the replication engine on each host. Because it intercepts writes at a different point than other replication products, we use this architecture to explain the difference when a comparison with existing approaches is needed.

Journal

The journal does not grow indefinitely; it rotates by retention period

Intercepted writes are recorded in the journal in order, and a recovery checkpoint is created every 5–15 seconds. The journal does not grow indefinitely: it is kept only for the retention period, with the oldest points rolling off first, so the retention period defines the recoverable range.

Recoverable range secured by the retention period

What Softworks Does

Journal capacity is not estimated: it is calculated back from measured change rates and recalculated whenever the retention period changes. Retention periods are set per service tier to balance capacity and cost.

Protection groups

We build protection groups around business workflows

Grouping VMs spread across multiple hosts into one protection group lets them recover to the same point in time even across different datastores and hosts. Each group can have its own recovery point objective, and a single VM can belong to multiple groups.

What Softworks Does

Success depends less on installation than on how group boundaries are drawn. We first define which VMs make up a single business service, then apply different objectives to each group by service tier.

Anomaly detection

Abnormal encryption is detected in the replication path

Write patterns being replicated are analyzed in real time to identify abnormal encryption activity, and the affected checkpoint is marked. Detection happens when encryption occurs, independent of the backup cycle, so the range to recover is short.

Detection at the moment encryption occurs

What Softworks Does

Detection does not end at an alert. Our DR runbooks include the procedure for finding the point just before infection and setting up an isolated environment for post-incident analysis. We also define who makes decisions after detection and what they decide on.

Immutable copies

Point-in-time copies exported to object storage

Specific points in the journal are extracted and stored immutably in object storage. Unlike copying production disks directly, this places no load on production, and copies cannot be deleted within the retention period, even with administrator privileges.

Journal points extracted and stored immutably in object storage

What Softworks Does

The documentation states at which layer the 3-2-1-1-0 rule is met. DR copies and long-term retention copies address different types of incidents, so we design the two layers with separate roles instead of mixing them.

Failover testing

We actually start recovery targets without stopping operations

Recovery targets are started on an isolated network separate from production. Replication from the production site continues during the test, and writes generated by the test are recorded in a separate area, so production data is unaffected.

What Softworks Does

We run drills on your behalf once or twice a year and submit measured recovery times in a report. Our scope extends to updating the runbook based on issues found in the drills, and recoverability is proven by the report.

References

Customer References

Customer Type	Projects	Scope
Public sector · Public corporation	In-House DR deployment	Network-separated infrastructure servers (internet + internal network), 80 VMs
Finance · Bank	Remote DR deployment	Mobile work + digital workplace services, 30 VMs
Financial sector · Mutual financial institution	Remote DR deployment	DR center for a new digital banking system, 15 VMs
Public sector · Fund management institution	Remote DR deployment	Disaster recovery for network-separated infrastructure servers, 30 VMs

Operation & Support

The same team stays on after deployment

24×7 replication status monitoring
Scheduled failover drills on your behalf
Annual DR scenario update
Failover execution support during outages
Support for procurement contract renewal based on GS certification

We combine solutions from global technology leaders with Softworks' deployment and operations expertise to power our customers' digital and AI transformation.

Prove your disaster recovery with failover drills

We start together by classifying business criticality and quantifying recovery objectives.

Request a Consultation →

Korean GS certification for this solution, obtained by Softworks itself

How Softworks works with Zerto

We obtained Korean GS certification ourselves

Failover drills are part of the project scope

We include ransomware recovery in DR scenarios

We have deployed DR in network-separated environments

We design configurations that keep DR resources from sitting idle

Also used as a migration tool

From assessment to operations: what Softworks covers

Assess

Design

Build

Drill

Operate

We convert objectives into four figures before design

Accumulated Assets

Six challenges commonly seen in the field

“We have DR in place, but we have never actually failed over”

“Services made up of multiple VMs recover to different points in time”

“We assume ransomware is outside the scope of DR”

“We want to move to another hypervisor, but worry there is no way back”

Disaster recovery through HPE Zerto materials

The gap left by a backup-only setup

After converting the same environment to a CDP architecture

The path of a single replicated write

Incident types each layer protects against

Figures shown in the console

Replication lag is visible to the second

Each protection group shows its own recoverable range

What we check first on site

Six components of Zerto

Replication engine

Journal

Protection groups

Anomaly detection

Immutable copies

Failover testing

Customer References

The same team stays on after deployment

Related Solutions

Prove your disaster recovery with failover drills

Korean GS certification for this solution,
obtained by Softworks itself