@Joe You mentioned consolidating and cleaning up backups. I waited a couple days to apply some Postgresql software updates because my weekly full backup was scheduled.
First thing I did was go to the Postgresql module and do a backup. I noticed there is no restore. Also, it seemed to do each database individually with no ‘full dump’ which is kind of what I wanted here in case of some major fail in the upgrade. All went well so no big issue.
IF you did a consolidation, any thoughts on how it would work? Just one separate page and leave the module options in place? Redirects so you don’t have to maintain both?
There is. It’s just Create a database, and then “Execute SQL” in the empty database.
A dump is a pile of SQL, and a restore is just running that SQL in a database.
But, there probably should be a more clear path for that. Virtualmin, of course, handles it as part of its backup and restore, and so it’s clearly labeled there.
I don’t really know the best way to present this stuff, honestly. Adding more pages and forms and options, and providing several ways to do things with different implications, is dangerous for usability. But, having people think Virtualmin is backing up everything when it absolutely is not is also dangerous, and that seems to be relatively common. It does do a good job with databases owned by Virtualmin domains, though, I think.
But, we probably should offer a “Backup Dashboard” type thing, where we show whether Filesystem Backups, Virtualmin Backups, Configuration File backups, etc. are configured and happening regularly, and maybe show the status of the last backup.
I’ve done a full single file dump before. That’s kind of what I was expecting at the server module level in Webmin. Then it’s a one file restore. I just wasn’t fearful enough the upgrade would fail that I bothered to look up the commands. I make cheat sheets but then forget about them.
I do like the dashboard idea though. Even if it just becomes a ‘check list’ of used options and then have redirects.
