Rather than make suggestions and not reading what someone posts, why not reply to specific points. I am going to assume for the moment that you really do have an interest in the whys, and, actually care and are not just posting to be troublesome as you did in the other ticket. Hopefully, clearly, you agree that I am somewhat passionate about this need. Maybe, just maybe, there is a reason.
So, first, some background.
We are consultants and system admins. We do all sorts of troubleshooting work for people with problems, and many other sorts of things. In this specific case, I am speaking of Virtualmin or Virtualmin PRO customers, who, either, were set up by themselves, or, someone else and have a problem of some sort. So, asking ME to do this or that is 100% irrelevant to what I am asking for, so, please understand this point. We do a lot of work beyond Virtualmin (it’s not a huge market and not what we specifically target), but, this is the topic here. So, it is simply not relevant to say run a filesystem backup or use webmin backup. Ok? It is also the case that we also have our own systems which we DO manage, and, some clients systems which we do setup and manage. That is not the issue here, for the most part. But it still is an issue that can be made simpler.
Now, we have had the joy of restoring around 20 systems in the past year or so, not sure why so many this year compared to previous years, maybe word of mouth, who knows. 19 of those posed major problems. So, before we go anywhere, understand, 19 out of 20 immediately says to me there is a problem without knowing any other info. Would you agree with that? Now, I will admit that there are likely many people who don’t have major problems as they of course would not be coming to us.
Most of these people (or whoever installed their system) ASSUMED that virtualmin backup backed up virtualmin, which included webmin. It’s not a separate system, after all, they installed virtualmin NOT webmin (their point of view). Reasonable? Yes. Technically correct? No. It doesn’t back up “webmin” as you may know. SOME of them assumed it backed up the system, I do not believe that can be helped except with maybe some help text. We agree on this one I am sure.
So, there’s your background and why your thoughts and suggestions are meaningless to this point.
Now, what types of problems do people have. Let’s go over, for example, what the Virtualmin doc says THEY do and analyze how that would work. Their “use case”. Perhaps it works well for them. Curiously, they have this comment in the doc:
“Daily backups of all virtual servers on the system using Virtualmin’s Backup feature. We do a full backup, including Virtualmin meta-data and Webmin stuff”. Hmm, what does the “and Webmin stuff” mean? Do they really do this from virtualmin backup?
Going down the page, and obviously recognizing the problem, it says this for remote systems:
“Restore the virtual server backups from the Virtualmin backups. Test. If something is broken (because of customizations I did outside of Virtualmin to non-Virtualmin related services), install the necessary packages (assuming I installed everything from packages, as I generally do), and restore the configuration (if necessary) by selectively pulling stuff out of the filesystem dump”
Does that sound easy or trivial? Well, imagine if you will an admin trying to help someone else out who doesn’t really know what they may have ever done? Not trivial. Not when it says “outside of virtualmin”, this also means anything done in webmin which is technically outside of virtualmin.
So, this is in the official doc. If you have a problem with that, blame them. Does this sound like something a new user of virtualmin might understand completely and easily?
My understanding, is what they are doing is actually different than what the doc says. I believe, and may recall incorrectly, they only do the filesystem backup monthly or something like that. If that is the case, then, this poses many other problems. As you will see below.
So, now we come to the next idea, you said to merely run virtualmin backup and webmin backup. Ok, have you done this? I challenge you to restore a system using this technique. this technique will in fact work as long as both are done on the same schedule. If they are not, it may still mostly work if the system is fairly static. If the system has new servers added and created a lot, and, named record changes, who knows what else, then, this fails miserably.
Why does that fail? Well, if they are not on the same schedule, then, here’s the problem. First, you make a choice, restore webmin then virtualmin via their backup modules, or, virtualmin then webmin. So, take webmin then virtualmin. Ooops, your restore of virtualmin fails. Why does it fail? Well, because it starts to get confused because things already exist that it does not to expect to exist. Given enough time, you can make this work by manually taking care of things.
So, let’s try the other way, let’s restore virtualmin THEN webmin! Well, that has another problem, given the assumption they were not done at the same time. Now the problem is apache changes, bind changes, you name it is not as current on the webmin configuration backup, so, now you have missing stuff.
The third way is to do what the virtualmin doc said, which is manually fix things.
Ok, so, back to the beginning. Remember, not systems we set up. How could ALL of this be avoided? Adding a simple checkbox to the virtualmin backup screen to backup not only virtualmin, but, webmin settings. The “hidden task” here is for the programmers to actually work out the details I mentioned and make sure one does not overlay the other with invalid info, data not stored twice, etc.
So, I ask you, which is easier for a non professional? Which do you think would be easier and less work to restore? Is that asking too much, to actually make it more easy to use and learn?
So, you other point was why duplicate the backup? In reality, I assume they would not be exactly the same since you have to consider what the other module does backup. Secondly, there are all sorts of stuff already in virtualmin that exist in webmin! Third - it will cause LESS problems for users of virtualmin and make the restore process easier for all. Shouldn’t that be what we want?
What types of things go wrong you ask? Some examples. Perhaps the customer changed their bind to not do ipv6 name resolution since they are running on a VPS with little memory, and, also some other bind settings to reduce memory. You restore a virtualmin backup, well, guess what, the system doesn’t run, out of memory. Why? Because that’s “outside of virtualmin”. Nevermind the changes were made mostly or entirely in webmin, which was installed by virtualmin.
Maybe the customer raised (or reduced) limits in httpd.conf via webmin. So, we restore the backup, and, complaints all over for apache problems. Why? Well, it doesn’t restore the apache configuration that was changed by a user in webmin, which they didn’t see themselves as installing.
Obviously, you should realize by now I have tons of examples, but more are pointless. This explains is clear detail what the issue is.
If you still disagree, that’s fine, but don’t say there isn’t any issue. There IS, else, we would not be getting this business. Which is fine, perhaps I should not complain, my complaint is more out of wanting users to not have to pay more and more for something that I believe can be avoided, fairly easily.
Yes, I do realize this does not resolve the support ticket we both commented in as that was from a customer who wanted a perfect backup of everything on the system. I am not at all asking for that, I just want a perfect backup of virtualmin, which includes webmin! So, that users of the product can more easily understand and backup their system without endless research and planning. Perfect in reality? No, but many of the 19 problem systems we had would have been avoided. But not all of them.
Imagine, user wants to restore, they have installed the packages and virtualmin, and they simply click restore. How nice would that be?