Backup and Disaster Recovery at a Three-Branch SACCO

Against the RPO (1 hour): a nightly full backup exposes up to 24 hours of transactions at any moment - a potential 24× breach of the approved tolerance. The March event actually lost three days, so even the design was not achieved in practice. The disk is taken home only on Friday, meaning that for most of the working week the only copy sits beside the server it is meant to protect; a fire, theft or encryption event destroys the source and the backup together.

Against the RTO (8 hours): recovering a core banking server means rebuilding hardware or a virtual machine, reinstalling the operating system, database engine and application, restoring data, replaying logs and reconciling balances. With one server, no standby hardware and no documented procedure, three days is the realistic outcome, not eight hours.

Why the missing restore test matters: a backup is an unverified hypothesis until it is restored. Failure to test since 2019 means the SACCO cannot demonstrate that the disks are readable, that encryption keys and software licences are recoverable, that the database backup is transactionally consistent, or that staff know the sequence of steps. It also removes the only feedback loop that would have exposed the gap before an incident. Examiners and auditors treat untested backups as a significant deficiency in the general IT controls, not as a minor housekeeping point.

Design standard: three copies of the data, on two different media, one of them off-site and immutable, with a retention long enough to survive a ransomware dwell time measured in weeks, plus continuous shipping of database transaction logs to meet a one-hour RPO.

Workings: 40 GB × 1,024 MB = 40,960 MB; × 8 bits = 327,680 megabits. At a theoretical 2 Mbps upload: 327,680 ÷ 2 = 163,840 seconds = 45.5 hours (about 1.9 days). Even treating 40 GB as 40,000 MB (320,000 Mb), the result is 160,000 seconds = 44.4 hours.

That figure is the best case. ADSL upload is contended and shared with branch traffic, and TCP/IP and encryption overheads typically leave 60–70% of the nominal rate, pushing the realistic transfer to 60 hours or more. A nightly full backup over this link is therefore impossible - it could never complete inside a night, let alone an eight-hour recovery window, and it would saturate the link so that core banking traffic fails during the day.

Alternatives that do meet the objective:

1. Seed the first full copy physically - export to an encrypted drive and ship it to the cloud provider or a second site, then send only changes thereafter.
2. Change the backup model - 40 GB of nightly change on a SACCO's data is implausible; it points to the backup job re-reading entire file systems. Implementing block-level or database-level incremental backup, with transaction-log shipping, should reduce the hourly volume to megabytes.
3. Size the link to the RPO - to move, say, 5 GB in an hour needs roughly 11–12 Mbps sustained upload, so a fibre or bonded-link upgrade is a prerequisite for any real-time copy.
4. Local first, cloud second - write to a local disk-based appliance during the night and replicate the appliance off-site continuously, so recovery does not depend on downloading from the cloud.

Order of spending (greatest risk reduction per shilling first):

1. Immutable off-site copies (~KES 400,000 one-off, ~KES 25,000/month). A disk appliance with object-lock or a cloud vault, plus an encrypted rotating disk held in a bank safe or a third-party site. This directly closes the RPO gap and defeats ransomware that encrypts mounted volumes.
2. A second virtualisation host at head office (~KES 900,000). Two hosts with shared or replicated storage let the core banking virtual machine be restarted on the surviving host. This is the only realistic route to an 8-hour RTO.
3. Power protection and network resilience (~KES 150,000 one-off, plus fibre upgrade from the monthly budget). A UPS sized to the second host and a second internet link with automatic failover.
4. Immutable retention of 90 days, database log shipping and quarterly tested restores. Formal DR runbook, named recovery team, evidence retained for auditors.
5. Preventive controls from the monthly budget: multi-factor authentication on email and remote access, email filtering, endpoint detection and response, and staff phishing awareness. The March incident started with a phish, not with a failed disk.

On the branch server: it improves resilience to fire or theft at head office, but an always-on replica that is domain-joined and reachable by the same credentials will be encrypted by the same ransomware - it is replication of corruption, not protection against it. The branch also lacks suitable cooling, stable power and physical security, and has nobody able to manage it. Unless it is deliberately air-gapped with immutable snapshots and log shipping configured, it gives false comfort. Fund it only after item 1 and item 2, or not at all.