i saw your now dead comment about how no one you interviewed had an answer…
just it’s surprising to me that devops folk aren’t in an org that has backup software, cause this kind of testing is standard load out for most backup softwares, and they even solve the space and isolation issue with various instant restore / publishing capabilities where data from the backup is mounted directly to some staging server with postgres or whatever installed in an isolated area
not trying to knock the idea you are correct most ppl don’t test their backups, but it’s a bit strange no one you talked to used any of the most common backup softwares
definitely in favor of free solutions as backup software field is awful like many ent tech fields, but like the workflows do exist
This is a great idea and something I've faced and had to implement manually in the past.
The most common scenario for me was: I implement backup, done by a daily cron calling pg_dump. It worked and I moved on, until one day I needed to restore and the backups did not work. Typically at some point the VM failed to run the commands to clear temporary backup files, the disk would fill up and the new backups would be truncated mid way.
psql is pretty awful at identifying this which must be a very common scenario. Instead of a header check leading to "Corrupted backup, aborting" or something, it simply executes the SQL commands until it reaches the very last line, which will be truncated midway and thus invalid SQL.
Anyway, it took some time to figure out, but later I did basically what your tool does, probably simpler: another daily cron job that downloads the file and checks if it ends with the correct pg_dump success signature. It has worked so far.
This is a great idea. Anything that makes this easier is a win for ops teams.
The problem i see with this approach is that nearly nobody uses dumps as backups. I consulted Postgres for a few hundred customers and the amount of times that I saw dumps as Backup can probably be counted on two hands.
Does not help that the description reads like AI slop.
[flagged]
[flagged]
> There are other tools in this space. Worth naming plainly instead of pretending they don't exist.
Why do LLMs like this kind of writing? Why did you need to “plainly” name the competition as opposed to “flamboyantly” naming them?
This is a cool idea but the README is absurdly not-to-the-point.