Need a Cloudmin Backup

Just like Virtualmin has a way to backup the Virtualmin machine and it's settings, Cloudmin needs a way to backup the Cloudmin master and it's settings. Near as I can tell, there's no built in way and I would need to painstakingly try and figure out where all the settings I need to keep are, etc if I ever needed to rebuild or restore the Cloudmin master. Not using replication, and, replication is not a backup anyway. This backup should not have anything to do with storing the virtual machines, just speaking of the Cloudmin machine itself. Then, like Virtualmin, it should also support restoring backup on a new machine, i.e., to move Cloudmin to another machine.

Not having any backup facility was a surprising omission. Unless I missed it!



There is actually a way to do this - at Webmin -> Backup Configuration Files. However, you should be careful restoring such a backup on a different system, as it won't include the actual VMs - just their state as tracked by Cloudmin.

Thanks for advice but it's still missing most of options of Virtualmin such as incremental and way to keep only a range of backups depending on dates !

Yes, that's exactly what I was saying, you just beat me to it. It needs to be like Virtualmin backup and it's features, not, webmin backup.

Incremental backup doesn't really make sense here, since all that is being backed up are Cloudmin's own internal settings.

Ok, so, how do you backup the cloudmin server, without the virtual machines then? Webmin backup is backing up settings, not other files like Virtualmin backup normally does on a non Cloudmin machine. Maybe I have scripts there, some databases, who knows what. Virtualmin backup is not there in the normal manner, so, there is no easy and simple or standard way of backing those up, right?

Just want a regular virtualmin backup that backs up stuff just like Virtualmin does, without the virtual machines, with the same options, etc. It's missing.

What do you mean by "backup the Cloudmin server" exactly? If you just want to backup CLoudmin's own config, the module mentioned in comment #1 will do it. Otherwise if you want a full backup of the whole filesystem, use the module at Webmin -> System -> Filesystem Backup.

But I am not wanting EITHER of those. I do understand what you are saying, you do not get what we are saying though. Pretend, that the Cloudmin system had no virtual machines in it. I want to backup just like a virtualmin backup on any virtualmin machine without cloudmin. The other backups are not flexible and do not backup what I want. Can they? Sure, with enough effort, scripting, etc. But, why is virtualmin backup mostly disabled on Cloudmin? It's extremely useful, supports so many things that I want to backup. MySQL, you name it. The Cloudmin machine can run other stuff, email, Postgres, etc.

The virtualmin backup on a regular Virtualmin machine is very very useful. It's what I am asking for on a cloudmin machine. So, if you still don't get it, create a scheduled backup on a non cloudmin virtual machine. Exactly that!

Ok, I think I see what you mean now - however, the Virtualmin backups are domain specific rather than being for all MySQL databases or files on the system. Similarly, Cloudmin has a pretty complete backup feature that is designed to backup VMs, by copying their entire disk images.

Can you explain a bit more about what your specific setup and use case for backups is?

Hmmm. Not sure how more clear I can be. What I am NOT asking for is to backup anything on any VM. Just the stuff on the Cloudmin machine that is not in VMs, just like Virtualmin does on a Virtualmin machine. So, I want to backup the cloudmin machine, without the VMs contents. Not sure how that would not be clear?

So, the cloudmin machine itself might be running MySQL (outside of the VMs). As an example, or email, or...

I see what you mean - however, this isn't a feature of Cloudmin currently.

Even Virtualmin backups don't include files or databases that are not associated with any domain.

The only feature we offer currently for this kind of backup is at the Webmin level. You can go to System -> Filesystem Backup to schedule backups of arbitrary directories, and Servers -> MySQL Database to schedule backups of DBs.

Yes, true about MySQL, not true about being able to add directories, being able to restore the cloudmin master with ALL settings without having to figure out where each of them are, all of the virtual machine definitions and settings (but not the virtual drives), etc. I am not asking for an exact duplicate of Virtualmin backup, I am asking for a similar feature that takes into account the differences between Virtualmin and Cloudmin. i.e., same CONCEPT as Virtualmin, but of course not the same. Uploads to other machines, incremental, retentions, script to run after, etc.

This is a feature request, I realize it isn't a feature of Cloudmin currently.

And a restore to go with it, so, I can restore the Cloudmin machine without lots and lots of hassle.

Do you really thing Webmin backup would restore the Cloudmin master and ALL settings for the vms, /kvm, whatever? I have no idea where everything is. If so, then, perhaps that would work.

I guess then I'd have to read up on what Webmin backup really does, never used it. For example, what does MySQL Database Server actually back up? Just an example, I presume the other modules work similarly.

So, if I did a Webmin backup, formatted the machine, and webmin restore, I would have everything I had before except the virtual machine disk files (unless I have backed those up of course). If I restored those, then, machine would be up and running with the VMs. You are telling me that all would just work? If not, that's what I am asking for in this request, it may not be done any time soon, but, that's what I'd love to see in Cloudmin.

If I backup Postfix via webmin backup, it would backup all postfix mail directories, etc.?

We will look into this and see how the current Cloudmin backup feature can be improved. I'm interested to know what situation you would use this backup in? I assume the total loss of the Cloudmin master system with all VMs on it.

However, if you want to backup VMs (and all their state), Cloudmin can already do this. These backups are very similar in concept to Virtualmin domain backups, in that they do not include files unrelated to the VMs being backed up.

Yes, the use case is more for restoring a couldmin master machine that died, so, we can recreate it along with all software running on it, etc. Yes, machine configs, etc.

As far as your comment "Cloudmin can already do this". The cloudmin backup feature backs up the VM LVM drive. This is way too big, we can't back it up in this manner (one of them is 1TB in size). So, we want the configs, etc., but, not the virtual drives, we back that up in another manner. The Cloudmin backup does not appear to do this near as I can tell. So, what backup are you speaking of exactly?

Ideal world - there is a cloudmin system backup so it can be restored fairly easily.

So, since this does not exist near as I can tell, which backup can we get the most out of, and, what options? Hopefully, you can then improve in the future.

One question - if the backup doesn't include VM drives, how can you restore your VMs if the master system dies? Or are all the VMs on a separate host system?

In this case, since it's actually impossible to back them up using the Cloudmin virtual drive backup, I would simply restore as I would any other machine we have, using VIrtualmin (within the VM). Yes, its not the whole machine, but, wouldn't be any different than recovering a Virtualmin machine. As long as all the settings are maintained from some sort of Cloudmin backup.

We need a daily backup. A Cloudmin backup takes > 24 hours, so, can't possibly use it obviously. Interestingly, a Virtualmin backup takes 3 hours, and, the 1TB drive, most of which is MySQL data, compresses quite well when a traditional MySQL backup is taken, to almost nothing comparatively.

There is no Cloudmin solution for these big VMs near as I can tell.

Surprising that a full Cloudmin disk backup takes that long - can you tell if the host system is IO or CPU bound? I can imagine that if you have a VM with a large disk that is mostly empty that a Virtualmin-level backup would be faster, as the number of blocks of disk that have to be backed up is much smaller.

901G out of 1.5T is currently used, though, in some processes, other parts are used during nightly test runs. So, it's far from mostly empty.

The host system is idle, except for the backup. It's a set of test systems, based on production, but only used for test environment, which is maybe one user a day and a bunch of nightly runs.

The backup that comes out from Cloudmin is huge, and, you have to have space for it as I recall before it uploads to the machine we store backups on, which I do not have, but, it's based on memory, I cannot repeat the mistake of running it again. It killed us. Even if I had the massive backup space on the cloudmin master or VM (which would be a huge waste), then it has to transfer to the backup storing machine, which would also be an issue.

You know that a mysql backup (as output from Virtualmin, which is text based sql statements), compressed, is extremely small relative to the size of the databases, so, this is perfectly normal. It's simply much more efficient. 99% of the disc space is mysql databases.

In the latest Cloudmin release, the backup should be compressed on the host system before being transferred to the destination. Assuming the transfer is done via SSH, the compression will use streaming gzip, so there's no need for any temporary space on the host at all.

That may be true, but, to scp such a huge file simply isn't practical. Takes too long and causes network issues. Cloudmin currently has no way to handle such large VMs. Perhaps that is the real issue.

The scp should only happen after compression though - and for a VM with a mostly empty filesystem, the compressed size will be much smaller.

What exact option do you have selected for your backup destination?

For the two smaller VMs I can backup, they are FTP to a backup server, local. Those 2 come out at 11GB each. The larger VMS were many many hundreds of GB (backup size, don't have exact number, probably at least 500GB). Vs, the tiny tiny virtualmin backup of the mysql databases and config.

Ok, I didn't realize you were using FTP - for that, a local compressed copy of the disk has to be made first before uploading it. Is there any reason the backup can't be done via SSH/SCP instead?

It could, but, it's WAY too big. I keep 7 copies of the Virtualmin backup, which amounts to < 100GB total! It would be many many TB for Cloudmin, and, the transfer simply takes many many hours even if it could be done. More hours than we have. The virtualmin backup which includes all the MySQL databases is done and transferred in 1 hour.

The issue there is Cloumdin backups are dozens of times larger. And thus take not only more disk space (massively more), but, the transfer time.

Ok, most likely the difference is that the Cloudmin backup includes the full OS, whereas the Virtualmin backup is just the domain files and databases.

Anyway, I can see now why your request makes sense - I will look into implementing this kind of backup.

That is not the only difference. I would wager the lvm virtual drive compresses far worse than text mysql backup. The OS is only 10GB or so. So, 10% of the VM size.

Thanks for understanding.

I'd expect the compressed size to be about the same either way for MySQL, as a text-format SQL dump is larger than the underlying InnoDB data files.

One more question - how full is the disk on the VM you are trying to backup?

Well, you might expect that, but....

On one machine, databases are 237GB. The mysqldump, compressed, comes out to 12GB. So, that expectation would not match what I see on all our machines. By far compressed mysqldump takes less space that the raw mysql files and this is why your compressed lvm drive is so huge in comparison.

There are a number of large vm machines, so, depends which one you are speaking of. I guess I would wonder why you are asking, what relevance does it have? So, I'll use the same machine I quoted in previous communication. That machine has 42% free space. However, during the night, it has massive processes it runs, and, during that time, can easily use up another 100GB of work space.