KUALA LUMPUR: Malay­sian busi­nesses are urged to move bey­ond rely­ing solely on data backups and instead pri­or­it­ise full dis­aster recov­ery (DR) read­i­ness to with­stand dis­rup­tions in 2026.

Backups vs. Recovery

Malay­sian web host­ing com­pany Exa­bytes chief oper­at­ing officer Guan Tian Lai said many organ­isa­tions often mis­take hav­ing backups with being pre­pared, and that backups only con­firm that data cop­ies exist, not that oper­a­tions can be restored effect­ively.

“Backups are not the same as recov­ery. Backups tell you a copy of data exists. Dis­aster recov­ery determ­ines whether you can restore access, ser­vices, and oper­a­tions within an accept­able time and with accept­able data loss.”

“The gap between those two is where Malay­sian busi­nesses lose hours, money, and cus­tomer trust, even when they believe they did the right thing,” he said in a state­ment on Fri­day in con­junc­tion with World Backup Day.

Guan said most organ­isa­tions only dis­cover weak­nesses in their dis­aster recov­ery plans dur­ing an actual incid­ent. Com­mon causes of down­time in Malay­sia include human error, sys­tem mis­con­fig­ur­a­tions, cre­den­tial com­prom­ise and ser­vice pro­vider out­ages.

“These exposes the same weak­ness: recov­ery is rarely designed, tested, and owned as a dis­cip­line,” he said.

He also poin­ted to rising cyber­se­cur­ity threats includ­ing ransom­ware as a grow­ing con­cern. Malay­sia’s national incid­ent response centre has repor­ted an increase in ransom­ware-related incid­ents in early 2026, along­side broader warn­ings that cyber threats are becom­ing more soph­ist­ic­ated with increased cloud and arti­fi­cial intel­li­gence adop­tion.

Recov­ery Time Object­ive (RTO) and Recov­ery Point Object­ive (RPO)

Guan stressed that busi­ness lead­ers must under­stand two key met­rics in dis­aster recov­ery plan­ning — Recov­ery Time Object­ive (RTO) and Recov­ery Point Object­ive (RPO).

RTO defines how long a busi­ness can tol­er­ate down­time, while RPO determ­ines how much data loss is accept­able.

“These are not IT terms. They are busi­ness decisions. If your billing sys­tem can be down for eight hours, that’s an RTO decision. If your orders can only lose five minutes of data, that’s an RPO decision.

“And if you’ve never defined those tar­gets or never tested whether you can meet them, then “hav­ing backups” may not pro­tect you from dis­rup­tion,” he said.

He added that fail­ures dur­ing incid­ents are often not due to miss­ing backup files, but weak­nesses in exe­cu­tion. These include untested res­tor­a­tion pro­cesses, over­looked sys­tem depend­en­cies, unclear recov­ery pri­or­it­ies and restric­ted access dur­ing emer­gen­cies.

Backup-as-a-Ser­vice (BaaS) and Dis­aster Recov­ery-as-a-Ser­vice (DRaaS)

Guan also cau­tioned against con­fus­ing Backup-as-a-Ser­vice (BaaS), which focuses on data stor­age, with Dis­aster Recov­ery-as-a-Ser­vice (DRaaS), which ensures full res­tor­a­tion of busi­ness oper­a­tions.

To improve resi­li­ence, he recom­men­ded that organ­isa­tions identify crit­ical sys­tems, define recov­ery tar­gets, secure backup integ­rity and develop clear recov­ery run­books out­lining roles, pri­or­it­ies and com­mu­nic­a­tion plans.

Reg­u­lar test­ing is equally import­ant, with at least two dis­aster recov­ery drills annu­ally and one full res­tor­a­tion test to ensure pre­pared­ness.

“World Backup Day is a reminder to back up data, but the more import­ant ques­tion is whether busi­nesses can recover. A backup is neces­sary, but it is not suf­fi­cient,” he said.

He added that con­duct­ing a dis­aster recov­ery drill can provide more insight into an organ­isa­tion’s resi­li­ence than routine sys­tem mon­it­or­ing.

“Because the real risk is not that something breaks, but that when it does, there is no prac­tised way to restore oper­a­tions quickly and effect­ively,” he said.

Full article by The Borneo Post (Sarawak).

By Guan Tian Lai, COO of Exabytes

Imagine a typical workday suddenly disrupted. A critical system goes down, employees are locked out, customer orders stall, and support lines start ringing non-stop. In the midst of the chaos, someone says, “It’s fine, we have backups.” It sounds reassuring—but in reality, that statement often hides a dangerous misconception.

Difference between Backups & Disaster Recovery

Backups are not the same as recovery. A backup only confirms that a copy of data exists. Disaster recovery, on the other hand, determines whether a business can restore its systems, applications, and operations within an acceptable timeframe—and with minimal data loss. The gap between these two is where many organisations lose valuable hours, revenue, and customer trust.

This distinction is becoming increasingly critical as Malaysia’s digital economy grows more complex. Businesses today face a range of disruptions, from human error and system misconfigurations to credential breaches and cloud service outages. These are not rare, large-scale disasters—they are everyday risks that expose a deeper issue: most organisations are not truly prepared to recover.

Warnings from the Malaysia Computer Emergency Response Team have also highlighted a rise in ransomware incidents in early 2026, reinforcing the urgency for stronger cybersecurity and recovery strategies. As threats evolve alongside cloud and AI adoption, relying on backups alone is no longer sufficient.

Recovery Time Objective (RTO) and Recovery Point Objective (RPO)

At the heart of recovery readiness are two key concepts: Recovery Time Objective (RTO) and Recovery Point Objective (RPO). RTO defines how quickly a system must be restored before the impact becomes unacceptable, while RPO determines how much data loss a business can tolerate. These are not merely technical metrics—they are business decisions that directly affect operations, customer experience, and financial performance.

However, many organisations fail not because they lack backups, but because they have never tested recovery. A system may show “backup successful,” yet no one knows how long restoration will take—or whether it will work at all. Dependencies such as identity systems, network configurations, and application integrations are often overlooked, making full recovery far more complex than expected.

Another common challenge is the lack of clear ownership during incidents. When everything is urgent, teams can become paralysed, unsure of what to restore first. Without a defined recovery sequence or runbook, valuable time is lost in decision-making instead of action. Access issues can further complicate the situation, especially when the right personnel cannot retrieve or restore systems quickly.

Modern cyber threats add another layer of risk. In cases of credential compromise, attackers may not need to destroy backups—they can simply restrict access or delete them using the same privileged accounts. This is why secure, immutable backups and separated access controls are essential components of any recovery strategy.

Backup-as-a-Service (BaaS) and Disaster Recovery-as-a-Service (DRaaS)

It is also important to understand the difference between Backup-as-a-Service (BaaS) and Disaster Recovery-as-a-Service (DRaaS). While BaaS focuses on storing data copies, DRaaS ensures that entire systems and operations can be restored. Confusing the two can lead to prolonged downtime and costly disruptions.

To build true resilience, Malaysian businesses must shift from a backup mindset to a recovery-first approach. This begins with identifying critical systems that must be restored immediately, defining realistic RTO and RPO targets, and creating a clear recovery plan. Regular disaster recovery drills are equally important, as they reveal gaps that are often invisible during normal operations.

Ultimately, the goal is not just to have data—it is to restore business continuity quickly, confidently, and with minimal impact. Because in today’s environment, the real risk is not that something will break. It is that when it does, the organisation is not ready to recover.

As businesses reflect on initiatives like World Backup Day, the message for 2026 is clear: backing up data is only the first step. True resilience lies in the ability to recover.

The full article is from Malaysian Updates.

By Guan Tian Lai, COO of Exabytes

Imagine it’s a normal workday. A key system goes down, staff can’t log in, customer orders stall, and the phones start ringing. Someone says, “It’s fine, we have backups.” That sentence feels reassuring, but it often hides a harsh reality: backups are not the same as recovery. Backups tell you a copy of data exists. Disaster recovery determines whether you can restore access, services, and operations within an acceptable time and with acceptable data loss. The gap between those two is where Malaysian businesses lose hours, money, and customer trust, even when they believe they did the right thing.

That’s why World Backup Day is a useful reminder but it can also reinforce the wrong kind of confidence if it stops at “we back up.” The more important question is: can you actually recover?

Most organisations don’t discover they have a disaster recovery problem until the day something breaks. It could be a configuration mistake. A human error that escalates faster than expected. A credential compromise. A provider outage. Or a chain reaction where one dependency quietly fails and the service never comes back the way you assumed it would. In the Malaysian environment, the most common downtime triggers we see are human error and misconfiguration, credential compromise, and provider-side outages and each of these exposes the same weakness: recovery is rarely designed, tested, and owned as a discipline.

This is also why Malaysia’s national incident response centre continues to warn about ransomware trends and repeatedly emphasises backup management and security hygiene as essential countermeasures. In early 2026, MyCERT noted an increase in ransomware-related incidents targeting organisations across Malaysia. At an industry level, Malaysia’s broader cybersecurity landscape discussions continue to highlight that threats including ransomware are increasing in sophistication as cloud and AI adoption deepens.

Backup vs disaster recovery

Backup vs disaster recovery: the difference leaders must understand Let’s define it simply. Backup is a copy of data. Disaster recovery (DR) is the ability to restore operations, systems, applications, access, dependencies, and workflows, within a target window.

Two decisions separate organisations that feel prepared from organisations that actually are: RTO (Recovery Time Objective): How long can we be down before the business impact becomes unacceptable? RPO (Recovery Point Objective): How much data can we afford to lose and still operate responsibly?

These are not IT terms. They are business decisions. If your billing system can be down for eight hours, that’s an RTO decision. If your orders can only lose five minutes of data, that’s an RPO decision. And if you’ve never defined those targets or never tested whether you can meet them, then “having backups” may not protect you from disruption.

Why backups still fail when reality hits When organisations struggle during incidents, the problem is rarely “the backup file.” It’s everything around it.

First, restore is untested. Many teams check backup completion status but never validate restoration. The result is a false sense of security: the system says “backup successful,” but recovery time and recovery steps remain unknown until the worst moment.

Second, dependencies are invisible until the outage. You may restore a database but forget the identity system, DNS, keys, network configuration, or application dependencies that make the service usable. In Malaysia, SMEs especially underestimate dependency mapping and recovery documentation — so when they attempt a restore, they don’t know what must come back first or what the service relies on.

Third, nobody owns the order of recovery. When everything is “urgent,” teams lose time debating what should be restored first instead of executing. This is where a clear Tier 1 restoration order prevents chaos.

Fourth, access becomes the bottleneck. Many organisations underestimate recovery access control. During an incident, they discover too late that the right people cannot access the right accounts, systems, or recovery tools quickly enough to restore.

Finally, the backup strategy does not match the risk. If credential compromise is a threat, backups must be immutable, ensuring they cannot be altered or deleted even with privileged access. If misconfiguration is a threat, recovery must account for operational errors, not just data loss.

Offsite backups

Across environments we’ve supported at Exabytes, a common scenario illustrates this clearly. Many organisations believe they are safe because backups are stored “outside” the main system. What often gets missed is that the same login access controls both production systems and the backups. When credentials are compromised, attackers don’t need to “destroy backups” in dramatic ways, they can block recovery access or delete backup sets using the same privileged accounts. In those situations, the weakness isn’t where the backup is stored; it’s that recovery was never fully separated from day-to-day operations. Put simply: offsite backups don’t help if attackers control the same credentials used to restore.

A quick clarity box: BaaS vs DRaaS Leaders often confuse the two. Backup-as-a-Service (BaaS) focuses on copying and retaining data. Disaster recovery (often delivered as DRaaS in modern environments) focuses on restoring the business, applications, infrastructure, access, and dependencies, so operations resume within target RTO/RPO. Both matter. Confusing one for the other is how incidents become prolonged outages.

Malaysia’s 2026 resilience checklist (practical, not theoretical) If you want a recovery plan that survives real pressure, start with what matters most: priority, targets, access, and practice.

Begin by setting your Tier 1 restore list and restore order. Tier 1 is not your entire stack. It’s what must come back first for the business to function. In practice, a sensible Tier 1 sequence for many organisations is: identity and access first, then network and DNS, then email and core business applications. Without identity and DNS, everything else becomes slower, riskier, or impossible.

Next, define RTO and RPO per system. Different systems have different tolerances. Define realistic targets, even roughly at first: “This must recover within X hours,” “We can only tolerate Y minutes of data loss.” You don’t need perfect numbers on day one. You need agreement and clarity because recovery is a business decision as much as a technical one.

Then make sure backups are recoverable, not just available. Ask better questions than “Do we have backups?” Ask: when was the last successful restore? Are backups protected from deletion or tampering? Do we have multiple recovery points? Can we recover not just data, but the service?

At the same time, create a runbook that works under stress. The most damaging incident moments are organisational, not technical. Your runbook should clarify who declares an incident, who leads recovery, what gets restored first, who communicates, and what “done” looks like. Include vendor contacts and escalation paths.

No universal template

One critical element many teams skip is defining DR declaration criteria before an incident. There is no universal template because every environment is different but every organisation should agree on triggers based on business impact, time thresholds, and security/access conditions. Indecision is one of the most underestimated failure points: teams keep troubleshooting long after the business should have shifted into recovery mode.

Finally, drill the plan. A practical baseline is two DR drills per year, with at least one restoration test annually. Tabletop drills are fast and revealing: who decides the restore order? What if admin access is unavailable? What do we tell customers? Restoration testing turns “confidence” into proof.

World Backup Day takeaway: the most important test is the one you haven’t run World Backup Day is a good reminder to back up. But the bigger question is whether you can recover. A backup is necessary, but it is not sufficient.

In 2026, Malaysian organisations should move beyond comfort statements and build measurable recovery capability: define what matters most, set recovery targets, create a runbook, and drill until recovery becomes predictable. Because the real risk isn’t that something breaks, it’s that when it breaks, the organisation has no practised way to restore operations quickly, calmly, and with minimal disruption.

If you can only do one thing this quarter, run a DR drill. It will reveal more about your resilience than any dashboard ever will.

*Full article from Business News.

IMAGINE a typ­ical work­day sud­denly unrav­el­ling. A crit­ical sys­tem goes down, employ­ees are locked out, cus­tomer orders stall and phones begin ringing incess­antly. Amid the chaos, someone offers reas­sur­ance: “It’s fine, we have backups.”

That reas­sur­ance, however, can be dan­ger­ously mis­lead­ing.

Exa­bytes chief oper­at­ing officer Guan Tian Lai said many organ­isa­tions con­flate hav­ing backups with being able to recover.

“Backups only tell you that a copy of your data exists. They do not guar­an­tee that your busi­ness can resume oper­a­tions within an accept­able time or with min­imal dis­rup­tion.”

A False Sense of Security

World Backup Day, marked on March 31, serves as a timely reminder for organ­isa­tions to safe­guard their data. But stop­ping at backups alone can cre­ate a false sense of secur­ity.

Guan said the more import­ant ques­tion organ­isa­tions should ask is not whether data is backed up, but whether sys­tems, ser­vices and work­flows can be restored when it mat­ters most.

“We often see busi­nesses assume they are pre­pared simply because backups are in place. In real­ity, dis­aster recov­ery is about restor­ing the entire envir­on­ment — access, applic­a­tions, depend­en­cies — not just files.”

Many organ­isa­tions only dis­cover gaps in their recov­ery strategy when dis­rup­tion strikes. Incid­ents can stem from human error, mis­con­fig­ur­a­tion, cre­den­tial com­prom­ise or ser­vice pro­vider out­ages — all of which are increas­ingly com­mon in Malay­sia’s digital land­scape.

This con­cern is echoed by the Malay­sia Com­puter Emer­gency Response Team (MyCERT), which has repor­ted a rise in ransom­ware-related incid­ents in early 2026, high­light­ing the grow­ing soph­ist­ic­a­tion of cyber threats.

Understanding What Really Matters

At its core, backup is about data stor­age, while dis­aster recov­ery is about busi­ness con­tinu­ity.

Two key bench­marks define this cap­ab­il­ity: Recov­ery Time Object­ive (RTO) and Recov­ery Point Object­ive (RPO). Guan stressed that these are busi­ness-driven decisions rather than purely tech­nical con­sid­er­a­tions.

“RTO and RPO define what the busi­ness can tol­er­ate. How long can you afford to be down? How much data can you afford to lose? Without clear answers, recov­ery becomes guess­work,” said Guan.

He added that organ­isa­tions that fail to define or test these tar­gets risk pro­longed out­ages des­pite hav­ing backups in place.

When Backups Fall Short

In real-world incid­ents, fail­ures rarely occur because backup files are miss­ing. Instead, they arise from gaps in exe­cu­tion and plan­ning.

Guan said that one of the most com­mon issues is the lack of res­tor­a­tion test­ing.

“Many teams mon­itor backup com­ple­tion but never test whether those backups can be restored quickly and cor­rectly. This cre­ates a false sense of con­fid­ence.”

Depend­en­cies fur­ther com­plic­ate recov­ery. Restor­ing a data­base alone is insuf­fi­cient if sup­port­ing sys­tems such as iden­tity ser­vices, DNS and net­work con­fig­ur­a­tions are not brought back in the cor­rect order.

“Recov­ery is not a single action. It is a sequence. If you restore com­pon­ents out of order or over­look depend­en­cies, the sys­tem may not func­tion even if the data is intact,” he added.

Separating Backup from Recovery

Guan said one of the most over­looked risks is the lack of sep­ar­a­tion between pro­duc­tion and backup envir­on­ments.

“Many organ­isa­tions believe they are pro­tec­ted because their backups are stored off­s­ite. But if the same cre­den­tials con­trol both pro­duc­tion and backup sys­tems, attack­ers can com­prom­ise recov­ery just as eas­ily.”

He said that in such scen­arios, attack­ers do not need to des­troy backups to cause dis­rup­tion.

“They can simply block access or delete backup sets using com­prom­ised cre­den­tials. The weak­ness is not the loc­a­tion of the backup, but the lack of sep­ar­a­tion in access con­trol.”

From Theory To Practice

To build genu­ine resi­li­ence, organ­isa­tions must adopt a more struc­tured and prac­tical approach to recov­ery.

Guan emphas­ised the need to identify Tier 1 sys­tems — the crit­ical com­pon­ents required to restore oper­a­tions.

“Iden­tity and access sys­tems should come first, fol­lowed by net­work ser­vices such as DNS, before mov­ing on to core busi­ness applic­a­tions. Without these found­a­tions, recov­ery becomes sig­ni­fic­antly more dif­fi­cult,” he said.

He also stressed the import­ance of defin­ing real­istic RTO and RPO tar­gets for each sys­tem, as well as ensur­ing backups are pro­tec­ted from tam­per­ing and sup­por­ted by mul­tiple recov­ery points.

Equally import­ant is the cre­ation of a clear run­book to guide teams dur­ing incid­ents.

“A good run­book defines who makes decisions, who leads recov­ery, what gets restored first and how com­mu­nic­a­tion is handled. In a crisis, clar­ity is everything,” he said.

A Shift in Mindset

While World Backup Day high­lights the import­ance of safe­guard­ing data, Guan said organ­isa­tions must move bey­ond basic meas­ures.

“Backups are neces­sary, but they are not suf­fi­cient. What mat­ters is whether you can recover quickly, safely and pre­dict­ably.”

*Full article from New Straits Times.