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
It seems to be a self-instruction. Leak from reasoning token into output token or using output token for reasoning. Perhaps something accidental like constraining number of reasoning tokens leads to model using output tokens for reasoning or perhaps ensuring some minimum user-visible reasoning. Seems like an accidentally introduced artifact.
“I should not pretend other implementations don’t exist. I should name them plainly.” Unable to tell itself that it puts this in output so that it can tell itself there.
Same with the “not X but Y” style. It is self-steering introspection leaking into output for one reason or the other. Recent poor language use by model is probably an attempt to minimize this by being concise. But it really needs more thinking to solve problem and so it does some of it in output.
Fair, you're right. Thanks for the point. I used ai for a chunk of the build and writing. However, the actual work behind it wasn't AI-generated. I spent a few weeks interviewing people in r/devops and some compliance subs about how they actually test backup restores, and the report schema especially came out directly out of those conversations.
You are also right about the REAME. I'll tighten it up right now, and enhance it. Thank you for the feedback.
What bothers me personally the most is trying to hide it. Why did you remove Claude's (or whatever you used, but looks like opus to me from the style) co-author info?
I'm willing to use (semi-)vibecoded projects under certain circumstances, but I like to know up front what I'm getting. The github contributors list makes that easy to see as long as people don't try to hide it.
I don't have a good defense here, it's fair. But part of that was because of messy commit history and I wanted to have a clean commit history. Maybe it's not a good reason as well, but it was my real intention and my desire of perfectionism :)
reason is that I wanted to take the full control, when ai do the commits you normally don't check the code and you loose the control, well I think it's the most important thing.
But Going forward, for building trust, definitely take your recommendation.
The actual design, the report schema especially, came out of around 30 interviews with people who handle backup testing as part of their job.
Thank you for the feedback.
Thanks for taking the time to reply! Hope my comment didn't sound too harsh, now that I read it again it might, that's what I get for posting in a hurry.
Seems like you put a lot of thought and effort into it which is awesome, so the LLM readme was ruining first impressions. It's a shame but given the explosion in low effort projects it's important to stand out I think.
I don't know if it's just solely how I use them, but when I've had Gemini commit and push things, it has never added a co-author or anything. I've recently been playing with Claude and Opus 5, and it only does it maybe 75% of the time. I truly don't know why
I think this is more Claude writing than LLM writing. GPT-5.6 also talks like an LLM, but not like this.
With GPT-5.6 I get reasonable results with "use natural, plain English". I tried "use ASD-STE100 Simplified Technical English" but I've found "natural plain English" to work better. Still not on the level I would write, but better.
In the mean time, I hear that Claude resists changing its writing style. A PO used Claude to write release notes and it was full of Claudeisms and tried changing the text into a TED talk. Then he prompted Claude to rewrite in ASD-STE100 Simplified Technical English, and Claude barely changed its writing. Then he switched to GPT-5.6 Terra, and GPT revised everything and made the text much better.
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.
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
> 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.
It seems to be a self-instruction. Leak from reasoning token into output token or using output token for reasoning. Perhaps something accidental like constraining number of reasoning tokens leads to model using output tokens for reasoning or perhaps ensuring some minimum user-visible reasoning. Seems like an accidentally introduced artifact.
“I should not pretend other implementations don’t exist. I should name them plainly.” Unable to tell itself that it puts this in output so that it can tell itself there.
Same with the “not X but Y” style. It is self-steering introspection leaking into output for one reason or the other. Recent poor language use by model is probably an attempt to minimize this by being concise. But it really needs more thinking to solve problem and so it does some of it in output.
Fair, you're right. Thanks for the point. I used ai for a chunk of the build and writing. However, the actual work behind it wasn't AI-generated. I spent a few weeks interviewing people in r/devops and some compliance subs about how they actually test backup restores, and the report schema especially came out directly out of those conversations. You are also right about the REAME. I'll tighten it up right now, and enhance it. Thank you for the feedback.
What bothers me personally the most is trying to hide it. Why did you remove Claude's (or whatever you used, but looks like opus to me from the style) co-author info?
I'm willing to use (semi-)vibecoded projects under certain circumstances, but I like to know up front what I'm getting. The github contributors list makes that easy to see as long as people don't try to hide it.
I don't have a good defense here, it's fair. But part of that was because of messy commit history and I wanted to have a clean commit history. Maybe it's not a good reason as well, but it was my real intention and my desire of perfectionism :) reason is that I wanted to take the full control, when ai do the commits you normally don't check the code and you loose the control, well I think it's the most important thing. But Going forward, for building trust, definitely take your recommendation. The actual design, the report schema especially, came out of around 30 interviews with people who handle backup testing as part of their job. Thank you for the feedback.
Thanks for taking the time to reply! Hope my comment didn't sound too harsh, now that I read it again it might, that's what I get for posting in a hurry.
Seems like you put a lot of thought and effort into it which is awesome, so the LLM readme was ruining first impressions. It's a shame but given the explosion in low effort projects it's important to stand out I think.
I don't know if it's just solely how I use them, but when I've had Gemini commit and push things, it has never added a co-author or anything. I've recently been playing with Claude and Opus 5, and it only does it maybe 75% of the time. I truly don't know why
I think this is more Claude writing than LLM writing. GPT-5.6 also talks like an LLM, but not like this.
With GPT-5.6 I get reasonable results with "use natural, plain English". I tried "use ASD-STE100 Simplified Technical English" but I've found "natural plain English" to work better. Still not on the level I would write, but better.
In the mean time, I hear that Claude resists changing its writing style. A PO used Claude to write release notes and it was full of Claudeisms and tried changing the text into a TED talk. Then he prompted Claude to rewrite in ASD-STE100 Simplified Technical English, and Claude barely changed its writing. Then he switched to GPT-5.6 Terra, and GPT revised everything and made the text much better.
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.