Paying an electricity bill ought to be an uneventful experience. A few clicks, a receipt, the modest satisfaction of having behaved like an adult. Behind that ordinary transaction, however, sits an extraordinary demand: the database must be there when the customer is.
PayGo, a utility payments provider, ran into a familiar obstacle in its AWS environment. Its SQL Server recovery process used log shipping and required human intervention. That could serve disaster recovery. It could not supply the quick, automatic handover the business wanted. An alternative involving SQL Server Enterprise Edition carried a price PayGo described as hundreds of thousands of dollars.
- SIOS protects critical applications. Its software watches for trouble and coordinates recovery on Windows and Linux.
- Storage need not be shared. DataKeeper replicates local disks so another server has data ready for a handover.
- Architecture beats wishful thinking. Recovery targets, separate failure domains and rehearsals matter as much as buying the software.
The expensive part of waiting
PayGo selected SIOS DataKeeper Cluster Edition. It made replicated storage usable by Windows Server Failover Clustering, allowing the company to keep SQL Server Standard Edition in a clustered configuration. The published case describes two database nodes per cluster, placed in separate AWS availability zones. PayGo had found a way to change the storage arrangement without buying a different database edition simply for that availability feature.
A separate SIOS account of PayGo’s historical cloud migration puts infrastructure spending at roughly $6,000 a month before the move and $900 afterward. Those figures describe the company’s circumstances at the time. They include a move to AWS; they are not a SIOS price list, nor a forecast for the next company through the door.
The useful question for a buyer is less glamorous than the savings figure: what, exactly, are we paying to keep? A database edition? A storage appliance? A recovery process familiar to the team? PayGo’s example suggests that these decisions deserve separate scrutiny. An expensive answer to one question can conceal a cheaper answer to another.
Two jobs, easily confused
SIOS has two principal names to untangle. LifeKeeper monitors applications and coordinates recovery. DataKeeper replicates storage. In Windows deployments, DataKeeper Cluster Edition works alongside Microsoft’s failover clustering. SIOS is selling an addition to that machinery, rather than asking every Windows administrator to abandon it.
LifeKeeper for Linux examines the application stack, including the database, operating system, network and storage. Its recovery policies can alert an administrator, restart an application or move service to another node. A machine that answers a health check is therefore only part of the picture. The database inside it might still be unable to do its job.
Serving the workload
Ready for recovery
The term SANless sounds like a technical diet. It means a cluster can use replicated local storage instead of depending on a shared storage area network. DataKeeper offers synchronous and asynchronous replication. That flexibility matters when the machines sit close together, far apart, or across a mixture of physical servers and virtual infrastructure.
The knowledge inside the kit
A spare server does not automatically know how to become a useful server. Enterprise applications have dependencies, and recovery has an order. SIOS packages application-specific intelligence in Application Recovery Kits, or ARKs. These extensions handle configuration and recovery tasks for workloads such as SAP and Oracle.
Consider SIOS’s SAP HANA demonstration. Solutions architect Todd Doane deliberately causes a kernel failure on a server running SAP’s central services. The standby takes over. When the failed machine returns, the replication service moves to preserve SAP’s required arrangement. The interesting feat is the sequence: the right components return in the right relationship.
“It just works.”
CHAD GATES / PAYGO
In SIOS’s published customer account
That tiny customer verdict is the ambition of this entire category. The administrator should have less to improvise during an outage because someone has already encoded the recovery rules. SIOS’s competitive argument rests on that application knowledge, along with commercial support, rather than on the mere existence of a second machine.

There is a long product history behind the current console. SIOS’s timeline records SteelEye’s acquisition of LifeKeeper technology from NCR in 1999, a Red Hat 6.1 release in 2000, Windows coverage in 2003 and DataKeeper’s launch in 2008. SteelEye joined the Tokyo-based SIOS business in 2006. Today, the US company reports more than 80,000 installed licenses worldwide. Licenses count installations, not customers.
A university does the arithmetic
The appeal extends beyond payments. In another published customer story, an unnamed New York-area university wanted better performance for its Oracle-backed enterprise system, particularly during registration, and a lower cost of ownership. It moved to Red Hat Linux servers with SanDisk Fusion ioMemory and SIOS protection.
LifeKeeper supplied application failover, DataKeeper supplied replication, and the Oracle recovery kit supplied database-specific protection. Consultant Brian Roth reported that three servers plus the SIOS solution cost less than one of the university’s old servers. The institution used savings to add memory. Removing dependence on shared disks also changed the failure risks in the storage design.
There is a pleasingly unfashionable lesson here. Modernization can mean spending less on the machine and more carefully arranging how machines cooperate. The university’s result was specific to a legacy replacement, flash storage and its Oracle workload. The transferable habit is to compare complete working systems, including recovery, rather than admiring individual components.
Buying a handover, not a miracle
SIOS fits among the specialists protecting stateful enterprise workloads: databases, ERP systems and applications whose data cannot simply be discarded when a server disappears. Its public customer examples include RSM Australia, Mavis Discount Tire and Toyo Gosei. Its partner network includes cloud providers, SAP, Microsoft and systems integrators.
Alternatives vary with the workload. Linux teams may evaluate Pacemaker-based stacks supplied through Red Hat or SUSE. SQL Server teams may consider availability groups or shared-storage failover clusters. SIOS’s claim to attention is application-aware recovery and flexible storage arrangements. The sensible comparison includes the team’s skills, supported configuration and operational burden.
The business model is commercial software. LifeKeeper v10 offers perpetual licenses, subscriptions and cloud marketplace purchasing. Support and consulting accompany the software business. The cost calculation also includes standby compute, storage, replication traffic and the work of keeping the recovery environment current. Saving on one database license does not make the second server free.
The target interval for restoring service. Detection, handover and application startup all belong in the calculation.
The tolerable gap in recovered data. A replication policy must match the workload’s requirements.
Network partitions need particular care. If two nodes lose contact, each can believe the other has failed. Both becoming active can compromise data consistency. SIOS documentation describes quorum, witnesses and fencing as protections against this split-brain problem. A replicated disk is useful; a clear decision about who may write to it is essential.
The annual allowance at 99.99% availability.
Approximately 52 minutes 34 seconds in a 365-day year. A mathematical budget, not a promise about any installation.
Rehearse the unremarkable
The discipline worth copying starts before procurement: decide the acceptable recovery time and data loss, identify dependencies, and separate systems that should survive different failures. Then test a real handover. A convincing diagram cannot tell you whether the application on the standby will start.
LifeKeeper v10.1, released in July 2026, moves further toward repeatable administration. It adds a Windows command-line interface for automated cluster management, centralized log viewing and SQL Server 2025 support. SIOS calls the release AIOps-ready. The concrete benefit to examine is whether an administrator can deploy and troubleshoot clusters more consistently.
The company’s September 2026 survey supplies a sobering counterweight to product language. Among more than 250 IT leaders in North America and the UK, 76% reported an outage lasting over ten minutes during the previous year despite HA/DR protection. It is a vendor survey, not a measurement of SIOS installations. Still, buying protection plainly leaves work to do.
For the customer paying an electricity bill, all this preparation should remain invisible. For the team running the payment system, invisibility takes effort: a working standby, a sensible replication policy, and a recovery procedure that has survived rehearsal. SIOS sells software for that effort. Its most persuasive outcome is a transaction completed without a story to tell.