Database backup storage in Kenya

Database backups that live on a different server

A dump file on the same disk as the database is not a backup. Send nightly dumps, physical backups and WAL archives to a separate storage server, encrypted and versioned, so a dropped table, a corrupted disk or a hacked host is a restore job rather than the end of the business.

Size your server Ask on WhatsApp

Size of your live databases

50 GB

We suggest

Storage S1 KES 2,000/mo

Up to 80 GB of live data compresses to about 27 GB per dump. Thirty daily dumps need roughly 800 GB, which fits on 1 TB with room for binary logs.

Order Storage S1

Your database server should not hold its own backups

It is common to find a cron job writing mysqldump output to /var/backups on the very server that runs MySQL. When that server is compromised, the attacker deletes both. When the provider loses the volume, both go together. When a developer runs an UPDATE without a WHERE clause on Friday evening, the only copy may be last night, if anyone checked that last night worked.

An off-server backup target fixes the first two problems, and versioned retention fixes the third. Logical dumps from mysqldump, mariadb-dump or pg_dump are easy to restore table by table. Physical backups from Mariabackup, Percona XtraBackup or pgBackRest are faster for big databases. Adding binary logs or PostgreSQL WAL archiving lets you replay changes to a point just before the mistake.

Be clear about what this storage is for. These plans use high-capacity SATA disks, which suit sequential backup writes and long retention. They are not built for the random input and output that a busy production database needs. Keep the live database on NVMe, and use the storage server as the place backups land, get checked and wait for the day you need them.

The problem

How database backups fail quietly

Backups on the same machine

A dump in the home directory of the database server disappears with the server. Disk failure, a lost VPS, or an attacker with root access removes the database and its only backup in one go.

Dumps that never finished

A full disk, a lock timeout or an expired password can leave a truncated .sql file that looks fine by name and size. Without a check on exit codes and a test restore, nobody notices until the file is needed.

Only last night to go back to

A bad import or a buggy release can corrupt rows days before anyone spots it. If you only keep one dump and it is overwritten every night, the clean copy has already been replaced by the damaged one.

Plain-text customer data in transit

Database dumps contain everything: customer names, phone numbers, password hashes and payment references. Copying them around unencrypted, or leaving them in a web-readable folder, turns a backup into a data breach.

What runs on it

Tools for off-server database backups

You install and configure these yourself, on the database host and on the storage server, with full root access on the storage side.

mysqldump and mariadb-dump

Logical dumps of MySQL and MariaDB. Use --single-transaction for consistent InnoDB backups without locking, compress the output, and stream it straight to the storage server over SSH so nothing sits on the database disk.

Mariabackup and Percona XtraBackup

Physical hot backups of InnoDB data files while the server keeps running. Much faster to restore than a dump for databases of tens or hundreds of gigabytes. Combine with binary logs for point-in-time recovery.

pg_dump and pg_dumpall

The standard PostgreSQL logical backup tools. The custom format (-Fc) compresses well and lets pg_restore pull back a single table. Run pg_dumpall --globals-only as well, so roles and permissions are not forgotten.

pgBackRest

Full, differential and incremental PostgreSQL backups with WAL archiving and point-in-time recovery. The storage server can act as a dedicated repository host over SSH, with repository encryption and retention rules set in one config file.

restic

Wraps any dump in encrypted, deduplicated snapshots. Pipe a dump into restic backup --stdin and keep 14 daily, 8 weekly and 12 monthly copies with a single forget --prune command, without storing every night in full.

Sizing

How much storage do your database backups need?

Enter the combined on-disk size of your live databases. We assume compressed full dumps at about a third of that size, with 30 daily copies kept and no deduplication.

10–80 GB Storage S1 Up to 80 GB of live data compresses to about 27 GB per dump. Thirty daily dumps need roughly 800 GB, which fits on 1 TB with room for binary logs.
90–350 GB Storage S2 Up to 350 GB of databases means about 117 GB per compressed dump, or 3.5 TB for 30 days, inside the 4 TB of Storage S2.
360–700 GB Storage S3 Up to 700 GB of live data needs about 7 TB for a month of daily dumps. Storage S3 has 8 TB and four cores for faster compression.
710–1,050 GB Storage S4 Up to 1,050 GB of databases produces around 10.5 TB of dumps over 30 days, within the 12 TB of Storage S4, leaving space for logs.
1,060+ GB Storage S5 Above 1,050 GB, Storage S5 gives 16 TB. At 1.4 TB of live data, 30 daily dumps come to about 14 TB, still with some headroom.

This is an estimate: compression ratios differ a lot between databases, and incremental tools like pgBackRest or restic usually need far less space than 30 full dumps.

Storage S1

KES 2,000/mo

1 core
2 GB RAM
1 TB SATA storage
2 TB transfer

Order S1

Storage S2

KES 5,000/mo

2 cores
8 GB RAM
4 TB SATA storage
8 TB transfer

Order S2

Storage S3

KES 7,000/mo

4 cores
16 GB RAM
8 TB SATA storage
16 TB transfer

Order S3

Storage S4

KES 15,000/mo

6 cores
24 GB RAM
12 TB SATA storage
24 TB transfer

Order S4

Storage S5

KES 20,000/mo

8 cores
32 GB RAM
16 TB SATA storage
32 TB transfer

Order S5

Before you go live

Setting up off-server database backups

0 of 8 done. Tick them off as you go.

Create a read-only backup user in MySQL or PostgreSQL with only the privileges the dump tool needs.
Stream dumps over SSH directly to the storage server, and check the exit status of every step in the pipeline (set -o pipefail).
Encrypt backups with restic, pgBackRest repository encryption or GPG, and keep the key off both servers.
Allow SSH to the storage server only from your database hosts, using keys restricted to the backup command.
Enable binary logs or WAL archiving if you need to restore to a moment, not just to last night.
Set retention rules (for example 14 daily, 8 weekly, 12 monthly) and let the tool prune old copies automatically.
Restore the latest backup into a scratch database every month and run a few real queries against it.
Alert when no new backup has arrived in 26 hours, not only when a job reports an error.

Built for Kenya

Database backups for Kenyan systems

Customer and M-Pesa records are personal data

Databases behind Kenyan shops, SACCO systems and school portals hold phone numbers, ID numbers and payment references. Under the Data Protection Act, 2019, backups of that data need the same care as the live copy, so encrypt it and restrict who can reach it.

Servers in more than one place

If your application runs with a foreign cloud provider, a backup server with a different provider gives you a copy outside that account. A billing dispute, a suspended account or a provider outage then does not leave you without your own data.

Restores over slow office links

Restoring a large database to a laptop in the office can take hours on a typical line. Restore to a server in the same data centre or another VPS instead, and check your upload and download speeds before you plan a restore drill from the office.

Questions

Database backups: your questions, answered

Can I run my production database on a storage plan?

It is not what these plans are built for. They use SATA disks chosen for capacity, which handle large sequential writes well but cannot match NVMe for the random reads and writes of a busy database. Run the live database on an NVMe VPS and send its backups here.

What is the difference between a logical and a physical database backup?

A logical backup, such as mysqldump or pg_dump, writes SQL or a portable archive you can restore table by table, even into a newer version. A physical backup copies the data files directly, which is much faster for large databases but restores to the same major version.

How do I get point-in-time recovery for PostgreSQL?

Take regular base backups and archive every WAL segment to another server. pgBackRest handles both, storing them in a repository on the storage server. To recover, you restore a base backup and replay WAL up to a chosen timestamp, such as one minute before a bad DELETE ran.

How often should I back up a MySQL database?

Ask how much data you can afford to lose. Nightly dumps mean up to a day of lost orders or records. If that is too much, keep binary logs and copy them off the server every few minutes, so you can replay changes on top of the last full backup.

Should database backups be encrypted?

Yes. A dump contains every record in the database, often including personal data and password hashes. Encrypt it before it leaves the database server, keep the key somewhere other than both servers, and test that you can actually decrypt and restore with that key.

How do I know my database backup will restore?

Restore it. Schedule a monthly job that loads the latest backup into a scratch database, checks row counts on key tables and records how long it took. A backup that has never been restored is a hope, not a plan.

Also on Storage Hosting

Ready to host your database backups?

Plans from KES 2,000 a month, paid by M-Pesa or card.

Size your server