Do you actually test your database backup restores?
Honest question. I've got automated daily pg_dump backups going to S3 and I check that the files are there, but I've never actually tried restoring one on a fresh instance to see if it works.
Feel like this is one of those things where you assume it's fine until you desperately need it and find out the dumps were corrupted for 3 months.
Anyone have a setup where restores get tested automatically? Or is that overkill for side projects?
4 replies
An untested backup is no backup at all. At least test once or twice per year.
But I usually do it manually by restoring into a new instance, rather that have it done on a script.
We have customers who do monthly restore tests. I haven't restored my home env in a while.
I noticed I could not restore pg dumps as expected when migrating to a new server. I had to add some parameter to pg dump so it's a better/more neutral dump or something, which was easier/able to restore. So - definitely check your backups.
Trying the restore locally is also an option. Just to verify it works and the expected data is there.
How important it is to verify and verify regularly depends on how much loss you're willing to accept.
Once verified, as long as you don't do big version upgrades or automation changes, I would expect it to continue to work indefinitely. A semi regular verification still makes sense, though.
At work I know my DB backups definitely work for other reasons, due to regular restores in non-prod.
For side projects I definitely recommend verifying it at least once, when setting up automated backups/scripts for backup creation.
Built my first environment a couple of hours ago for a mission critical project. In this case, and a bit of overkill, we have hourly backups, and the process then spins up a VM, sets up pgsql, uploads the fresh backup, reports it as ok and then stores it, if it fails, requests a fresh backup, or calls the admin to report a problem.