SIOS APAC Portal

May 30, 2026	SIOS Enterprise Support Guide: What Your Plan Covers SIOS Enterprise Support Guide: What Your Plan Covers What’s Included in Your SIOS Enterprise Support Plan? Here are some quick tips for what is covered and not covered with Enterprise level support, and where to go for additional information based on three common scenarios. 24/7 Support for Critical System Downtime Scenario 1: System Down After Hours Joan’s team: It’s 7 pm EST on Sunday. The routine switchover between SIOS LifeKeeper cluster nodes should have been simple. But something unexpected happened, resulting in the switchover failure. Despite all of the team’s efforts to resolve the issue, the cluster remains down. Joan needs help, but she is not sure that her SIOS Technical support plan covers weekends or how long it will take to get a support person on the phone. Customers who have purchased (or renewed) their Enterprise level support prior to an incident have access to receive support 24 hours a day, 7 days a week. This support includes weekends and holidays to address *Critical Issues. Critical Issues mean down production systems or applications, where Customer data cannot be accessed using SIOS Programs. For all Priority 1 (critical) issues, where normal operation results in the loss of access to your production data, SIOS provides a 2-hour response time. If Joan has valid Enterprise support, she will be able to reach out to the SIOS support team, and her after-hours issue will be covered. Installation and Configuration Support* Scenario 2: Installation Assistance Needed Scott’s team: It’s 4 pm EST on Thursday. The approvals have been completed for the new infrastructure project, including the required high availability configuration for critical applications and data. At the kickoff, the stakeholders moved the date for go-live. As a result, the team needs to get the systems installed and configured quickly to avoid service interruption. Scott’s team knows how to configure the application and server, but they want to be doubly sure they install the HA solution correctly. They need help, but Scott’s not sure that their support plan covers help with installation errors. Since Scott’s team is in the deployment phase, the new infrastructure project involves systems that have not been validated or successfully put into production. If Scott’s team has valid SIOS Enterprise level support, he will have access to SIOS product documentation and installation pointers. However, assistance with installation and configuration is not covered under Scott’s Enterprise support, but he can contact his SIOS sales representative to arrange a paid Professional Services installation engagement. This engagement will ensure that Scott’s team gets the assistance they need to properly install, configure, and validate their cluster. SIOS provides a wide range of professional services designed to help customers quickly and cost-effectively implement, manage, and maintain their HA environments. Root Cause Analysis (RCA) After Failover Scenario 3: Post-Failover RCA Support Amol’s team: It’s 2 am EST on Tuesday. An alert has been sent out to the entire application team at AjaxBjax Corp. The cluster protecting the company’s most critical application system is conducting a failover. Amol checks the application dashboard and discovers that the failover was successful and all applications are functioning. However, Amol knows that management will want some explanations and assurances. Amol wants to make sure that all application services are up and functioning, but he isn’t sure that their support plan covers whatever this is. Amol’s team is looking for an RCA and the confidence that their system is going to continue to be operational. Amol’s data is accessible, and his application is fully functional. His system is not a critical down production server, nor a P1 issue. However, if AjaxBjax Corp has valid Enterprise support for their cluster, they will be able to reach out to the SIOS support team for guidance around the clock (US East), Monday through Friday, for RCA issues. Amol’s 2 am call will be routed to one of the knowledgeable SIOS support centers, where the team will begin working with Amol. Additional Questions About Contacting SIOS Support Amol and Joan were able to contact support via the Support Hotline (US: 877.457.5113; International: +1.803.808.4270) with coverage included by their Enterprise Support. Scott was able to receive the help he needed, not from the Support team, but through the purchase of services to assist with configuration and installation. But what about other scenarios, where can Scott, Amol, Joan, and others find more about their support levels and support details? Or whether their product has reached the maintenance or extended support phases? When you need to find additional information about your support agreement, you can consult the SIOS Technical Support Agreement (TSA), which is included with each order. The TSA is also conveniently located on our download site, and can be requested via an email to the SIOS Support Team at support@us.sios.com. Additionally, product schedules and support tier information can be found online at the Product Lifecycle page. Customers who already know what’s covered under their plan, but need help with a problem, answers to a general question, root cause analysis, the latest software, or pointers to more information can open a new case via the Support Portal website or via email to the Support Inbox at support@us.sios.com. Once your case is created, the team will work to provide timely responses and resolution. *Author: Cassius Rhue VP, Customer Experience* Reproduced with permission from SIOS
May 25, 2026	Why a Sandbox Environment Is Essential for High Availability Why a Sandbox Environment Is Essential for High Availability Convincing Management to Invest in Non-Production Infrastructure Convincing management to invest in non-production infrastructure is not a job for the faint of heart. Handled casually, discussions regarding an additional test cluster or sandbox environment quickly deteriorate into complaints about paying double for an environment (infrastructure, software, IT resources, applications, and licenses), and accusations that test clusters “generate zero revenue”. The cost discussion expands into a mixture of assertions that backup, DevOps, and software runbooks have rendered test environments obsolete. However, the cost of not having an exact replica of your production environment for testing is often exponentially higher than the cost of an additional test cluster. These extra costs often hide in the form of unplanned outages, corrupted data, emergency fixes, and stressed-out engineering teams. 10 Questions to Help Justify a Sandbox Environment If you are struggling to get budget approval for a proper sandbox environment, pose these 10 questions to your leadership team. They shift the conversation from the cost of a duplicate cluster to the value of ensuring the business from loss. 1. How much does downtime actually cost our organization? Start with the bottom line. If a deployment fails and the production HA cluster goes dark, what is the cost to the organization? How much do we lose per hour? What’s our company’s burn rate per business unit? This question moves the conversation beyond vague statements to the cost per minute of lost revenue, idle employee salaries during an outage, and the harder-to-measure cost of reputational damage. If a production outage costs $300,000 per hour, preventing just one four-hour outage annually saves $1.2 million. Armed with tangible business numbers, the ROI of implementing a sandbox to derisk a costly outage becomes crystal clear. 2. How many maintenance activities do we perform each month? It’s simple: frequency equals risk exposure. Risk exposure equals additional costs. If you are deploying updates, patches, or configuration changes weekly, you are rolling the dice 52 times a year. Refer back to question 1: How much would an hour of downtime due to a bad patch update cost the organization? Now multiply that by your maintenance frequency. As Tristan Allen, Associate Software Engineer at SIOS, reminds customers, a sandbox that is a replica of production provides an invaluable environment “where new features, configuration changes, and patches can be thoroughly tested. Beyond functional testing, a QA environment allows for process validation, performance benchmarking, load testing, and security validation. These are critical activities for identifying bottlenecks, vulnerabilities, or integration issues before they have the chance to impact end users or compromise your environment.” The velocity of releases and maintenance updates increases the necessity for a safety net. 3. How confident are we in deploying to production? Does the team hold its breath every time they touch production with an update? How many times have we heard the phrase, “It was only a one-line change”? Off by one and null pointer errors are small changes that have historically led to major downtime. How confident are you in your team’s ability to ensure newly deployed packages are free from coding errors, logic flaws, architectural issues, third-party incompatibilities, or sequencing mistakes? How confident is your team in the health of your production environment? If your production environment is brittle, a sandbox cluster allows you to validate the deployment process itself, significantly reducing the cost and stress of emergency rollbacks, as well as validating fixes beforehand. 4. What is our risk tolerance for applying security patches directly in production? Security patches are non-negotiable, but sometimes they conflict with existing libraries or configurations. Applying a kernel patch or a database update directly to production is a gamble. As VP of Customer Experience, we worked directly with a customer to roll back a kernel update applied directly to production. While the update fixed one problem, it had unexpected side effects that greatly impacted the storage layer, leading to deadlocks, application crashes, and other bottlenecks. If you are having a hard time justifying a full QA cluster, ask your management team: Are we willing to risk a critical business application to apply a security patch? A sandbox allows you to apply these patches in an identical environment first, ensuring that “fixing” security doesn’t “break” the business. Beyond patches, it allows you to deploy new applications and updates to explore any security vulnerabilities or risks that may arise. 5. What is the financial and operational impact of data corruption? Downtime is temporary; data loss can be permanent. Incompatible changes to underlying storage, application logic errors, or problems in device drivers can silently corrupt data in a way that isn’t immediately obvious. Do you want your production environment to be the place where you discover that the update to your backup tool means you can no longer back up or restore your critical application data? By the time you realize the error in production, you might be weeks deep into corrupted records. Or you may hit a crisis and realize that your backups cannot be restored on the newly updated software. A sandbox allows you to run data integrity tests, data migrations, schema updates, driver changes, and even replication software scenarios against a copy of real data, ensuring that if data is lost or mangled, it happens in a safe environment, not the one billing your customers. 6. Can we afford for third-party integrations to fail silently? Your application likely relies on APIs, third-party authentication, third-party applications, or some other form of dependency. These behave differently under load and especially in clustered environments. Incompatible changes often arise not from your code, but from how your code interacts with the infrastructure. If a change works on a developer’s laptop but fails when distributed across three nodes, that is a disruption that stops business. A sandbox catches the “it works on my machine” bugs before they reach the customer. 7. How prepared are we for a true DR scenario? Most organizations have a Disaster Recovery (DR) plan on paper, but a plan that hasn’t been tested is just a hypothesis. The only way to validate a DR strategy is to execute it, simulating a total site failure or data corruption event. Without a sandbox cluster, testing your DR plan requires you to target your production environment. This introduces risk, expense, dangerous logistics, and downtime. Without a sandbox cluster, you must intentionally take your revenue-generating systems offline to verify they can come back online. This requires massive coordination between network, storage, database, and application teams. The cost for this exercise in production resembles a running water meter on a leaky system. In addition to the downtime, the process of testing DR scenarios in production only introduces risk and complexity. The risk involves working with live data and making sure there is strict adherence to all the data protection steps. The complexity isn’t usually the failover—it’s the restoration. Once you have successfully failed over to a secondary site or backup node, getting the production cluster back to its original state (failback) is a complex, high-risk operation. Remind management that the cost of a sandbox would allow your teams to simulate catastrophic failures and execute full recovery procedures during business hours without impacting users. Teams could work together to refine the “Run Book”, find and resolve process flaws safely, and practice thoroughly so that when a real disaster strikes, the team is executing a well-choreographed routine rather than a dangerous first-time experiment. 9. How do we onboard new vendors and train existing teams? Exceptional organizations have an IT onboarding process for new team members, vendors, and service providers. These organizations understand that a well-structured onboarding framework is essential for new team members. They value and prioritize creating learning management systems and a culture ripe with comprehensive resources that help newcomers understand the critical HA environments they will be managing, maintaining, and updating. They also understand the value of continuous learning and a proactive approach to keeping the team’s skills sharp. Without a sandbox system that is a direct replica of production, your IT Onboarding must leverage your production clusters. That means the new college grad is learning how to run patch management, security software, and application updates in an HA environment on the company’s breadwinner. When they reach a spot that is unclear to them in the run book, or coincidentally missing, the cost to productivity and risk of reputational injury to them and the business can be devastating. In advocating for a sandbox environment, emphasize the nature of ongoing onboarding of vendors, partners, and managed service providers, and the risks of not having a place for those individuals and teams to learn about the business or explore procedures. If your organization does not have a sandbox system, consider asking your leadership a few questions: Where will our new team members go to understand the environment they will be managing, maintaining,g and updating? How will they keep their skills current? What systems do we utilize to properly onboard the next team when necessary? 10. Is the cost of the HA tool insurance cheaper than the disaster? Finally, address the elephant in the room: the cost of the tools and hardware. High Availability clustering software and the associated compute costs are not free. However, compare the annual cost of the sandbox license and infrastructure against the cost of a single major downtime, rollback, or data loss event. In almost every scenario, the cost of prevention will be a fraction of the cost of the cure. A Sandbox Environment Is a Business Continuity Investment As Tristan Allen, Associate Software Engineer at SIOS, concludes in his blog: QA and production environments play a vital role in keeping systems running smoothly. By keeping environments separate, testing thoroughly, and managing deployments carefully, IT teams can reduce downtime, maintain high availability, and make transitions between updates seamless. If your management team is having trouble understanding the benefits of a full sandbox, try asking them a few of these questions. By asking these questions, you move the discussion away from an overly simplified cost conversation and toward a focused dialogue related to business continuity, making the approval of that budget line item much easier for management to sign. A sandbox cluster is not a luxury item; it is a risk mitigation asset for the business. Request a demo to see how SIOS helps you reduce downtime risk with resilient high availability and disaster recovery solutions. *Author: Cassius Rhue, VP of Customer Experience at SIOS* Reproduced with permission from SIOS
May 19, 2026	Inheriting DataKeeper Inheriting DataKeeper What It Means to Inherit a DataKeeper Environment The concept of inheritance often brings to mind assets passed down from one individual to another. Webster and other dictionaries define inheritance as: An inheritance consists of the assets, property, and sometimes debts left behind by a deceased person, distributed to beneficiaries via a will, trust, or state intestacy laws. It commonly includes cash, real estate, stocks, bonds, personal items (jewelry, cars), and business interests.” In the world of IT, inheritance takes on a digital twist. When a Systems Administrator inherits a cluster that utilizes tools like DataKeeper, they’re not dealing with tangible assets like jewelry or real estate, but rather digital resources—think configurations, roles, and critical volume resources. And while this inheritance is hopefully the result of someone retiring from the company or receiving a well-earned promotion, we’ll cross our fingers it isn’t due to someone transitioning to that “great BIG data center in the sky.” (Yes, humor is a coping mechanism for IT professionals!) So, if you’re the lucky recipient of an existing 1×1 cluster with a SQL Server role and associated DataKeeper Volume resources, where do you begin? What steps should you take to ensure a smooth onboarding and knowledge transfer process? To help guide that transition, here are some key questions you should ask yourself or your Management Team: Account Administration Questions Account Manager Details Who is the current Account Manager responsible for this account? What are their contact details (email, phone, etc.)? Licensing Information What is the status of your licensing agreement, contracts, and renewals? Are there any upcoming licensing expirations or renewal deadlines one should be aware of? Where can I access the licensing portal, and do I have the necessary credentials? DataKeeper Administration Questions Comprehending the Environment Assess the current infrastructure, to include Windows Server Failover Clustering setup, servers, storage, etc. What current workloads and applications are DataKeeper protecting? Configuration and Management Become familiar with DataKeeper configuration. What Asynchronous and Synchronous mirror types are in use? How are the cluster nodes set up? What storage is involved? Maintenance and Software Updates How to stay informed about new releases, patches, and updates for DataKeeper? Testing Failover and Recovery Occasionally, test failovers to ensure HA and DR configs are working as expected. Is the mirrored data consistent and recoverable in the event of a disaster? Understand Resource Ownership and Dependencies Once you’ve understood as much as possible about your inheritance, your next step is to begin taking care of what you’ve been given, as depicted in the illustration above. When “inheriting” ownership of a SQL Server Cluster, it is crucial to identify and communicate with all cross-functional teams impacted by cluster administration. A few key areas, as there are numerous, to focus on include: SQL Server or Application Team Being proactively notified about any planned changes to SQL Server names or instances Informed of large SQL inserts or operations that may impact cluster performance Provide details on the locations of the database files, backups,s and snapshots. Networking Team Communicate plans to move a SQL role or related resource to a different network. Share information on new IP addresses or other network-related changes that could affect cluster operations Storage Team Being cautious when making changes to the Source and Target volume (e.g, resizing, formatting, or adding partitions) for these can have an impact on DataKeeper replication. Is there ample bandwidth for the existing mirror? Are you able to collaborate with the Networking Team to ensure bandwidth is sufficient, isolated from other applications to avoid bottlenecks? Why Runbooks Matter in a DataKeeper Environment: Runbooks are an essential part of a smooth operation and provide great resolutions for environments utilizing DataKeeper, for cluster administrators and related technologies. Ideally, a well-crafted runbook should be a “living document” that evolves over time, reflecting changes in infrastructure, workflows, and best practices. If previous administrators have done the due diligence, your runbook should have comprehensive coverage in the following areas: Break/Fix: working through known issues, which could be anywhere in the “stack,” e.g, Physical Layer all the way up to the Application Layer Workflows: deploying software and managing routine day-to-day cluster operations Maintenance: how is patch management performed, database backups, etc Vendor support: how to reach SIOS, Microsoft, AWS, and other providers Most importantly, when to “reach out” to them? Key Takeaways For Inheriting DataKeeper This blog highlights several important talking points for navigating such transitions, including account administration, resource ownership, cross-functional collaboration, and the value of runbooks. However, it’s important to note that these are just a few considerations among many others that may fall outside the scope of this discussion. Every environment is unique, and successful cluster administration requires a thorough understanding of the specific infrastructure, dependencies, and workflows involved. Enjoy your “inheritance” . . . Don’t spend it all in one place . . . Request a demo to see how SIOS DataKeeper can help simplify cluster administration and support high availability. Author: Greg Tucker, Senior Product Support Engineer at SIOS** Reproduced with permission from SIOS
May 13, 2026	High Availability vs. Fault Tolerance: Key Differences Explained High Availability vs. Fault Tolerance: Key Differences Explained High Availability vs. Fault Tolerance is a common comparison when evaluating system designs that can be used together to create an infrastructure that is always on and functioning. The goal of High Availability is to ensure minimal downtime, whereas the goal for fault tolerance is to allow an infrastructure to remain running even when a failure occurs. What Is High Availability? High Availability serves as a way to ensure minimal downtime by guaranteeing that systems will be operational for at least 99% of the time. This is achieved through continuous monitoring of the health of an infrastructure. High Availability can be three (99.9%), four (99.99%), or five (99.999%) nines. Each of the nines represents an expected uptime of an infrastructure. The standard is 99.99%, where the expected downtime per year is 52.60 minutes. Software like SIOS LifeKeeper and DataKeeper provides 99.99% High Availability through monitoring and preventing long downtimes by automating failovers and replicating data. What Is Fault Tolerance? The purpose of Fault Tolerance is to eliminate a single point of failure to ensure that an infrastructure keeps running in the event of failure. This ensures the prevention of downtime and data loss. Fault Tolerance can be achieved through error detection, load balancing, and/or microservices. For example, in the event of high traffic entering the network, load balancing is in place to reroute traffic to other servers, preventing failures caused by a heavy load. High Availability vs. Fault Tolerance Cost Comparison In a High Availability vs. Fault Tolerance comparison, fault-tolerant infrastructure typically costs more than a high-availability infrastructure due to the increased amount of software and hardware used. Maintaining an infrastructure that is continuously running and experiencing almost negligible downtime will require more hardware and software redundancy. High Availability Use Cases High Availability in Financial Services Banks aim to maintain high availability to allow continuous processing of financial transactions. To do so, the typical environment requires databases and a configuration where a failover is possible in the event of a failure. High Availability for Streaming Services Streaming services, especially live, aim to provide continuous audio and/or video content to maintain their users. This, in turn, provides a seamless experience for users, allowing them to continue to use and operate the product. Fault Tolerance Use Cases Fault Tolerance in Healthcare Many critical devices used in hospitals, life-support systems, ventilators, dialysis machines, etc, are always running 24/7. This is to ensure that patients are provided with uninterrupted life-saving care. Fault Tolerance for Websites Websites, like e-commerce platforms, that incur high amounts of traffic will host different parts of the sites on multiple servers. In the event of a failure on one server, the site will still be running and accessible. Conclusion: High Availability vs. Fault Tolerance While looking at High Availability vs. Fault Tolerance, it is clear that the two serve different purposes. Fault tolerance aims to have uninterrupted time in the event of a failure. At the same time, High Availability aims to ensure minimal downtime through quick recovery. As organizations evaluate high availability vs. fault tolerance, SIOS helps simplify the path to stronger uptime and faster recovery. Request a demo to learn more. Author: Alexus Gore, Customer Experience Software Engineer at SIOS Technology Corp. Reproduced with permission from SIOS
May 8, 2026	Business Continuity Planning for High Availability and Disaster Recovery 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

Results 1-5 of 1020
Page 1 of 204 >

Join Our Mailing List

First Name Last Name Email Address
Search