Uptime
Backup
Backup is a separate, restorable copy of data taken at a point in time. A second server kept in sync is not a backup, because a deletion replicates instantly.
How it is measured
Measure by restore, not by file. Track the age of the newest good copy, its size, where it is stored, and whether a restore test completed. Success means the restored site loads and the database row counts look plausible.
Time the restore. A 40 GB uploads folder plus a 3 GB database over a 100 Mbit link takes well over an hour, and that time feeds directly into your RTO.
Worked example
A WordPress recipe site runs nightly dumps at 03:00 to an S3 bucket in a different account, keeping 14 daily copies. On Monday a plugin update truncates wp_posts at 11:20. The newest backup is Monday 03:00. The owner restores it into a staging database at 11:40 and finishes the swap at 12:25.
Eight hours of comments, 11 of them from paying members, are gone. The backup worked exactly as designed. The owner then adds hourly binlog shipping for the database only.
How it differs
Backup keeps a historical copy you can roll back to. Failover moves traffic to a live twin. A failover target copies a bad delete in seconds. A backup still holds yesterday's rows but takes hours to bring online.
Common errors
Never restoring one. Storing the copy on the same disk or under the same login. Backing up files but not the database. Keeping no old versions, so slow corruption overwrites every copy. Forgetting the encryption key needed to open the archive.
In practice
Pick a Friday, restore last night's backup to a scratch host, and log how long it took and what was missing. Put that time next to your RTO. Copy one generation to storage under a different account.