The Backup That Existed Only in Theory: Cloud Backup for a Singapore Edtech Company

The short answer: A Singapore edtech company's content server failed, and the recovery attempt found the nightly backup job had been failing silently for three weeks. The backup existed on a schedule. Nobody was watching whether it ran. Job monitoring and dated restore drills are what turn a backup schedule into something you can actually rely on.

The company here is a composite scenario, not a named client, and its timeline is illustrative. What is real is the service described: backup job monitoring, recovery drills and offsite cloud targets are how Brocent's Cloud Managed Backup is actually built.

Why a backup failure is a different kind of event for a digital-content business

Singapore has a dense population of edtech, e-learning, media production and digital publishing companies — fifty to eighty people, product entirely digital, and a content library that took years and considerable money to build. Course video, assessment banks, interactive modules, localised variants for four or five markets, and the project files behind all of it.

For that kind of company, the data is not a record of the business. It *is* the business. A manufacturer that loses three weeks of file server data has an unpleasant reconstruction job. An edtech company that loses its course masters has lost inventory it cannot re-source, because the instructors have moved on, the studio booking was a year ago, and the localisation vendor's working files were the ones on that server.

Two structural details make these companies more exposed than their sophistication suggests. First, the technical maturity is uneven. The engineering team is genuinely capable, which produces a reasonable assumption that internal systems are equally well handled — and internal systems are usually nobody's product, so they are nobody's priority. Second, the environment is hybrid in an awkward way: the customer-facing platform is in cloud infrastructure and managed properly, while the content production pipeline sits on an on-premise server or a NAS in the office, because rendering and editing over a VPN was never practical.

The result is a company with a modern, well-run production platform and a store-room-grade content archive, protected by a backup job someone configured competently two years ago and nobody has looked at since.

The scenario: a failed drive, and three weeks of nothing

The composite company employs about sixty-five people in Singapore, building and localising course content for corporate clients across the region. Its content pipeline runs on a single on-premise server with direct-attached storage: source video, project files, rendered masters, and the asset library the production team works from daily.

The backup was set up properly when the server was built. Nightly job, local target, retention configured, email notification on completion. The person who set it up left the company about a year later. The email notifications went to a distribution list that gradually stopped being read, then to a mailbox rule that filed them, and eventually nobody could have said with confidence who received them.

On a Tuesday morning, the array degrades and then fails outright. The engineering lead does the right things in the right order — confirms the failure, sources replacement hardware, and goes to restore from backup.

The most recent successful backup is twenty-three days old.

The job had been failing since a routine update changed a service account's permissions. It failed the same way every night for three weeks, and every night it wrote that failure to a log nobody read and sent a notification nobody received. Nothing about the environment looked wrong from the outside. The backup software was running. The schedule was intact. The storage target had free space. The job simply did not complete, silently, twenty-three times.

Three weeks of content work is recoverable in the sense that it can be redone. It cost the company a delayed client delivery, two weekends of production time, and one localisation batch that had to be re-commissioned because the vendor had already deleted their working copies after handover.

What actually went wrong, and it is not the software

It is tempting to read this as a tooling failure. It was not. The backup software did what it was configured to do and reported honestly every single night.

Four gaps produced this outcome, and they are the same four we find almost every time.

Nobody owned job status. Backup was treated as a configuration — something you set up — rather than an operation, something that runs and therefore needs watching. A job that reports failure into a void has the same practical value as no job at all.

There was no offsite copy independent of the primary environment. The backup target sat in the same office, on the same network, reachable with the same credentials. That is a single-site copy, and it fails against the two scenarios most likely to actually hurt a Singapore SME: ransomware that encrypts everything it can reach, and a physical event in the building.

No restore had ever been tested. This is different from the job failing. Even had the job succeeded every night for two years, nobody had ever proven the data could be brought back into a working state within a useful timeframe. A backup that has never been restored is a hypothesis.

RTO and RPO had never been agreed with the business. Nobody had asked the production director how much content work the company could afford to lose, or how long the pipeline could be down. Without those two numbers, no one could evaluate whether a nightly local-only backup was adequate — and in fact it was not, but there was no standard against which to notice.

That last point is worth dwelling on, because it is the one that gets skipped. RPO is how much data you can afford to lose, expressed in time. RTO is how long you can afford to be down. Both are business decisions, not technical ones. IT can tell you what a given RPO costs; only the business can say what it is worth. In the composite company, the honest answer — once someone finally asked — was that a day of lost production work was tolerable and three weeks was not, which immediately made the existing arrangement indefensible.

Brocent's perspective: a backup you have never restored is a hypothesis

Brocent has run IT operations across Asia since 2007, opened its Hong Kong office in 2016, and has been headquartered in Singapore since 2021. Backup and DR is included in every tier of our managed IT plans, and the reason it is included rather than optional is precisely the pattern above: the companies that get hurt are almost never the ones with no backup at all. They are the ones with a backup nobody was watching.

Our Cloud Managed Backup service is built around three things that a configured-and-forgotten backup job does not have.

Backup job monitoring, 24 × 7. Our SCC and NOC teams monitor backup jobs as a supervised operation, not as a notification email. A job that fails on a Tuesday surfaces the same week — not twenty-three days later, in the middle of an incident.

Regular recovery drills. We perform periodical data recovery drills with the customer to verify backup integrity and recoverability. The output is a dated result: on this date, this data was restored, and it took this long. That is the artefact that converts a hypothesis into a fact, and it is also what an insurer or an enterprise client's due-diligence questionnaire is actually asking for.

A BCP with RTO and RPO agreed in writing. We support defining the business contingency plan covering the strategy and methodology of backup and disaster recovery with respect to RTO and RPO. This is the conversation the composite company never had, and it is the one that determines every technical decision downstream.

Underneath, the design follows the discipline the market shorthand calls 3-2-1: at least three copies of the data, on at least two different media or platforms, with at least one held offsite. In practice that means on-premise backup for the servers and systems that live in your office; consolidation of cloud-hosted data into on-premise storage or into a second cloud platform for inter-cloud redundancy; and, where it fits the risk profile, offsite storage of physical backup media in a third-party facility. We work with Veeam, Microsoft, Acronis and MSP360 tooling and back up to Azure, AWS and Alibaba Cloud targets — the tool is chosen to fit the environment rather than the other way round.

One thing we are deliberate about: this is not sold as a standalone product to babysit. Backup and DR is part of every managed IT support plan, because job monitoring is an operational discipline that belongs with patching, endpoint protection and NOC monitoring rather than sitting in isolation as another dashboard nobody opens.

What good looks like for a company of this size

For a sixty-five-person edtech company with a production pipeline that matters, the practical shape is not exotic.

Job status is watched by someone whose job it is. Not a notification email, not a dashboard the engineering lead means to check. A monitored operation with an escalation path when a job fails.

At least one copy is offsite and independently credentialed. The offsite copy should not be reachable with the same credentials that would be compromised in a ransomware event. This is the single change that most improves a Singapore SME's actual survivability, and it is usually the cheapest one on the list.

Restore drills happen on a schedule and produce a dated result. Quarterly is a reasonable baseline. The drill should restore something real to a usable state, not merely verify that a backup file can be opened.

RTO and RPO are written down and signed off by the business. Two numbers, agreed with the person who owns the consequences. Everything else follows from them, including how much you should be spending.

Retention is matched to how the business actually works. A content company frequently discovers a problem in a master file weeks after delivery. A seven-day retention window is a different product from a ninety-day one, and the difference only matters at the moment you need it.

The cloud platform's own data is included in scope. Microsoft 365, Google Workspace and SaaS platform data are commonly assumed to be backed up by the provider. Provider replication protects against their infrastructure failing; it does not protect against your own accidental deletion, a departing employee's mailbox purge, or ransomware inside your tenant. This is one of the most common gaps we find.

Cloud Managed Backup starts from USD 298 for the basic preventive backup maintenance plan, and there is a per-device Cloud Backup add-on published as a monthly per-device rate on the pricing page alongside the rest of the managed plan. The backup and recovery page covers the underlying tooling options if you want to see what sits beneath the service.

The ransomware version of the same story

It is worth stating the counterfactual plainly, because it changes how you should read the scenario above.

In the composite company, the failure was a degraded array. That is the benign version. It announced itself, it affected one system, and the backup target — however stale — was still intact and readable when someone went looking.

Run the same environment through a ransomware event and the arithmetic changes completely. Encryption software reaching a file server via valid credentials will reach anything else those credentials can write to, and a backup target on the same network, mounted with the same service account, is exactly that. The company would not have discovered a twenty-three-day-old backup. It would have discovered an encrypted one.

This is why the offsite copy is not a refinement of a backup strategy but the load-bearing part of it, and why immutability matters. A copy that cannot be modified or deleted within its retention window — even by an administrator, even with correct credentials — is the thing that survives an attacker who has taken over your environment. Immutable backup is included in the backup and DR baseline of our managed plans for exactly this reason.

There is a second-order point here that is easy to miss. In a ransomware incident, the question is not only "can we restore" but "how fast, and from where". If your only good copy is in a cloud region and you need several terabytes back onto hardware you have not yet bought, the restore is measured in days regardless of how correct the backup is. That is an RTO conversation, and it is best had before an incident rather than during one.

Three ways a Singapore company handles backup

An unmonitored scheduled job

• What you get: A backup that runs, configured correctly, at no ongoing cost.
• Where it breaks: Silently. The job's failure reports into a log or an unread mailbox, and the gap is discovered during a real incident — the worst possible moment to learn how long it has been going on.
• The tell: If you cannot say who read yesterday's backup job result, nobody did.
• Who it suits: Nobody, though it describes a large share of SMEs honestly assessed.

Self-managed cloud backup tooling

• What you get: Capable software, offsite targets, retention policy control, and full flexibility.
• Where it breaks: It still needs somebody watching job status and running restore drills. In a company where IT is one or two people with a product roadmap of their own, the drills are the first thing to slip, and job monitoring quietly becomes "we'd notice if something was wrong".
• Who it suits: Companies with a dedicated infrastructure person who has the mandate to protect that time.

Managed cloud backup with monitoring and restore drills

• What you get: 24 × 7 backup job monitoring by SCC/NOC teams, scheduled recovery drills with dated results, offsite cloud targets independent of the primary environment, and a BCP with RTO and RPO agreed in writing. Veeam, Microsoft, Acronis and MSP360 tooling; Azure, AWS and Alibaba Cloud targets.
• What it costs: From USD 298 for the basic preventive maintenance plan, plus a per-device rate for the Cloud Backup add-on. Backup and DR is included at every managed IT plan tier.
• Where it breaks: It does not remove the need for the business to decide its RTO and RPO. We can advise; we cannot decide what your downtime is worth.
• Who it suits: Companies whose data is the product, and whose internal team's time is better spent on the product than on watching job logs.

Frequently asked questions

How is cloud backup priced?

Two ways, depending on scope. Cloud Managed Backup starts from USD 298 for the basic preventive backup maintenance plan covering design, setup and supervised operation. For endpoint and device-level coverage there is a Cloud Backup add-on published as a monthly per-device rate, with overage beyond the included storage quota quoted per environment. Both sit alongside the managed IT plan, in which backup and DR is included at every tier. Current figures are on the pricing page.

What is the 3-2-1 backup strategy?

At least three copies of your data, held on at least two different media or platforms, with at least one copy offsite. The point of the third copy is not redundancy for its own sake — it is that the offsite copy should survive the event that destroys the other two, which in practice means ransomware reaching everything on your network, or a physical incident in your building. A local backup on the same network as the server it protects satisfies none of this.

How often should a restore actually be tested?

Quarterly is a reasonable baseline for most SMEs, and more often for systems with a tight RTO. The important part is what the drill produces: a dated record showing that specific data was restored to a working state, and how long it took. That figure is your real RTO, as opposed to the one in the plan document, and it is common for the two to differ substantially the first time anyone measures.

What is the difference between backup and disaster recovery?

Backup is a copy of the data. Disaster recovery is the ability to get back to working within an agreed time. You can have complete, perfectly valid backups and still be down for a week, because restoring several terabytes over an office internet connection onto hardware you have not procured yet takes as long as it takes. DR planning is about RTO — the time — and it changes what you build, not just what you copy.

Which cloud platforms can this back up to?

Azure, AWS and Alibaba Cloud are the targets we work with, using Veeam, Microsoft, Acronis and MSP360 tooling depending on the environment. We also support consolidating data from cloud IaaS environments into on-premise storage, or into a second cloud platform for inter-cloud redundancy, and offsite storage of physical backup media in a third-party facility where the risk profile calls for it.

What happens if a backup job fails silently?

In a monitored service, it does not stay silent. Our SCC and NOC teams supervise backup jobs 24 × 7 as an operation with an escalation path, so a failure surfaces within the same week rather than during a restore attempt. That is the specific difference between a configured backup and a managed one, and it is the difference the scenario in this article turns on.

Is this suitable for a company of fifty to eighty people?

Yes, and this size is where the gap is usually widest. A company this size has enough data to matter and enough technical confidence to assume it is handled, but rarely a dedicated infrastructure person whose job includes reading backup logs. The basic preventive maintenance plan is scoped for exactly this kind of environment.

Does this cover our Microsoft 365 data as well as our servers?

It can, and it usually should. Microsoft's replication protects you against their infrastructure failing, not against deletion, a departing employee clearing a mailbox, or ransomware operating inside your tenant with valid credentials. SaaS data is one of the most frequent gaps we find during scoping, precisely because it feels like somebody else's problem.

Where to go from here

The composite company in this article did not lose its content library. It lost three weeks, a client delivery date and a localisation batch — an expensive but survivable outcome, and only because the failure happened to be caught by a hardware fault rather than by ransomware, which would have reached the backup target on the same network.

The useful question is not whether you have backups. Almost everyone does. It is whether anyone read yesterday's job result, whether a copy exists somewhere your primary credentials cannot reach, and whether anyone has restored anything recently and written down how long it took.

If those three questions do not have confident answers, that gap is straightforward to close and considerably cheaper than the incident that would expose it. Our Cloud Managed Backup service covers monitoring, drills and offsite targets, and backup and DR is included at every tier of managed IT support. Get in touch and we will start with what you currently have and where it would actually fail.