Full backups & point-in-time recovery
Understand what is stored, how far back you can go, and what recovery means.
Two parts make recovery possible
A full backup is a consistent base copy of your database. Recovery logs record later changes: PostgreSQL uses WAL, MySQL uses binary logs, and Valkey uses timestamped append-only logs. Together they can recover to a specific available point in time.
Backups live in cloud storage
Creating a backup does not create another database instance. Full backups and recovery logs are stored separately from your database server in S3-compatible storage. The backup list will show completed full backups, their sizes, and their status.
Use the actual recovery window
Your plan defines retention, but the usable recovery window depends on a valid full backup and a complete sequence of uploaded logs. Use the earliest and latest recoverable times shown in your workspace. Do not assume the last few seconds are always recoverable.
Valkey recovery and expiring keys
Valkey backups include its append-only base and timestamped changes. A point-in-time restore replays the available log up to your chosen second. Keys retain their original expiry timestamps: a key whose expiry has passed at the current time may already be absent when you connect to the recovered server. This is not a rewind of the server clock. Treat caches as rebuildable data and keep durable application records in PostgreSQL or MySQL.
Retention and storage are different limits
Live database storage and backup storage are separate allowances. Retention cleanup must keep the full backup and logs needed for advertised recovery points. Failed or incomplete backups are not restore points.
A single database instance does not provide automatic failover. Backups help recover data; they do not eliminate downtime.