Confusion over how Account Plans and Server Templates are handled during a migration

I set up a new Pro server with new Account Plans and Server Templates, named "Basic Web" in both cases. I then set up four virtual servers using these plans/templates.

I then imported about a dozen domains from an older (but updated and current) Pro server. Some of the domains were set up quite some time ago (before I had really got a decent grip on managing Virtualmin), and had some features (e.g., BIND) that I had since disabled on the old server and were never enabled on the new server. After the import it seems that my "Basic Web" plans and templates were renamed "Default Web" and the existing "Basic Web" plans/templates were overwritten by their counterparts on the old server.

I'm very confused by this, as nowhere in the documentation did I read that this would happen! Now my new server is a dog's breakfast of "wrong" (for want of a better word) Account Plans and Server Templates I DO NOT WANT.

What the heck happened here? I've halted all of my migrations until I can figure out how to prevent this from continuing to happen as I migrate more domains, and how I can somehow (if possible) have migrated domains conform to the Account Plans and Server Templates that I want prevailing on the new server.

Thanks in advance.

Craig

Status: 
Active

Comments

Maybe this was my own fault? I used these commands to back up and restore these domains -- i.e., migrate them:

virtualmin backup-domain --dest DESTINATION --domain DOMAIN.COM --all-features --newformat
virtualmin restore-domain --source SOURCE --domain DOMAIN.COM --all-features

Was it my use of "--all-features" that caused this? What would have happened if I omitted that flag?

No, that's not the answer, because running the back-up command without "--all-features" causes a "No features specified" error.

I suppose what I expected was for Virtualmin on the new server to create the imported domain without an Account Plan, or handle it in some intelligent way other than messing around with the Account Plans and Server Templates that I had spent so much time carefully crafting.

Standing by.

Howdy -- thanks for contacting us!

I believe what's happening there is that the backup process is creating a virtualmin.tar.gz file, which is where the various Virtualmin settings are stored.

If you don't wish to migrate all the Account Plans and Server Templates, my suggestion would be to ensure that the virtualmin.tar.gz file isn't being restored onto the new server there.

My recommendation would be to bring across (using a virtualmin.tgz file) all the templates and plans from the old server, then delete the plans you don't need on the new server.

Hmm, in an earlier experiment I created the virtualmin.tgz file and examined it. I didn't like the idea of using it, because it contained very little information I couldn't set up in a few minutes manually, and I wanted to set up new plans and templates from scratch anyway. However, it seems the migration process overruled my wishes regardless, leaving me with this (as I described it) "dog's breakfast".

Not happy with that and the lack of some kind of a warning, even after the fact, but I'll work around it and get everything back in order manually after I finish the migration.

There is a hidden "feature" that causes any plans missing on the destination system to be automatically re-created on restore, even if you don't bring them across explicitly. This is to prevent a situation where a restored domain is on a plan that no longer exists.

OK, well that jibes with what I concluded in my last message, and doesn't change my negative conclusion about this hidden feature. I suppose I can see the logic in not wanting a domain that is somehow orphaned with no governing plan. I see that there appears to be an option on the List Virtual Servers screen to make mass changes, including to the assigned plans, so thankfully I'll be able to do that later.

Yeah, due to the way plans are linked to domains, we have to ensure that the plan always exists when restoring. The alternative would be to fail the restore until the plan is migrated separately.