Most people think of a backup as something that is simply there. A manual backup on our host, Kinsta, is not: it has an expiry date. Ours reads 4 November 2026, and this is what we did about it, so you can do the same with yours.
Whose backup it is
Our blog’s staging environment on Kinsta once held another site: the old version of grafica.group. When staging was turned into a copy of the blog, we took a manual backup on Kinsta first. That backup became the only copy of the old site anywhere, and the backups page showed the date it would expire.
Download and backup are not the same thing
The obvious plan was to download it and keep it on our own drive. It did not work that way. The host’s download button builds an archive of an environment as it is now, not of an old backup. The old backup offered one action only: restore it to staging.
So on 6 October we did it in four steps:
- Took a fresh backup of staging as it was, so we could put it back.
- Restored the old site’s backup to staging.
- Created the download of staging, which was now the old site, and saved it to our own drive.
- Restored staging to what it was before.
How we know the archive is the old site
A file called «backup» proves nothing. We recorded the archive’s size, about 500 MB, and its SHA-256 checksum, a fingerprint that changes if a single byte does, and computed it again on a second machine. Then we looked inside: the old site’s theme and its old homepage line were there, and the blog’s theme was not. Only then did we call it kept.
The host’s own copy still expires on 4 November. Ours does not.
Check yours this week
- Find every backup that is not automatic. Manual backups, backups taken before a migration, exports a previous developer made. Write down where each one is and when it expires.
- Ask what «download» gives you. Today’s site, or the backup you are looking at? Ask before you need it.
- Keep one copy you control, with its date and checksum written next to it.
- Open the copy. A backup you have never opened is a hope, not a backup.
- Put the date in a calendar a week before the expiry, with the decision written in it: keep or let go.
We follow the same rule in our maintenance routine: the backup’s time goes on the sheet before the first edit, and on our own blog’s last fix pass we wrote its expiry date next to it. The rest of that routine is in How we maintain WordPress sites on Kinsta. If you are not sure what your site’s backups would give you on a bad day, talk to us.
Gráfica built this survey as a WordPress plugin, and builds plugins like it for clients. Tell us what your site needs
