News & Events

  • Share:



Indonesian Retail Leader Cuts Disaster Recovery Time from Days to Under 90 Minutes with AWS Elastic Disaster Recovery

Retail Company

One of Indonesia’s five largest lifestyle retail conglomerates had no tested recovery path for the AWS estate running 2,000+ stores. PT Metrodata Electronics Tbk delivered a two-tier disaster recovery architecture — pilot light for the server estate and an always-on Oracle Data Guard standby for the SAP databases — with measured test results.

62 min

15 min

8 of 8

~40%

Average failover, against a 90-minute objective

Recovery point achieved, down from up to 24 hours

Corporate servers passing both objectives, both directions

Lower cost than the planned standby infrastructure

ABOUT THE CUSTOMER

The customer is one of Indonesia’s five largest lifestyle retail conglomerates, operating more than 2,000 retail stores nationwide for over 30 years. Listed on the Indonesia Stock Exchange, the organisation manages a portfolio of more than 150 international and local brands across fashion, sports, food and beverage, department stores and lifestyle categories, generating annual revenues exceeding USD 2 billion. It serves millions of Indonesian consumers through both physical stores and digital retail channels, making uninterrupted IT operations fundamental to daily trading, supply chain execution and financial reporting.

CUSTOMER CHALLENGE

As the customer’s retail footprint expanded, its AWS estate grew to 171 virtual machines running in a hub-and-spoke AWS Landing Zone across six AWS accounts — 32 SAP-related servers and 139 non-SAP servers supporting point-of-sale processing, systems integration, business intelligence, workspace services and finance. These systems underpin daily transactions across thousands of stores. Yet the estate had no modern disaster recovery capability. Recovery from a significant infrastructure failure was measured in days rather than hours, no recovery point objective had ever been defined, and no tested recovery path existed for any of the critical workloads.

The exposure this created was material. Modelling by the customer placed revenue loss at USD 100,000 to USD 200,000 for a single downtime incident during year-end promotions or flash sale events, when transaction volumes peak. Without a defined recovery point, as much as 24 hours of transactional data could be lost in a failure — data the business depends on for financial reconciliation, audit compliance and regulatory reporting. Because no automated failover mechanism existed, every incident required manual intervention across multiple systems by a team working without runbooks, which extended outages and introduced the risk of error under pressure. In a fiercely competitive retail market, downtime during high-traffic promotional periods carried a direct cost to customer trust and brand reputation.

The customer’s existing plan was to build traditional standby infrastructure, which would have required significant capital expenditure on hardware held idle, and would still have delivered an untested recovery path. A further constraint shaped the design: Asia Pacific (Jakarta) is the only AWS Region in Indonesia, so any resilience architecture had to deliver a tested recovery capability while keeping all customer data onshore.

PARTNER SOLUTION

PT Metrodata Electronics Tbk, working through its subsidiary PT Mitra Integrasi Informatika, designed and implemented a disaster recovery architecture using AWS Elastic Disaster Recovery in the Asia Pacific (Jakarta) Region. The design recovers workloads between Availability Zones within the Region, directly addressing the failure scenario the customer had defined — a disaster affecting a single Availability Zone — while keeping every byte of customer data inside Indonesia.

The architecture follows the pilot light pattern: application data replicates continuously into a low-cost staging area, recovery servers exist as pre-configured launch templates rather than running instances, and promotion to a full production environment is automated. The customer pays for continuous data protection without paying to run a duplicate environment.

Metrodata began with a discovery and assessment phase across the customer’s 171 virtual machines, mapping application dependencies, network requirements and recovery priorities across retail, logistics and finance systems. From this analysis, 24 servers spanning six AWS accounts were classified as business-critical and brought into the disaster recovery scope, and a target recovery Availability Zone was assigned to each one according to its dependency group, so that related systems recover together rather than in isolation.

In the design phase Metrodata built an isolated recovery environment using Amazon VPC with private subnets, ensuring replication traffic never traverses the public internet. AWS Identity and Access Management roles were configured to grant least-privilege access to recovery operations, and all replicated data was encrypted both in transit and at rest. Amazon CloudWatch alarms were established to monitor replication health and replication lag in real time, so that a degraded replication stream is detected and raised before it becomes a recovery failure — the most common silent defect in disaster recovery programmes.

Deployment centred on AWS Elastic Disaster Recovery, which performs continuous block-level replication from each protected server into Amazon EBS volumes in a staging subnet. Amazon EC2 provides the recovery compute, launched from pre-defined templates only when a drill or an actual recovery is invoked. Amazon S3 provides backup storage, Amazon VPC provides the network isolation, AWS IAM governs access, and Amazon CloudWatch provides the monitoring and alerting layer. Metrodata installed and configured the AWS DRS replication agent across all 24 in-scope servers, tuned replication settings for each workload profile, and configured launch templates so that recovery instances start with correct sizing, networking and security group placement without manual configuration at the point of failure.

Metrodata provided support services across both the pre-implementation and post-implementation phases. Before implementation, the partner ran the discovery and assessment, facilitated design workshops with the customer’s infrastructure and application teams, deployed and configured the replication agents, authored recovery runbooks for each dependency group, and trained the customer’s internal IT team to execute recovery operations independently. After implementation, Metrodata provides quarterly disaster recovery drill execution, 24×7 managed support, continuous monitoring of replication health, and ongoing optimisation of the recovery configuration as the customer’s estate evolves.

The programme was validated in two exercises. The first tested the pilot light layer across eight production servers in the Corporate account, in both the failover and failback directions. The second was a dedicated SAP disaster-recovery drill that exercised the Oracle Data Guard switchover and automated fast-start failover for the SAP landscape, confirming the standby database was automatically promoted to primary and the SAP services were brought back up in order on the recovered environment. Automated database failover completed in 4 minutes on the core retail system and 18 minutes on the food and beverage system, with controlled switchover in 1 to 2 minutes.

The engagement concluded with a formal validation exercise conducted in 2025. Rather than testing recovery in one direction only, Metrodata executed both failover and failback for eight production servers in the customer’s Corporate account, recovering from Availability Zone A to Availability Zone C and from Availability Zone A to Availability Zone B. Each test was verified by four independent checks: local user login, comparison of the newest file against the source, comparison of existing data against the source, and confirmation of service status. Data integrity was proven by comparison, not inferred from a successful instance launch.

The customer’s SAP estate required a second mechanism alongside the pilot light layer. Where AWS Elastic Disaster Recovery protects the application and operating-system servers, the SAP production databases are protected by Oracle Data Guard, which maintains a continuously synchronised physical standby database in a second Availability Zone within the Jakarta Region. An Oracle Data Guard Observer monitors the primary database and, on failure, performs an automated fast-start failover — promoting the standby to primary without manual intervention. This gives the database tier a warm, always-on recovery posture: the standby is a live, fully functional copy applying changes in near real time, not a switched-off template. The SAP application servers are recovered alongside it and the landscape is brought up in dependency order, ASCS and ERS first, then databases and application servers.

RESULTS AND BENEFITS

Every server tested met both recovery objectives, in both directions. Against a committed Recovery Time Objective of 90 minutes, failover completed in an average of 62 minutes across the eight servers — 31 percent faster than the objective — with the fastest recovery at 41 minutes and the slowest at 88 minutes. Failback performed better still, averaging 55 minutes with a slowest case of 68 minutes. Recovery Point Objective was achieved at 15 minutes on all eight servers in both directions, meeting the committed target exactly. All eight servers passed all four data integrity verification checks. The result is a documented pass rate of 8 out of 8 servers against both objectives in both directions — a materially stronger evidence position than the one-directional testing typical of most disaster recovery programmes, because it demonstrates the customer can not only recover but return to normal operations afterward.

The SAP drill validated the Oracle Data Guard tier across both SAP production systems — the core retail system and the food and beverage system — running on Oracle Database 19c. In the SAP drill each system’s primary database was deliberately shut down to trigger recovery. On the core retail system, the Oracle Data Guard Observer detected the failure and automatically promoted the standby database in a separate Availability Zone to primary in 4 minutes , with no manual intervention, and a controlled switchover completed in 1 minute . The food and beverage system was validated the same way, with switchover in 2 minutes and automated failover in 18 minutes . All twelve test cases across the two systems passed. Because Data Guard runs in maximum-performance mode with a 30-second lag limit, the database recovery point is within approximately 30 seconds .

Measure

Before

After

Recovery time

Measured in days, untested

62 min average, 88 min worst case

Recovery point

Undefined, up to 24 hours

15 minutes

Servers under continuous protection

0

24 across six AWS accounts

Tested recovery path

None

8 of 8 drilled both directions; SAP tier drilled Aug 2025

Disaster recovery cost

Traditional standby, capital funded

~40% lower, no idle duplicate estate

Measured against the position before the engagement, the improvement is substantial. Recovery time fell from a capability measured in days to a tested capability measured in approximately one hour. Potential data loss fell from as much as 24 hours to a maximum of 15 minutes, a reduction of over 98 percent in the customer’s worst-case data loss exposure. Coverage moved from zero servers under any form of continuous protection to 24 business-critical servers replicating continuously across six AWS accounts. Because the pilot light architecture holds no running duplicate environment, the customer achieved this protection at an estimated 40 percent lower cost than the traditional standby infrastructure it had originally planned to build, while eliminating the capital expenditure that plan required.

The business outcomes follow directly from the challenge. The USD 100,000 to USD 200,000 revenue exposure per peak-trading downtime incident is now bounded by a tested 90-minute recovery rather than an open-ended multi-day outage. The 24-hour reconciliation and audit compliance risk is reduced to a 15-minute window. Manual, undocumented incident response has been replaced by runbooks and an automated recovery path that the customer’s own trained team can execute, supported by quarterly drills that keep the capability current as the estate changes. The customer moved from having a disaster recovery intention to having a disaster recovery capability with measured evidence behind it.

ABOUT THE PARTNER

PT Metrodata Electronics Tbk (IDX: MTDL) is one of Indonesia’s leading digital solution providers and an AWS Advanced Tier Services Partner, listed on the Indonesia Stock Exchange and trusted by more than 200 organisations across banking, retail, manufacturing, mining, healthcare and the public sector. Through its consulting and system integration subsidiaries PT Mitra Integrasi Informatika and PT Sinergi Transformasi Digital, Metrodata delivers cloud migration, modernisation, managed services and business continuity solutions. Metrodata currently holds the AWS Migration and Modernization Competency and the AWS Glue Service Delivery designation, and maintains a dedicated AWS practice of certified solutions architects and engineers delivering resilience, migration and managed services from Indonesia for Indonesian customers.

Back To List
Metrodata logo

PT. Metrodata Electronics, Tbk.

APL Tower 37th Floor 
Jl. Letjen S. Parman Kav. 28
Jakarta 11470

Contact Us:

P: (62-21) 2934 5888
F: (62-21) 2934 5899
E: info.metrodata@metrodata.co.id

social media