This website is deprecated, and remains online only for historic access to old issues and docs for historic versions of Virtualmin. It has been unmaintained for several years, and should not be relied on for up-to-date information. Please visit www.virtualmin.com instead.
Would be cool to be able to backup VirtualMin's module configuration (and any other linked modules) so that it can be restored, or mograted to another server.
Faisal is correct, but I'll expand upon it to explain the various types of backup and what they're for.
A Virtualmin created backup is a backup of one or more domains, in one of several reasonably standard (i.e. you can recover files from the without Virtualmin if you needed to, though the configuration data will be tucked into files that only Virtualmin will understand what to do with--though if one needed to, it wouldn't be hard to write a recover script that didn't need Webmin/Virtualmin). This backup can be restored on any Virtualmin server that is configured similarly (i.e. same mail server, homes location, etc.), and the domain(s) can be expected to work the same way. The backups are somewhat abstracted out, so things should copy over even when there are minor configuration differences on the system, but because Virtualmin is extremely flexible and supports many mail servers and practically infinite possible combinations of other software and configuration options, recovery between two widely differing systems could be a bit more difficult. In those cases, you'd need to fix some things by hand, or modify the provided tools to make the changes. Anyway, this backup can include (it is configurable) the system users, the mailboxes, the Webmin users, the web/mail/DNS, as well as database data. Everything belonging to a domain should come through a backup/restore process.
Next up is the Backup Webmin Configuration Files module. This one lives under the Webmin tab, and will backup your Webmin configuration files (I feel like that is a redundant statement!). You can choose to backup Virtualmin's configuration, along with any other modules that you have changed the configuration of. In many cases, you won't change many Webmin configuration details, but Virtualmin is a unique module that practically will always be modified by the end user to make the created domains fit local policies and practices. So, this will allow you to restore the Virtualmin settings to a new machine.
Finally, there is a Filesystem Backup module located under the System tab. This one is the big bomber of a backup, which makes a complete copy of your system in a format that can be recovered all at once, or on a file-by-file basis. It can use dump or tar, and supports tape changes and all of the other good stuff one would expect of a backup utility.
Realistically, one probably needs to keep all of these types of backups for peace of mind. Virtualmin.com uses the following backup routine:
All backups are written to a remote network file system partition provided by our hosting provider using cifs. It is large enough to store about twice our complete disk usage, excluding the software repositories (which are backed up via other mechanisms locally where we actually do the work on the repository).
Every week, I run a full system backup using the Filesystem Backup module. I use dump, which backs up all attributes (including quotas). dump is the default mode. Some file systems don't support dump, and tar would need to be used.
Every day, I run a full backup of all Virtualmin domains using the Virtualmin backup feature. This gives me the ability, for example, to reasonably quickly bring up software.virtualmin.com (the license and software downloads domain) on an alternate machine should something terrible happen to our primary server. I use a backup format of one tarball per domain.
Also every day, I run an incremental backup using the Filesystem Backup module. This just backs up all files that have changed since the last full backup to a separate file. dump is use for this backup, as well. dump supports many more levels of increments than this (I have mine configured in two levels--full and last-since-full--which is indicated by numbers 0 and 1, I think), but because my backups are on a network attached storage device and my dataset is reasonably small, I don't have any motive to reduce tape swaps or backup time.
I don't actually use the Webmin Backup Configuration Files module, but will do so now that I'm thinking about it. I haven't made many changes from defaults in the Webmin configuration, but no reason not to back them up too...they're quite small, generally.
This pretty much mimics my configuration on SciPy.org, which is a large Open Source project server that I administer, except there is site-wide usage of rdiff-backup to a terabyte file server instead of the Webmin provided Filesystem Backup. Both methods work fine, and rdiff-backup is quite cool in its own right...one of these days in my copious free time, I'll probably write a module for it.
So, to answer your request: With appropriate planning, you can do everything you'd like to do with the existing tools in Virtualmin Professional (and Webmin+Virtualmin GPL).
Excellent post, Joe! It would be great to have it preserved somewhere more permanent, such as in the documentation or the FAQ. I'm sure it will be helpful to others not reading the forums and may want to refer to it again in the future.
On another note, since this is the Feature Requests forum, I think it would be a good idea further down the road to consolidate and simply these different backup modules (especially Virtualmin and Webmin Backup Configuration Files) to one place so administrators don't have to follow a multi-step procedure to get a complete backup. Or, alternatively, Virtualmin could back up its own configuration internally along with the domains.
I agree on both counts. There probably should be an aggregate "Backup Policies" module that can drive all of these types of backups from one screen and with one set of configuration options. But this is a problem not unique to Virtualmin, and not really very simple to address. Restoring a system, without actually restoring from a full backup (like the Filesystem Backup utility provides), isn't really feasible. In the same way, without backing up everything on the system, it's nearly impossible to <i>guarantee</i> that a restored Virtualmin virtual host will behave identically to the server it was backed up from--because Virtualmin manages a half dozen other services that could be configured differently outside of the realm of the virtual host configuration. In reality, a restored Virtualmin domain all by itself will behave identically in the vast majority of cases (and Virtualmin Professional reduces the number of variables that would change that by an order of magnitude), theoretically even across platforms, though there are some OS differences that could effect the veracity of this claim.
Anyway, to address the "restore must be identical" we probably can't simply add a Virtualmin configuration file backup function to the Virtualmin backup, because Virtualmin relies on the configurations of several other modules and servers in addition to itself. So restoring just the Virtualmin configuration would not necessarily result in a Virtualmin instance that behaves the same way (though it probably will, if other modules remained in their default configurations on both systems). So, if Virtualmin backups were extended to include all of the Webmin module and server configuration files it needs, that aspect of it would be identical to the Webmin Backup Configuration Files module. And if it were extended to included everything it really needs, we begin to approach a full backup of the whole system...It's probably easy to add a check box that says "Also backup related Webmin Configuration Files" that uses the existing Webmin backup utility, but I don't think this is the right way to go about it. Perhaps just the Virtualmin configuration and templates would be the biggest thing--the Webmin Backup Configuration Files module has recently been enhanced to include templates and everything Virtualmin needs, but perhaps it is unintuitive for it to be outside of Virtualmin and tucked away in the Webmin Backup Configuration Files module. There seems to be a tendency for folks to think of Virtualmin as its own entity that just happens to hide inside of Webmin. This isn't a wrong way to think of it since Webmin can be intimidatingly large, but it's probably not the right way to think of it either--it leaves a huge swath of functionality outside of your field of view (as you all probably know, Webmin has been in development for about eight or nine years--a lot of incredibly powerful stuff is in there).
In short, I think all of the functionality that is needed exists (and then some), but it isn't obvious how to use it. Again, the flexibility of the Webmin platform bites us a bit, and our job for Virtualmin Professional is to reign in the flexibility and select a Golden Path that is easy to understand, well-documented, and works for the vast majority of users. I need to think about this some, as repeating Webmin features into Virtualmin seems ugly...but having the necessary features spread across three modules also seems wrong.
I'll add a wish to the bug tracker and let Jamie think on it too. He understands all of the inner workings better than anyone, and usually has frightfully good insights on how things ought to be done to keep them simple and effective in implementation.
I'll also add some of this discussion to the FAQ. Backup is so important, it definitely needs to have more documentation devoted to it. I'll create a task for myself to add more documentation to the Administrator's guide. Maybe that will wait until Jamie and I have hashed out how the backup modules can do the Right Thing with regard to how the user perceives the features and how they are used--hopefully, we can make it easy enough that everyone will religiously backup their servers and occasionally confirm that the backups are complete and correct.
Ah, backups. The wholly boring subject that everybody needs to spend more time and effort on. ;-)
I just wanted to bring this to a satisfying conclusion by mentioning that the latest 2.97 version of Virtualmin adds the ability to backup all of your Virtualmin settings, templates, etc. in addition to the domain data. So, it's now possible to pick up and move between similarly configured servers without any pain.
The options are in the Virtualmin Backup Virtual Servers page.
Hi.
This is included in the backup utility by what i understand.
Faisal is correct, but I'll expand upon it to explain the various types of backup and what they're for.
A Virtualmin created backup is a backup of one or more domains, in one of several reasonably standard (i.e. you can recover files from the without Virtualmin if you needed to, though the configuration data will be tucked into files that only Virtualmin will understand what to do with--though if one needed to, it wouldn't be hard to write a recover script that didn't need Webmin/Virtualmin). This backup can be restored on any Virtualmin server that is configured similarly (i.e. same mail server, homes location, etc.), and the domain(s) can be expected to work the same way. The backups are somewhat abstracted out, so things should copy over even when there are minor configuration differences on the system, but because Virtualmin is extremely flexible and supports many mail servers and practically infinite possible combinations of other software and configuration options, recovery between two widely differing systems could be a bit more difficult. In those cases, you'd need to fix some things by hand, or modify the provided tools to make the changes. Anyway, this backup can include (it is configurable) the system users, the mailboxes, the Webmin users, the web/mail/DNS, as well as database data. Everything belonging to a domain should come through a backup/restore process.
Next up is the Backup Webmin Configuration Files module. This one lives under the Webmin tab, and will backup your Webmin configuration files (I feel like that is a redundant statement!). You can choose to backup Virtualmin's configuration, along with any other modules that you have changed the configuration of. In many cases, you won't change many Webmin configuration details, but Virtualmin is a unique module that practically will always be modified by the end user to make the created domains fit local policies and practices. So, this will allow you to restore the Virtualmin settings to a new machine.
Finally, there is a Filesystem Backup module located under the System tab. This one is the big bomber of a backup, which makes a complete copy of your system in a format that can be recovered all at once, or on a file-by-file basis. It can use dump or tar, and supports tape changes and all of the other good stuff one would expect of a backup utility.
Realistically, one probably needs to keep all of these types of backups for peace of mind. Virtualmin.com uses the following backup routine:
All backups are written to a remote network file system partition provided by our hosting provider using cifs. It is large enough to store about twice our complete disk usage, excluding the software repositories (which are backed up via other mechanisms locally where we actually do the work on the repository).
Every week, I run a full system backup using the Filesystem Backup module. I use dump, which backs up all attributes (including quotas). dump is the default mode. Some file systems don't support dump, and tar would need to be used.
Every day, I run a full backup of all Virtualmin domains using the Virtualmin backup feature. This gives me the ability, for example, to reasonably quickly bring up software.virtualmin.com (the license and software downloads domain) on an alternate machine should something terrible happen to our primary server. I use a backup format of one tarball per domain.
Also every day, I run an incremental backup using the Filesystem Backup module. This just backs up all files that have changed since the last full backup to a separate file. dump is use for this backup, as well. dump supports many more levels of increments than this (I have mine configured in two levels--full and last-since-full--which is indicated by numbers 0 and 1, I think), but because my backups are on a network attached storage device and my dataset is reasonably small, I don't have any motive to reduce tape swaps or backup time.
I don't actually use the Webmin Backup Configuration Files module, but will do so now that I'm thinking about it. I haven't made many changes from defaults in the Webmin configuration, but no reason not to back them up too...they're quite small, generally.
This pretty much mimics my configuration on SciPy.org, which is a large Open Source project server that I administer, except there is site-wide usage of rdiff-backup to a terabyte file server instead of the Webmin provided Filesystem Backup. Both methods work fine, and rdiff-backup is quite cool in its own right...one of these days in my copious free time, I'll probably write a module for it.
So, to answer your request: With appropriate planning, you can do everything you'd like to do with the existing tools in Virtualmin Professional (and Webmin+Virtualmin GPL).
--
Check out the forum guidelines!
Excellent post, Joe! It would be great to have it preserved somewhere more permanent, such as in the documentation or the FAQ. I'm sure it will be helpful to others not reading the forums and may want to refer to it again in the future.
On another note, since this is the Feature Requests forum, I think it would be a good idea further down the road to consolidate and simply these different backup modules (especially Virtualmin and Webmin Backup Configuration Files) to one place so administrators don't have to follow a multi-step procedure to get a complete backup. Or, alternatively, Virtualmin could back up its own configuration internally along with the domains.
Hey Alan,
I agree on both counts. There probably should be an aggregate "Backup Policies" module that can drive all of these types of backups from one screen and with one set of configuration options. But this is a problem not unique to Virtualmin, and not really very simple to address. Restoring a system, without actually restoring from a full backup (like the Filesystem Backup utility provides), isn't really feasible. In the same way, without backing up everything on the system, it's nearly impossible to <i>guarantee</i> that a restored Virtualmin virtual host will behave identically to the server it was backed up from--because Virtualmin manages a half dozen other services that could be configured differently outside of the realm of the virtual host configuration. In reality, a restored Virtualmin domain all by itself will behave identically in the vast majority of cases (and Virtualmin Professional reduces the number of variables that would change that by an order of magnitude), theoretically even across platforms, though there are some OS differences that could effect the veracity of this claim.
Anyway, to address the "restore must be identical" we probably can't simply add a Virtualmin configuration file backup function to the Virtualmin backup, because Virtualmin relies on the configurations of several other modules and servers in addition to itself. So restoring just the Virtualmin configuration would not necessarily result in a Virtualmin instance that behaves the same way (though it probably will, if other modules remained in their default configurations on both systems). So, if Virtualmin backups were extended to include all of the Webmin module and server configuration files it needs, that aspect of it would be identical to the Webmin Backup Configuration Files module. And if it were extended to included everything it really needs, we begin to approach a full backup of the whole system...It's probably easy to add a check box that says "Also backup related Webmin Configuration Files" that uses the existing Webmin backup utility, but I don't think this is the right way to go about it. Perhaps just the Virtualmin configuration and templates would be the biggest thing--the Webmin Backup Configuration Files module has recently been enhanced to include templates and everything Virtualmin needs, but perhaps it is unintuitive for it to be outside of Virtualmin and tucked away in the Webmin Backup Configuration Files module. There seems to be a tendency for folks to think of Virtualmin as its own entity that just happens to hide inside of Webmin. This isn't a wrong way to think of it since Webmin can be intimidatingly large, but it's probably not the right way to think of it either--it leaves a huge swath of functionality outside of your field of view (as you all probably know, Webmin has been in development for about eight or nine years--a lot of incredibly powerful stuff is in there).
In short, I think all of the functionality that is needed exists (and then some), but it isn't obvious how to use it. Again, the flexibility of the Webmin platform bites us a bit, and our job for Virtualmin Professional is to reign in the flexibility and select a Golden Path that is easy to understand, well-documented, and works for the vast majority of users. I need to think about this some, as repeating Webmin features into Virtualmin seems ugly...but having the necessary features spread across three modules also seems wrong.
I'll add a wish to the bug tracker and let Jamie think on it too. He understands all of the inner workings better than anyone, and usually has frightfully good insights on how things ought to be done to keep them simple and effective in implementation.
I'll also add some of this discussion to the FAQ. Backup is so important, it definitely needs to have more documentation devoted to it. I'll create a task for myself to add more documentation to the Administrator's guide. Maybe that will wait until Jamie and I have hashed out how the backup modules can do the Right Thing with regard to how the user perceives the features and how they are used--hopefully, we can make it easy enough that everyone will religiously backup their servers and occasionally confirm that the backups are complete and correct.
Ah, backups. The wholly boring subject that everybody needs to spend more time and effort on. ;-)
--
Check out the forum guidelines!
Thanks for the great reply Joe, I've probably looked at those tabs a few hundred times and never noticed the modules.
I'll shout RTFM at myself a few times :)
cheers
I just wanted to bring this to a satisfying conclusion by mentioning that the latest 2.97 version of Virtualmin adds the ability to backup all of your Virtualmin settings, templates, etc. in addition to the domain data. So, it's now possible to pick up and move between similarly configured servers without any pain.
The options are in the Virtualmin Backup Virtual Servers page.
--
Check out the forum guidelines!