What a backup is not

RAID, replication, and snapshots all look like insurance, but they protect against different things. This lesson covers which data loss scenarios each mechanism closes, and how a backup differs from all of them.

Data gets lost in different ways

Before picking a tool, understand what you're defending against. Data loss scenarios vary a lot, and no single mechanism closes all of them.

Hardware failure: a disk dies, a controller burns out, power drops in the rack.

Human error: DROP TABLE in the wrong console, rm -rf in the wrong folder, a migration that wiped out half the rows.

Software bug: a bug in the app quietly corrupted data for a month, and nobody noticed until yesterday.

Malicious intent: ransomware swept through the network and encrypted everything it could reach, including network shares with copies on them.

Site loss: fire, flooding, equipment seizure, a cloud provider shutting down your account.

We'll go through this list and check the mechanisms that often get mistaken for a backup.

RAID: protection from a single disk

RAID keeps data across several disks so that the death of one (two, in RAID 6) doesn't stop the system. That's availability protection, and it only works against the first scenario.

Against everything else, RAID is useless. A deleted file disappears from every disk in the array at once, because to RAID that's just a normal write. Ransomware will just as neatly encrypt the data on every disk at once.

More on RAID in a separate lesson of the track. It also covers why rebuilding a large array is itself a risk.

Replication: protection from a node

A replica is a second database (or a second server) where changes arrive continuously. If the primary node dies, you switch the app to the replica and lose seconds, not hours.

The problem is the same as with RAID: replication repeats every change, including the bad ones. DELETE FROM orders with no WHERE reaches the replica within a fraction of a second. An async replica has a tiny window, but you won't manage to detach it by hand in time.

There's a middle ground: a delayed replica. It still receives the change log (WAL) right away, but applies it after a delay. In PostgreSQL this is the recovery_min_apply_delay setting, in MySQL SOURCE_DELAY (called MASTER_DELAY before version 8.0.23). Say the replica stays an hour behind. You get that hour to notice a bad query and pull data from the replica before it replays it too.

You can check how many changes a replica has received and how many it has applied right on the replica:

select pg_last_wal_receive_lsn(), pg_last_wal_replay_lsn();

On a regular replica, both values match. On a delayed one, the second position lags behind: the changes already sit on the replica's disk but haven't been applied yet.

Replication covers node failure, and partly site loss if the replica sits in another location. It doesn't protect you from human error or ransomware, and a delayed replica only helps within its own delay window.

Snapshots: a rollback point, but next to the data

A snapshot captures a volume or database's state at a point in time, and you can roll back to it in seconds. It's the best tool against human error: delete something by mistake, roll back thirty minutes.

That's where the similarities end. An LVM, ZFS, or disk-array snapshot lives in the same pool as the original: kill the array, and the snapshots go with it. Cloud providers' disk snapshots are built better. AWS EBS snapshots, for example, live in S3, separate from the disk itself, so they survive the disk's death.

What they share is something else: both kinds get deleted with the same permissions as the data. Deleting shadow copies and snapshots is a documented ransomware technique in the MITRE ATT&CK matrix, with its own number: T1490, Inhibit System Recovery.

A snapshot isn't a copy of the data. It's a pointer to a previous state of the same blocks. There's a separate lesson on that later.

So what is a backup

A backup is a separate copy of the data that:

• lives somewhere else, not where the original is, ideally managed by a different system;
• is never changed after the fact, and is kept versioned across past days;
• is verified by restoring it, not one that merely exists.

The first point closes site loss and ransomware. The second protects against human and software errors. The third turns hope into fact.

The mechanisms from this lesson don't compete with a backup. They work in layers. A replica keeps the service alive through a node failure, a snapshot rolls back a bad migration in a minute. A backup stays the last line of defense when nothing else worked.

Scenario	RAID	Replica	Snapshot	Backup
Disk died	yes	yes	cloud only	yes
Server died	no	yes	cloud only	yes
Human error	no	delayed only, within the delay window	yes	yes
Silent corruption over a month	no	no	if snapshots are kept for a month	yes, if versions go back a month
Ransomware	no	no	no, if it has permissions	yes, if the copy is out of its reach
Site loss	no	if the replica is elsewhere	only if stored elsewhere	yes, if the copy is elsewhere

A typical setup for a production service

A PostgreSQL replica in another availability zone: a node failure costs tens of seconds to switch over, not hours of downtime.

Disk snapshots every hour, kept for a day: a fast rollback for a bad release.

Database dumps and a file backup once a day to separate storage, versioned for a month: insurance against deletion, corruption, and ransomware.

A restore from backup onto a test server once a quarter: proof that all of this actually works.

Common mistakes

• "We have RAID, we don't need a backup." RAID survives a disk dying. It faithfully writes deletion, corruption, and encryption to every disk at once.
• "We have a replica, that's our copy." A replica repeats DROP TABLE and DELETE with no WHERE right along with every other change. A second later, the copy is gone too.
• Treating a delayed replica as a backup. It gives you a window the size of the delay. A mistake noticed later has already been replayed on the replica.
• Storing snapshots and backups under the same credentials as the server. Whoever gets access to the data can delete the copies too. Ransomware does this first.
• Never restoring from a backup, even once. Until a restore has been verified, you don't actually know whether you have a backup.

What you'll need for the tasks

• The list of data loss scenarios from the start of the lesson, and the takeaway: a regular replica repeats a bad query, a delayed one repeats it later.
• Connecting to PostgreSQL via psql and a simple query like select count(*) from <table>.
• show <parameter> in psql: this shows the value of a server setting, such as a replica's delay.
• A PostgreSQL replica is read-only: select, COPY ... TO STDOUT, and pg_dump work on it, INSERT and DELETE don't.
• Docker: the lab environment starts with one script, the commands for querying the databases are in the lab's README. Docker itself is covered in the docker-basics track.

Next, we'll cover the two numbers that the whole backup design grows out of: RPO and RTO.