EXPLOREINDUSTRIESGUIDESLEARNGLOSSARYBOOKSWHITEPAPERTOOLSRESOURCESPIONEERMARKETSCOUNTRIESFEESMISSION FUNDPASSPORT
SUPPORTLOGINJOIN THE PROTOCOL →
GETREADYANDJUMP.COM · BUILT IN DETROIT

DISASTER RECOVERY
ON GRAJ.

Disaster Recovery on the GRAJ protocol. One fee. 195 countries. Join the protocol.

JOIN THE PROTOCOL →
Resilience

WHEN SOMETHING
GOES WRONG.

Being built

Every system fails eventually. What separates an incident from a catastrophe is whether the failure modes were thought about beforehand and whether the recovery has ever been tested — because a backup nobody has restored is a hypothesis.

The two numbers that define it

How much data you can afford to lose, and how long you can afford to be down. Every recovery decision follows from those, and an organisation that has not chosen them has chosen them implicitly and badly.

  • Recovery point objective — the acceptable window of lost data
  • Recovery time objective — how long restoration may take

Append-only helps more than it looks

A log that is never updated or deleted is far easier to reason about after an incident: recovery is replaying events rather than reconciling a mutable state nobody can reconstruct. The financial ledger has the same property by design.

A backup is a hypothesis until restored

Restoration has to be practised, on a schedule, to a real environment. Almost every serious data-loss incident involves a backup that existed and could not be used.

What is true today

The database is managed with provider-level backups, and the record structure is append-only, which meaningfully limits what a bad write can destroy. A documented recovery plan with tested objectives is not in place, and saying so is more useful to somebody assessing risk than a paragraph implying one.

Where to go next
/append-only/ledger/iso27001
JOIN THE PROTOCOL