disaster recovery Archives - SIOS SANless clusters

Webinar: From Panic to Proactive: A Beginner’s Guide to High Availability

August 2, 2026 by Jason Aw Leave a Comment

Webinar: From Panic to Proactive: A Beginner’s Guide to High Availability

A critical server failure shouldn’t mean a frantic, hours-long outage. If you are a systems administrator, a new DBA, or an “accidental” DBA tasked with keeping the lights on, you cannot afford to leave your uptime to chance.

In this beginner-friendly on-demand session, we break down the fundamentals of high availability. You will discover exactly what causes unexpected outages, how automatic failover works, and how modern technologies like clustering and cloud infrastructure keep your critical systems running 24/7.

Reproduced with permission from SIOS

LifeKeeper Generic Applications for High Availability and Disaster Recovery

June 4, 2026 by Jason Aw Leave a Comment

LifeKeeper Generic Applications for High Availability and Disaster Recovery

Keys to Success for Protecting Business-Critical Applications

High Availability and Disaster Recovery have to cover a broad range of use cases. There are as many use cases as there are organizations, far exceeding the capabilities of any single High Availability and Disaster Recovery solution to provide out-of-the-box support for every scenario. While many common applications have a wide array of High Availability and Disaster Recovery solutions available, more specific use cases limit the selection available to protect business-critical applications.

Of course, LifeKeeper cannot cover every use case out of the box. LifeKeeper, however, provides a versatile and flexible framework that can be adapted to a wide range of use cases to remedy this limitation. While powerful, this framework can appear complex to an outsider. This blog is here to help give a leg up when starting to conceptualize a Generic Application Recovery Kit for your specific use case.

Conceptualizing Applications and Defining the Approach

Asking the Smallest Question About Application Health

System administration and software engineering are both fields with lots of nuance. There can be so many different elements behind a question that a simple, straightforward answer can be difficult to obtain. Conversational, this can be easily navigated. In code, complex answers are difficult to accommodate. Asking the “smallest” question is the practice of targeting an inquiry to the smallest element possible, while ensuring that the answer has clearly defined criteria.

“Is the application running?” This is a “big” question; it may require a verbose answer. Yes, the application is running, but it is not responding. Yes, the application is running, but it is running on that other system – not the one you’re talking about. The criteria of the answer are ambiguous, and the answer is nuanced – a level of detail that developers would rather not have to handle.

“Is the application’s process running, and is the application actively responding to queries?”

Though longer to say, it is a smaller question. It clearly defines the conditions under which the answer is yes or no. While this change is an improvement, it is not yet the “smallest” question. The previous falls victim to the same pitfall of asking “Are both X and Y true?” A yes or no answer cannot give the level of detail to determine the truth of X and Y independently. The smallest question requires specificity; it must provide full insight into the status of the smallest element of the greater whole. “Is the application’s process running on the desired system?” That’s a small question – in this case, this is the smallest question. Keep in mind, there might be multiple “smallest” questions – in this example, “is the application responding to queries” would also qualify.

While questions can be broken down almost indefinitely, there is a limit. Asking “the smallest question?, comes with the implication of “Asking the smallest question that still provides useful/actionable information”. Asking “Am I on the train to Philadelphia?” is sufficient; going further to ask “Am I on the train to Philadelphia, and which direction is Philadelphia?” provides more information – but it is not actionable. I cannot change the direction of the train. I know from the answer to “Am I on the train to Philadelphia?” if I need to call into work to inform my boss that I will be late.

Though clear in this example, this is less obvious when developing for a generic application. Throughout the process of protecting the generic application, one must still keep perspective on the bigger picture. This, like anything else, is a skill – with practice and collaboration comes the ability to determine when a question is the smallest question, and when further nuance stops providing additional useful information.

Broad questions that have been broken into smaller, specific, and targeted inquiries about individual elements are the basis on which Generic Application Recovery Kits are built. Each “big question” can be answered through a composite of the answers provided for each of the elements implicated within.

Once the questions are broken into their smallest elements, the information that needs to be relayed becomes significantly clearer. Knowing the information needed, the remaining work in developing a Generic Application Recovery Kit is all a matter of how to get the information that is needed from the information that is provided. One must work with the information that is given.

Working with Application APIs and LifeKeeper APIs

Often, applications provide Graphical User Interfaces (GUIs) to display information or show changes that occurred to the application. While fantastic for human-driven use, this is less useful when the administration is being done by an application. GUIs are for people to use, and applications (foregoing a massive amount of programming effort and unnecessary complexity) are not equipped to interface with the GUI of another application as a human would. For the purposes of LifeKeeper and a Generic Application Resource, the exchange of information between the Generic Application Recovery Kit’s action scripts and the application being protected must be done by an Application Programming Interface, or an “API”.

LifeKeeper provides its own API for interacting with the LifeKeeper, the hierarchy, and the resources within the hierarchy. In the case of LifeKeeper’s API, the command-line utilities contained within the product are the easiest to use in a Generic Application. As a general recommendation, only the command line utilities outlined in LifeKeeper Product Documentation (Linux Commands Documentation / Windows Commands Documentation) should be used. Even with this recommendation, these commands should be used with care and attention to detail to ensure that unintended actions are not taken.

Of course, LifeKeeper is not the only factor in the Generic Application. The application being protected will also need an API presented so action scripts can leverage the application’s API to achieve the desired outcomes. Developing a Generic Application Recovery Kit does require knowledge of the protected application’s API and the use of that API within the action scripts that compose the Generic Application Recovery Kit.

Using Return Codes and Output Streams in Recovery Scripts

Whether it is the API for LifeKeeper or the protected application, information will be primarily output in two ways:

Return Codes
Output Streams (sometimes called “STDOUT/STDERR output” or just “terminal output”)

How Return Codes Help Determine Success or Failure

Return codes, in the broadest sense, provide a quick way to see if a utility succeeded or failed. Typically (In the context of a shell environment), a return code of 0 indicates success, while a nonzero return code indicates failure.

Depending on the application, the exact value of the return code may give more insight into the error encountered. Often, the outcome of actions performed via an application’s API can be surmised simply by checking the return code.

In more nuanced cases, it may be that the return code is simply used to tell the program which course of action to take following a call to the application’s API. Return codes are especially useful when dealing with utilities that concern the state of some underlying element.

How Output Streams Provide More Detailed Application Information

Output Streams, while more complex to make use of in a program, are sometimes necessary for information exchange or to verify outcomes. If running a utility to get the system’s hostname, the return code alone will not indicate what that hostname is, unless the utility was successful in retrieving the hostname. In some cases, an API utility may return a successful return code if the requested information was obtained, but that information has to be evaluated for validity based on the circumstances.

Whether using return codes or output streams, developing a Generic Application requires the use of the information at hand. When thinking of ways to achieve resource actions (outlined in the next section) or determine information about an application or LifeKeeper resource, try to think in terms of return codes and output streams, not GUI interfaces. It can be helpful to imagine trying to convey information over the phone. This is to say, information is best communicated, actions are best defined, and scenarios are best handled when the inputs and outputs of utilities are reported exactly as they are to be provided as input or are reported as output.

Building a Foundation for Generic Application Protection

This section kept the strategies very conceptual. These strategies lay the foundation for thinking about an application through the responses provided to questions and actions issued upon that application. Going forward, the approach will become more specific to LifeKeeper and the process of creating a Generic Application Recovery Kit. In the meantime, these strategies develop like any other skill, through practice. In technical communication, writing procedures, or any capacity in which you find yourself, practicing these conceptualization strategies will benefit not only in the short term but over time as well.

Need help protecting a business-critical application that does not fit a standard high availability model? SIOS can help you evaluate your environment and determine the right LifeKeeper approach. Request a demo today.

Author: Philip Merry, L3 Support Engineer at SIOS Technology Corp.

Reproduced with permission from SIOS

Business Continuity Planning for High Availability and Disaster Recovery

May 8, 2026 by Jason Aw Leave a Comment

Business Continuity Planning for High Availability and Disaster Recovery

Why Every Business Needs a Strategy for Business Continuity and High Availability

Modern businesses rely on applications and data to operate. When those systems go down, the impact can be immediate, affecting productivity, revenue, and customer trust. That is why organizations need a strong Business Continuity and High Availability strategy to ensure critical systems remain operational even when infrastructure fails.

By combining resilient infrastructure with application-aware high availability solutions, businesses can minimize downtime and maintain consistent uptime during unexpected disruptions.

What Is a Business Continuity Plan?

Business continuity refers to an organization’s ability to maintain operations during and after a disruption. Failures can occur for many reasons, including hardware problems, software bugs, cyberattacks, or natural disasters.

Without a continuity plan, even a short outage can interrupt services and cause major operational setbacks. A strong business continuity plan ensures critical applications, systems, and data remain accessible when they are needed most.

Key Components of a Business Continuity Plan

A typical business continuity plan includes:

Risk assessment to identify potential threats
Business impact analysis to determine critical systems
Communication plans for employees and stakeholders
Recovery procedures for IT systems and applications
Regular testing to validate recovery processes

These components help organizations prepare for disruptions before they occur.

High Availability Explained

High Availability (HA) refers to designing systems that remain operational even when components fail. This is often achieved through clustering, redundancy, and automated failover that shifts workloads to standby systems.

Application-level high availability tools can monitor specific applications and automatically restart or fail them over if a failure occurs, reducing downtime and maintaining service continuity.

Importance of Uptime Management

Effective uptime management requires continuous monitoring and proactive infrastructure design. Organizations must track system health and ensure backup systems are ready to take over when problems occur.

Common uptime management practices include:

Monitoring application and server health
Implementing redundancy across systems
Automating failover processes
Maintaining consistent patching and updates

These practices help keep mission-critical systems available.

Benefits of High Availability in Business

High availability delivers several key benefits:

Reduced downtime for critical applications
Improved customer experience and reliability
Faster recovery from failures
Greater operational resilience

For organizations that rely on digital services, maintaining high availability is essential for business continuity.

Disaster Recovery Planning

What is IT Disaster Recovery?

While high availability focuses on minimizing downtime during localized failures, IT disaster recovery addresses larger incidents such as data center outages or regional disruptions.

Disaster recovery strategies ensure systems and data can be restored quickly after a major event.

Steps to Develop an Effective Disaster Recovery Plan

Effective disaster recovery planning typically includes:

Identifying critical applications and infrastructure
Defining recovery objectives such as RTO and RPO
Implementing backups and replication systems
Documenting recovery procedures
Testing recovery scenarios regularly

These steps help organizations recover quickly and avoid prolonged downtime.

Load Balancing for Performance and Reliability

Load balancing distributes workloads across multiple servers to improve performance and reliability. By spreading traffic across systems, organizations prevent individual servers from becoming overloaded.

Types of Load Balancing Techniques

Common load balancing techniques include:

Round-robin request distribution
Least-connection routing
Geographic traffic distribution
Health-check-based routing

Load balancing supports high availability by ensuring traffic can automatically shift to healthy systems when a server fails. This improves both performance and reliability for users.

Data Replication Strategies

Data replication ensures that critical data exists in multiple locations. If a system or site becomes unavailable, another copy of the data can be used to restore operations.

Common data replication strategies include:

Synchronous replication for real-time protection
Asynchronous replication for distributed environments

Snapshot replication for periodic backups

Best Practices for Implementing Data Replication

To ensure reliable replication:

Replicate data across separate infrastructures or regions
Align replication with recovery objectives
Monitor replication performance
Regularly test failover processes

These practices help ensure data is available when disruptions occur.

Strengthening Business Continuity and High Availability

A strong strategy for Business Continuity and High Availability helps organizations keep critical applications running, even during unexpected failures. Combining high availability architectures, disaster recovery planning, load balancing techniques, and data replication strategies creates a resilient IT environment.

Businesses should regularly evaluate their high availability and disaster recovery strategies. Implementing application-level high availability solutions, automated failover, and robust replication systems can significantly reduce downtime and protect critical operations.

Strengthen your business continuity planning with SIOS high availability solutions designed to minimize downtime, automate failover, and keep critical applications running. Request a demo today.

Author: Ben Roy, Marketing Specialist at SIOS

Reproduced with permission from SIOS

Disaster Recovery Planning in an Unpredictable World

April 4, 2026 by Jason Aw Leave a Comment

Disaster Recovery Planning in an Unpredictable World

Computer systems and computerized infrastructure have become a load-bearing part of a modern business environment. As such, the potential for downtime is not just annoying – it is costly. Though the world is unpredictable, having an emergency plan in place through effective disaster recovery planning can ensure that an unexpected issue does not lead to an unexpected problem. This is the role of a High Availability and Disaster Recovery solution.

Understanding High Availability and Disaster Recovery

High Availability and Disaster Recovery is a multi-faceted endeavor of mutually supportive efforts. Though these concepts work in tandem to uplift one another, it is important to understand the boundaries between them.

What is High Availability?

High Availability refers to the capacity of a system, application, or other infrastructure component to readily continue operation. This encompasses the ability of an infrastructure component to be restarted, migrated, or otherwise recovered with minimal loss or regression in the operational state.

This is to say, the infrastructure is able to continue serving the designated role with access to up-to-date information. Additionally, highly available infrastructure may accommodate the ability for multiple infrastructure components to act in a primary role to provide availability.

What is Disaster Recovery?

Disaster recovery refers to the capacity of a system, application, or infrastructure component to withstand a catastrophic failure. Often, disaster recovery is concerned with the catastrophic and irrecoverable loss of some infrastructure component.

A simple example of a disaster recovery solution can be seen any time a data backup is taken and stored off-site. Doing this to protect the data against building-wide disasters that would make the original storage media unrecoverable meets the criteria of a disaster recovery solution, though via an implementation that leaves room for improvement.

How High Availability and Disaster Recovery Work Together

When combining High Availability and Disaster Recovery, both can work to aid the other’s stated goals. A High Availability solution accommodates the ability to ensure systems can resume their operative role in a timely manner, and the infrastructure that can resume the system’s operative role is frequently a part of the disaster recovery solution.

When planned accordingly, the ability to migrate workloads to a healthy infrastructure can enable a disaster recovery solution to operate quickly and effectively, minimizing downtime. These two elements work hand in hand to produce environments that prioritize resilience and uptime equally.

The Real Cost of Downtime

Every computer system, infrastructure component, or other element of a production environment is susceptible to failure. When failure occurs, it is easy to measure the opportunity cost for lost revenue, reduced productivity, or costs of remediating the issues from which downtime originated. These costs alone posed an average cost of $300,000 or more per hour of downtime, a figure cited by 91% of medium to large-sized companies estimating the cost of downtime, as reported in a study performed by International Technology Intelligence Consulting in 2024.

Often not considered, though, is the “soft cost” of downtime. Outages can erode customer confidence, blemish the reputation of an organization, and apply additional pressure to the personnel responsible for the environment. Though downtime does pose a very real and very immediate cost to business, the ripples of such an occurrence may send shockwaves through a business for months or years to come.

Make Resilience a Design Requirement

Infrastructure reaches the peaks of High Availability and the highest capacity for disaster recovery when it is designed with the intention of being a highly available environment that has a strong disaster recovery plan.

The first stage of honoring HA/DR as a design requirement entails setting realistic expectations. Often, these expectations can be summarized via the “Recovery Point Objective” (RPO) and “Recovery Time Objective” (RTO).

To briefly describe these metrics:

Recovery Point Objective describes the data that an organization can stand to lose when restoring from a backup
Recovery Time Objective describes the desired amount of time before an unavailable environment is able to return to operation.

Defining these metrics naturally sidesteps a common issue. As systems are prioritized by their HA/DR needs, systems that are more resilient to downtime can make use of simpler implementations. Systems that require extremely low RTO and RPO metrics, in turn, can be allocated more effort to ensure that the solutions in place on these systems are equipped to meet the higher operational standards.

Use Automation to Reduce Risk in Disaster Recovery Planning

When addressing the strategies for High Availability and Disaster Recovery, the topic is often business-critical systems. These systems often require speedy issue resolution performed in a reliable manner so that an issue does not spiral out of control. Though the personnel responsible for these systems are experts in the nuances of the environment, the potential of human error during issue resolution is an avoidable risk factor.

A robust High Availability and Disaster Recovery solution can incorporate automated failure detection along with automated recovery actions. Not only is the response faster when the issue is automatically detected and executes a recovery plan in kind, but an automated response also takes action methodically and efficiently without the possibility of human error.

Build Redundancy Beyond Technology

Though it is important to design with HA/DR in mind and ensure that solutions can provide automated responses, there is still a human element to designing, creating, and maintaining critical systems. The key to leveraging personnel in these solutions is to allow teams to work in a low-stress environment that allows for careful and methodical problem-solving approaches. When a person is involved in any work, the outcomes should undergo a validation process to ensure that the solution functions as intended.

Even further than the conditions in which work is done, it is also important to ensure that personnel have access to the knowledge that they need to work effectively. If only one person on a team is capable of a particular maintenance task, then there is potential for a gap in operations should they become unavailable.

Planning for operational continuity extends beyond on-system considerations. Ensuring that teams operate to reduce knowledge silos and can put their outcomes to the test before moving into production can protect systems by avoiding issues entirely.

Disaster Recovery Planning Best Practices for Resilient Systems

While there is no one-size-fits-all approach to implementing High Availability and Disaster Recovery solutions, there are guidelines and best practices that can help build out a disaster recovery planning strategy that suits your organization. The aforementioned points serve as a great foundation. Additionally, improvements can be found via some generally applicable goals such as finding and eliminating single points of failure, documenting processes with clear roles and responsibilities, maintaining an identical QA copy of the production environment to validate procedures, distributing systems across geographically distinct regions, and frequently reviewing and updating documentation.

Preparing for the Next Disruption with Disaster Recovery Planning

Disruptions are inevitable, and no organization wants to experience an outage from a failure that could have been predicted and avoided. Taking an approach of intentional planning and implementing a layered solution to provide environments with High Availability and Disaster Recovery ensures that, whether predictable or not, an environment is prepared to weather issues and continue operating at full capacity, so business can operate without a hiccup.

Request a demo to see how SIOS high availability and disaster recovery solutions help protect critical systems and keep your business running.

Author: Philip Merry, SIOS Technology Corp.

Reproduced with permission from SIOS

How To Improve Customer Satisfaction in Technical Support

March 18, 2026 by Jason Aw Leave a Comment

How To Improve Customer Satisfaction in Technical Support

We have customers all over the world. We speak different languages; we are in different time zones; we are in different countries. But there are many things that we have in common when it comes to technical support. We all want and expect the best support when we have problems and need help. What does wanting and expecting the best support actually mean for an IT team?

6 Customer Expectations for a Technical Support Team

Here’s what our customers tell us they expect from a Technical Support Team.

Listen to the Customer

Customers (just like everyone else) like to be listened to. When talking to a customer, it is important to let the customer describe the problem. As a Support engineer, take notes, listen to what the customer is describing, and ask follow-up questions to gather important information. Do not interrupt the customer while they are talking. To confirm you understand what the customer stated, summarize what the customer told you. Summarize actions and make sure everyone is on the same page. Don’t assume you know the problem before the customer has described it.

Talk to a Real Person

Customers still prefer to talk to a “real” person and not an automated voice / AI/ ChatBot. Customers like talking to a support agent right away who knows the product and not just following a script. Nothing is more frustrating than when you call to get help with a problem you are experiencing, and you have to go through multiple automations to try to get to a “real” person. Many times you end up going in circles and arrive back to the scenario in which you started! Valuable time can be quickly wasted trying to get a “real” person on the phone to help you. Customers calling in for help strongly prefer setting up a video conference to share the problem live with a support team. A picture is worth 1000 words! In our experience, trying to help customers without a visual and without asking “live” questions adds to the length of time to solve a problem.

Availability 24 x 7

Customers are all around the world and want to contact support at any time of the day or night. We offer around-the-clock support every day of the week. To accommodate this, we have multiple teams around the world that cover 24 hours a day, every day of the week. When customers need us, we are there for them. We have procedures in place to escalate cases when our team members need immediate assistance on critical downtime issues affecting the customer’s business. Our customers use our High Availability and Disaster Recovery software, and our Technical Support team reinforces this goal by being ready to provide assistance whenever we are needed.

Experienced Support Engineers

Customers don’t have time to get on the phone with a person who can’t help them and needs to pass the call to someone else. Customers want to talk to support engineers who can assist with their questions and problems. At SIOS, we make a point to ensure that customers are quickly put in contact with an experienced member of our technical support team so the issue can be addressed as soon as possible. Based upon our Customer Surveys, customers love our technical support team! Our support team has an average of 16 years of total support experience; this expertise allows issues to be addressed quickly and often without having to escalate cases to another group. Customers appreciate it when they are met with experienced personnel who can join a video conference and provide real-time assistance based on years of experience.

Be transparent

Customers appreciate transparency. They want to know reality. Don’t make promises that you cannot keep. Always ensure that the customer understands what you are going to do to help them solve the problem and when you will be getting back in touch with them. Explain the steps that need to be done to the customer as you go, and ensure that the steps are approved by the customer before you execute them. Many customers need to get pre-approval prior to implementing changes to their systems. In pursuit of transparency, it is important to give the customer frequent updates that give insight into the support process. Even if your update is, “We are still analyzing the logs”, tell the customer this to keep them updated. Don’t tell them what you think they want to hear; tell them the truth.

Customer Surveys

For every case customers open with technical support, a survey is sent to the customer when the case is closed. This gives the customer an opportunity to provide feedback so our teams can continuously improve our products, documentation, and support. Our support team looks at completed customer surveys at least once a week and responds to customers who have concerns, ideas, and improvement suggestions, letting them know what actions we took on their feedback. Customers often thank us for resolving their issues quickly and for demonstrating our commitment to their success by following through on the notes they leave us after the case is closed.

What Customers Expect from a 24/7 HA/DR Technical Support Team

Customers reaching out for technical support on HA/DR products want to know they are being heard by a real person, not a bot. They expect to talk to experienced agents who actually know how to fix their problems and who stay transparent about what’s happening every step of the way. By offering this human touch with 24/7 availability, we show our customers that we are always there when they need us. Today’s technical support isn’t just about solving a ticket; it’s about building trust, listening, and being reliable and honest whenever customers need assistance.

Looking for a technical support team that understands HA/DR? Schedule time with a SIOS HA expert to see how we deliver high availability, automated recovery, and reliable cluster deployments.

Author: Sandi Hamilton, Director of Product Support Engineering at SIOS

Reproduced with permission from SIOS