And before everyone says go and use cPanel, I do on my other server
I like the cPanel backup, it allows me to extarct easily the things i want and extensively it is one archive, i ordered folders. It is not a single archive with multiple archives inside with arbitrary file extensions.
It is just a thought as it would allow a lot more interoperability between the systems and lead to more of an up tick in adoption of Virtualmin.
Now there are differences between how Virtualmin and cPanel functions (a.k.a Virtual Servers)
Ah, so the cPanel backups are human readable friendly. Hmm.
As a systems admin, I would like that, of course, but I am fine with doing a full restore of a Virtualmin backup on a staging system and then accessing the files where I know I can find them.
Yeah, till the time cPanel changes the internal structure of their backups. Joe can tell you how many hundred times that has happened thus farâŠ
It would be quite trivial, I imagine, to write a utility to convert the directory structure and files of Virtualminâs backup into a human readable friendly format.
Though, quite frankly, in all these yeas, I have never needed to peek inside the trio of files that Virtualminâs backup generates.
I think the virtualmin backups are messy and inconsistent. I have never liked them.
People donât like cPanel but their archives are very neat and logical. If needed, I can give a bit more in-depth feedback but I have just got back from the gym.
First off, everyone is entitled to their opinion on how things work best for them.
That being said, most backup systems have their own way of handling things in a manner that makes sense to them. The backup system designed by Virtualmin is intended to be used with Virtualmin restoration, so if doing so, it doesnât matter how the archives are stored since youâre not typically looking inside them yourself.
That being said (yes I love that phrase), if you take the time to learn about the archives created, theyâre not that difficult to understand, extract from, or work with.
Changing the way a backup is stored wouldnât IMO cause some mass adoption of Virtualmin. There are tons of reasons based on personal preference why some use cPanel, and others use Virtualmin.
Once upon a time I used Plesk, then DirectAdmin for a moment and finally Virtualmin once it was developed. My journey started long before Virtualmin was created so I used what was available. Iâve tracked the Webmin and later the Virtualmin project, and once it became somewhat stable, I adopted it.
Going back to the original point though. Feel free to make âsuggestionsâ for what you âfeelâ are good ideas, but before making claims that one change is going to change the world, be sure to make sure youâve actually got evidence to back it. Also remember, this is Virtualmin, NOT cPanel.
Easy, cpanel backups are much easier to manipulate the data and extract what I need i.e. extracting to xampp I can just drag and drop the public_html folder. All the SQL databases are in on folder so are easy to identify, can be dragged and dropped to the desktop ready to use because they have the .SQL extension.
Whatâs wrong with that ? The âouterâ archive has a logical structure but each to their own. Iâm not sure by not compressing the domainâs home directory that brings anything to the party considering itâs containing everything that the admin needs to restore all email users, their emails and the domainâs web content the other bits of the outer archive contain mysql dumps etc and virtualmin settings for that domain. The format was designed (I guess) with the Virtualmin restore function in mind which makes total sense if you look at the virtualmin restore ui. It would appear you wish webmin/virtualmin to be a free clone of cpanel as most âimprovementsâ you suggest seem to mirror how things are done in cpanel. So if you want a free varient of cpanel why not fork webmin/virtualmin ( it is open source) and recode the bits of webmin/virtualmin to your liking and release it as either shouldersmin or shoulderspanel then we donât get threads here that are suggesting that virtualmin/webmin should clone cpanel
However if you look at 1970s austins some had square/rectangular steering wheels so that inallergy could be be the difference between backup archive formats, they both do the same thing but look totally different this one looks quite good
But, we could do a better job documenting out backup format. I donât think itâs really documented anywhere, beyond saying itâs compressed tarballs (containing some other tarballs). We focused on making it readable using standard tools that everyone would already have on their server, but without docs, I guess it can be hard to figure out where everything ends up.
I will mention itâs possible to selectively restore stuff from backups in the GUI (or CLI), which means in a lot of cases you donât need to know where something is in the backup, because Virtualmin will pull it out for you. But, for looking at one specific file or checking for changes or whatever, I can see how being able to poke around in the backup would be useful.
We could also create a CLI sub-command to extract a Virtualmin backup in a user-friendly way with a nice hierarchy, with all the data extracted and ready.
However, one downside is that the extraction would have to be done on the server.
Alternatively, we could provide a script that a user could run against the Virtualmin backup on their system, maybe?
Ignoring all the work and effort (wasted) who/how many are even interested?
possibly of more use - as a one off - but shouldnât such things be down to the user to develop and pay for - what does it do for the average Virtualmin user who is presumably paying for this work?
I donât think thatâs a good use of time, and doesnât even solve the problem (it would need documentation, need users to learn a new tool, etc.). Simply documenting the damned thing would solve the problem.
The backups are not complicated or obfuscated, and there are already CLI tools for working with the backups! (tar being the primary one)
But, it does require a little bit of poking around to figure out where things are. If there were documentation of the format, that spelunking would no longer be needed.
Really, the problem needs a page of documentation (again, itâs not complicated, a single page can cover it), it does not need more software.