Services
// Backup & Disaster Recovery
For the day you hope never comes
Every business believes it has backups — until the day it needs a restore. We design, run and test your backup and disaster recovery: defined RPO and RTO targets, automated backup operations, and scheduled drills that prove recovery works while it is still a rehearsal.
// The problem
Everyone has backups. Fewer have restores.
-
The backup ran. The restore never had to — until it did
Backup jobs reporting green for two years, and the first real restore is during the incident. That is the worst possible time to learn.
-
RPO and RTO were never actually decided
“As fast as possible” is not a target. Until the business states how much data it can lose and how long it can be down, every DR decision is a guess.
-
The DR plan is a document, not a system
Written for an audit three years ago, never rehearsed, and the person who wrote it has left. Paper does not fail over.
-
The estate changed; the backups did not
New databases and services shipped monthly, backup scope reviewed never. The gap between what runs and what is protected only ever widens.
// What’s included
Tested, not assumed.
-
Backup strategy mapped to RPO and RTO
What is backed up, how often, kept how long — decided from what the business can afford to lose, not from tool defaults.
-
Automated backup operations with integrity monitoring
Backups that run on schedule and are verified — a silent failure alerts us the day it happens, not the day you need the restore.
-
Disaster recovery architecture on Google Cloud
Warm standby, pilot light or backup-and-restore — designed to the recovery your business actually needs, at the cost tier that recovery justifies.
-
Scheduled DR drills with documented results
Restores rehearsed on a calendar, timed against the RTO, written up in evidence you can show an auditor — or your board.
-
Restore support with a human
At 3 a.m. if that is when it happens. The engineer who answers has seen your environment before the emergency.
// How it runs
A monthly subscription.
It is included at the higher levels of Managed Cloud — Operations and Full accountability — or runs on its own alongside your team. Scope, RPO/RTO targets and drill cadence are agreed in writing before it starts.
// Proof
We rehearse our own worst day.
Pantip MALL is a national marketplace — downtime there is public, immediately. The backup discipline, integrity checks and restore drills on this page are the ones protecting our own platform. We do not sell a practice we would not bet our own uptime on.
// Common questions
What teams ask before the worst day.
What are RPO and RTO, in plain terms?
RPO — recovery point objective — is how much data you can afford to lose, measured in time: an RPO of one hour means at worst you lose the last hour. RTO — recovery time objective — is how long you can afford to be down. Every backup and DR decision is a trade between those two numbers and cost, which is why we make the business state them first.
Is the cloud provider's own resilience not enough?
The platform protects against its own failures, not against yours. Deleted data, a bad deployment, ransomware or an account compromise replicate to every zone just as reliably as good data does. Provider resilience plus your own backups and a rehearsed restore path are different layers, and you need both.
How often should restores be tested?
On a schedule, not on faith — quarterly for most estates, more often for the systems with the tightest RTO. A restore that has not been rehearsed within the last quarter is a hypothesis, and drills are how it becomes a fact with a time against it.
Does this cover ransomware?
It is a large part of why the practice exists: immutable and versioned backups, isolation between production and backup credentials, and drills that include the scenario where production is untrusted. Prevention lives in Managed Security; recovery lives here — an incident needs both halves.
Our estate is partly on-premises. Can you cover it?
We design DR into Google Cloud for on-premises workloads — often as the first, lowest-risk step of a wider migration. Backing up to the cloud is frequently how an estate proves the cloud out.
Test your worst day
While it is still a rehearsal, and not a headline.
Innovate for the better tomorrow.
// Corporate update
Our
Move
-
Buying the platform and building on it used to be two conversations with two suppliers. It is one conversation now: we resell Google Cloud, Alibaba Cloud and BytePlus, and the same engineers who size the environment stay with it through production support.
For teams already running with us, nothing changes technically — the difference is commercial. Licensing, quota and billing sit with the people who know what the workload actually does.
-
A certified implementation partner works to the cloud provider's published reference architectures. In practice that means your landing zone, IAM model and network layout look like something any Google Cloud engineer can pick up — including the next team you hire.
It also means the review gates are not ours to waive. Where the reference architecture asks for separation of duties or a break-glass path, it gets built.
-
Hospital data arrives in fragments — HIS exports, lab feeds, scanned forms, free-text notes in Thai and English. Before a model sees any of it, someone has to answer where each field came from, who consented to what, and which records must never leave the country.
We build that layer first. It is slower to demo and it is the reason the pilots survive contact with a real ward.
-
Live commerce moves fast enough that the recommendation loop has to close in the same session. That puts the weight on the event pipeline, not the model: what counts as a view, when a cart event lands, how quickly the feature store sees it.
We treat the BytePlus components as a stack to be wired properly rather than a switch to be flipped. The lift comes from the wiring.
-
The site you are reading ships as static HTML, one stylesheet and one script, served by a Node process with a strict content security policy. There is no analytics tag, no font CDN and no tracker.
It is partly a statement of taste and partly a working sample: the same restraint we bring to a client's platform, applied to our own front door.
-
Warehouses fill up faster than they get governed. By the time a model needs a feature, nobody can say which of the four revenue columns is authoritative, and the project stalls in a meeting about definitions.
The fix is unglamorous: contracts on the ingest side, lineage through the transformations, and one owner per domain. Do that and the AI work stops being archaeology.