Restore All Virtual Servers with One Command?

19 posts / 0 new
Last post
#1 Wed, 09/02/2009 - 09:34

Restore All Virtual Servers with One Command?

I'm moving to a new DC and need to restore all virtual servers. I have the backups copied over, but don't see a way to restore all at once from the control panel. I assume this can be done then by the command line. What would that command be?


Wed, 09/02/2009 - 09:37


You can restore them all at once by pointing Virtualmin to the directory your backups are in, rather than specifying a particular filename.


Wed, 09/02/2009 - 10:21 (Reply to #2)

Perfect! Thanks

Wed, 09/02/2009 - 12:57

Took a little less than 2 hours to restore 198 domains, not bad. Two problems I can see so far.

1) The drop down arrow that allows the selection of virtual servers disappeared

2) I had to disable Virtualmin Analytics on the only two accounts using it, otherwise Apache wouldn't start and gave this error:

[error] Can't locate /etc/webmin/virtualmin-google-analytics/ in @INC (@INC contains: /usr/lib64/perl5/site_perl/5.8.8/x86_64-linux-thread-multi /usr/lib64/perl5/site_perl/5.8.7/x86_64-linux-thread-multi /usr/lib64/perl5/site_perl/5.8.6/x86_64-linux-thread-multi /usr/lib64/perl5/site_perl/5.8.5/x86_64-linux-thread-multi /usr/lib/perl5/site_perl/5.8.8 /usr/lib/perl5/site_perl/5.8.7 /usr/lib/perl5/site_perl/5.8.6 /usr/lib/perl5/site_perl/5.8.5 /usr/lib/perl5/site_perl /usr/lib64/perl5/vendor_perl/5.8.8/x86_64-linux-thread-multi /usr/lib64/perl5/vendor_perl/5.8.7/x86_64-linux-thread-multi /usr/lib64/perl5/vendor_perl/5.8.6/x86_64-linux-thread-multi /usr/lib64/perl5/vendor_perl/5.8.5/x86_64-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.8 /usr/lib/perl5/vendor_perl/5.8.7 /usr/lib/perl5/vendor_perl/5.8.6 /usr/lib/perl5/vendor_perl/5.8.5 /usr/lib/perl5/vendor_perl /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi /usr/lib/perl5/5.8.8 . /etc/httpd) at (eval 2) line 1.\n

Any ideas?.

Wed, 09/02/2009 - 13:01 (Reply to #4)

Well, if you're restoring that onto a new server, you'll need to make sure the Virtualmin Google Analytics package is installed.

I also believe that said package requires mod_perl.

As far as the drop-down arrow goes, look in System Settings -> Module Config -> User Interface Settings, you'll see an option to enable it when you have more than 100 domains. By default, after 100 domains, it requires you to do a search for the domain in question.


Wed, 09/02/2009 - 13:28 (Reply to #5)


Thanks for the quick fix for the User Interface Setting. I'll look into the Analytics later, since it's not a very pressing issue at the moment.

By the way, moving to a new server couldn't have been easier!!!

Wed, 09/02/2009 - 14:09

Another issue, mySQL sites are showing this error when you browse to them:

Database Error: Unable to connect to the database:The MySQL adapter "mysql" is not available.


Wed, 09/02/2009 - 14:14

Is the php-mysql (or perhaps php5-mysql) package installed?


Wed, 09/02/2009 - 14:22 (Reply to #8)

I guess I assumed all would be installed through Do I need to yum it?

Wed, 09/02/2009 - 14:30 (Reply to #9)

I don't know what distro you're using, but whatever the package command is, you just need to make sure you have the PHP MySQL package installed -- which is typicalled called php-mysql or php5-mysql.

It would typically be installed with yum or apt-get.


Wed, 09/02/2009 - 14:50 (Reply to #10)

CentOS 5.3

Package php-mysql-5.1.6-23.2.el5_3.x86_64 already installed and latest version Nothing to do

Perhaps this has to do with setting the root password for mySQL?

Wed, 09/02/2009 - 15:57 (Reply to #11)

I've discovered databases can be connected to if using Apache mod_php instead of FCGId. Is there some place else that I need to enable FCGId?

Thu, 09/03/2009 - 08:34

I found this post:

There it is mentioned solving the "Database Error: Unable to connect to the database:The MySQL adapter "mysql" is not available." was done by commenting out the "extension_dir = "/usr/lib/php/modules"" in php.ini.

IT WORKED - so now my question is this the best way to fix this? If so, I need to fix 100 or so accounts, can I just globally replace all php.ini files with an edited one or is there a better way?

This is the only thing preventing me from putting the server in production and seems a bit like a restore bug.

EDIT: Doesn't look like I should do a global replace, because there are a couple custom lines in the php.ini file. I need a fast way to get this done.

Thu, 09/03/2009 - 09:50 (Reply to #13)

It sounds like the dir PHP stores extensions in may have been different between your last server and this one.

The explicit setting for extension_dir in the php.ini files that were restored may be pointing to a location that's not valid on your current server -- but by commenting it out, the default setting within PHP probably has it pointing to the correct place.

So your question is, how do you disable that globally?

There's no "one click button" to do that at the moment.

The best I can offer is that you can string some commands together to do a global find and replace -- you just have to be really really careful in doing this, as it has the opportunity to break lots of things if it finds and/or replaces the wrong things :-)

I have not tested this below (ie, please test it before running it on your live server) --

But if your goal is to comment out the string "extension_dir = "/usr/lib/php/modules" in the php.ini file, something like this Perl code should do that:

perl -pi.bak -e 's!extension_dir = "/usr/lib/php/modules"!;extension_dir = "/usr/lib/php/modules"!;' php.ini

This will work on a single php.ini file.

Before you go any further, I'd run the above against one php.ini file to make sure it does what you need, and that your Virtual Server works as expected after the fact.

If it does, the following command would run that same code against all the php.ini files found in the /home hierarchy (but again, it'd be great if you had a way to test this first :-)

find /home -type f -name php.ini | xargs perl -pi.bak -e 's!extension_dir = "/usr/lib/php/modules"!;extension_dir = "/usr/lib/php/modules"!;'

Thu, 09/03/2009 - 10:16 (Reply to #14)

I'm losing confidence that commenting out that line is the solution. After I did that and the Joomla website was working, I installed Joomla in another directory for that site, it worked too. However when I went back to inspect the php.ini file, the "/usr/lib/php/modules" line was uncommented now.

Same OS and version. I have submitted a ticket on this issue.

EDIT: I don't know what the heck I was looking at. The line is still commented out. If the modules are in a different directory than /usr/lib/php/modules, could I make a sym link to the correct location?

Perhaps now that I have a support ticket, I should be continuing this on that thread.


Thu, 09/03/2009 - 10:20 (Reply to #15)

Sure, you could make a symlink from the old module location to the new one.

That'd be a pretty straight forward way to resolve this, just don't forget to make that symlink again if you change servers in the future :-)


Thu, 09/03/2009 - 10:24 (Reply to #16)

I see the issue, the new server is a x86_64, the old is i686. Therefore extension_dir = "/usr/lib64/php/modules" is now the correct location.

Thu, 09/03/2009 - 10:50 (Reply to #17)

Sym link seems to be working!

Thu, 09/03/2009 - 10:57 (Reply to #18)

That's great news! Thanks for the update,


Topic locked