Another VMN to VMN backup and restore question

I’ve been browsing the forums for info on this, pretty straight forward for moving a virtual server from one VMN install to another. Backup virtual server on VMN1, restore virtual server on VMN2, profit. :yum:

However, the virtual server on VMN1 is using NGINX and VMN2 is using Apache, so I’m wondering if there will be any issues due to the web servers being different?

Haven’t tired it quite yet, but would like to know if there’s any issues I may potentially run in to due to the different web servers?

If I get the backup and restore scripts correctly, they replace the existing files and configurations with the ones from the backup. So I highly guess it might get into a problem. Meaning it will restore apache2 on your VMN2. Its possible that it will let be nginx enabled and get apache2 additonally to it.
A manual change to fully go with nginx on that system should be doable afterwards.

That’s my worry, here since the web servers are different. I see there’s any option to NOT backup the NGINX config, which I presume I’ll need to use.

Curious to know if anyone else has run in to this before and how they did it? Perhaps the powers that be can give me some input?

Tried it without bringing in the NGINX settings from the VMN1 (origination server) and getting an Internal 500 error when I try to preview the web site… No luck thus far.

Edit, doesn’t matter what is checked, same results each time. Internal 500 error after restoring the virtual server from the back up. Time to do some more research here…

Which 500 error do you get? Directly 500? If yes, then it might be easier then expected because 500’er errors are typically 5 things (not always but in over 95% in the cases).
Did you restore the backup and tried to access a domain other than the webpanel itself and got the error there? Or directly at the webpanel?

I used the “Preview Website” under the Services option within the VMN panel, haven’t made any DNS changes and won’t until this is successful.

Edit: It’s an apache2 issue, tracking that down right now. Wish me luck!

Edit2: “/public_html/.htaccess: Option FollowSymLinks not allowed here” is in the apache2 error log.

If you use a .htaccess file, then try to remove it.

Try removing Options +FollowSymLinks from the APP’s .htaccess file and try again.

The above is from the documentation for the APP that’s used on this virtual server that I migrated. I remarked out the line with the above statement and it appears to have worked, as when I now “Preview Website” it resolves to the actual install on VMN1. DNS entry has been changed and once it propagates, I’ll know for sure.

Still have fingers crossed right now. :wink:

If you want to use mod_rewrite as an example, then you should check why its throws that error.
In any case, you should check it.^^

I don’t think I’m out of the woods quite yet on this and yes, mod_rewrite is typically needed for this app.

I’ve made the migration and got it working… for the most part. The above mentioned Internal 500 error, due to the +FollowSymlinks being present in the .htaccess needs to be figured out.

Also, once the DNS propagated, I’d get to the log in screen, just like always which was nice. However, logging in would take to me AWSTATs page… I did laugh and giggle a bit at that one. I checked and sure enough there’s an index.html in the ./public_html folder (this APP uses index.php). I renamed it to index.old and I was able to get in to the app correctly. I reverse the file back (back to index.html) and the same thing happened, AWSTATs…

As an experiment, I typed in a URL that’s within the APP (after logging in with the INDEX.HTML still present and at the AWSTATS page) and it worked, so for some reason after logging in to the app on the VMN2 (new host) for the migrated virtual server, something has changed (apache2 again??) and it may have to do with the NGINX > APACHE2 change, not sure yet.

Once again renamed the index.html to index.old and all is well and as it should be. I hope that’s not to confusing?

I clearly have a work around, but I like things to function 100% as they should, as rigging things typically means I’ll have issues later.

Success is NOT 100% quite yet, still working through some of the smaller things here. Any input would be much appreciated.


I see looking at the apache2.conf that the FollowSymlinks direction is already in this file:

Options FollowSymLinks AllowOverride None Require all denied

Perhaps apache2 didn’t like it twice? Dunno here, just seeing what I’ve found thus far and knowing it was an issue with the .htaccess that was easily solved. (Thinking out loud here…!) More researched needed on this one.

Also, I’ve changed the DirectoryIndex for this specific virtual server to list index.php first, but that doesn’t seem to matter… Will chase this one down as well.

Did you enable the mod_rewrite itself? If not, run:

a2enmod rewrite

and after that make sure to reload/restart apache2.

Btw, if you use your own index file, then there is no need for the “default” index.html and it can be removed.
I am a bit surprised to see that there is one file, because I never got an index.html file inside the public_html file after creating a domain.

It appears the index.html is a leftover file from when the APP was created or the directory first created, as the file date for index.html is the same on both VMN1 and VMN2. Renaming index.html to index.old works just fine as the APP uses index.php

Also, I’ve changed the DirectoryIndex for this specific virtual server to list index.php first, but that doesn’t seem to matter… Will chase this one down as well.

Still haven’t tracked down the above, and not sure why it won’t load the index.php first… [Scratches head]

I’ll check to see if the mod_rewrite is enabled or not, I was able to do a decent size import in to the DB for the APP last night and it worked as it should.

Thank you very much for posting your ideas and assistance!

@GPZs well… apache and nginx are two different things - like potato and onion… if you make backup on nginx then restore in nginx server and it would work… same for apache, otherwise give yourself an favour and do your self research how to convert configurations from one to another… this is not really an issue within virtualmin. Yes the issue you would have is apache is not nginx and other way around. Anyway you can request this future from virtualmin folks on pro support / issue / ticket tracker and see it from there.

edit: backup would work as desired when you do backup from apache to restore to apache and same for nginx…


I’m guessing here you didn’t bother to read any of my posts?? Where did I state it was a VMN issue at all? I didn’t, I was merely being preemptive on doing due diligence to see if I could find any info on this type of migration.

@GPZs no you did not stated its virtualmin issue directly, however you open forum post asking to help you solve this here, where I said, its not an virtualmin issue - or perhaps I should already ask where virtualmin fails in this… my bad… anyhow, have good day.

There is and was no VMN failure at all, if you read my post you’ll see I was asking for anyone with experience to give their input on this type of migration. I’m probably not the 1st person in the history of WMN / VMN to do this type of migration.

You waltz in and start giving advice on something that’s already been completed and start stating the obvious (as if I didn’t know NGINX and Apache are two different web servers… For real??) and telling me to " give yourself an favour and do your self research how to convert configurations from one to another… " What exactly do you think I am (or was) doing by posting this? Research, my friend!

While I do appreciate your input, it’s really ex-postfacto and not any help.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.