From the project
New Hub feature: Auto-Restore TKLBAM backup to a new cloud server
Since we announced the release of TurnKey Hub v1.0 two weeks ago, we followed up with the two top issues users reported, and continued to receive awesome feedback - you guys rock, keep it coming!
A common question we received was related to restoring a backup to a new server. This wasn't a new question either, last year Phil Bower said: "I only want to run my instances while I'm using them so I'm interested in figuring out the fastest way to create new instances and restore backups to them."
In light of this, we just released a new Hub feature that streamlines the restore process depending on your use case. It also makes testing your backups even easier!
Restore this backup to a new cloud server
Alice is a consultant developing a new site for her client on Turnkey Wordpress in a local virtual machine. She is regularly backing up her work with TKLBAM and has reached version 1.0 status - time for production.
Alice logs into her Hub account, goes to the backup dashboard and clicks "Restore this backup to a new cloud server". The Hub knows which appliance is related to her backup and launches a Wordpress instance. TKLBAM is automatically initialized and her backup is restored, essentially migrating her local VM to the cloud.
Alice jumps up and down with excitement. She immediately calls up her client to give them the great news. Development to production in 3 minutes flat!
Launch a new server like this one
Bob (aka Evil Bob) has a highly customized TurnKey LAMP instance running in the cloud. He has added user accounts, installed packages, saved data on the filesystem as well as MySQL. Additionally, he configured an EBS volume and Elastic IP when he launched the instance. He even customized the firewall rules.
Bob only needs the instance to be up about for a few days every week while crunching data for his evil plan, but launching a new instance, attaching the EBS, associating the EIP, tweaking the firewall rules and manually restoring his TKLBAM backup is a little tedious.
Tedious? Not any more! Once a week Bob logs into his Hub account, goes to the server dashboard and clicks "Launch a new server like this one". He clicks the checkbox to automatically restore his backup, and he's off! The Hub launches a new server, automatically attaches his EBS volume (EBSMount mounts it), associates his Elastic IP, configures his custom firewall rules and restores his backup.
The lights dimm, Evil Bob's face lights up, raises his chin and lets out an evil laugh - MUHAHA!!
Note: The new restore features are not available for passphrase protected backups or legacy builds.
Comments (12)
Removing small inefficiences
Reply 1Innovative Solution and an immediate boon
Reply 2This feature is of immediate use to my organization and to my daily practice.
Security being what it is, StatusNet, IEP-IPP, our Joomla playground, for example, are not available off campus. With this feature, I simply leave for home on a weekend feeling secure that I'll be able to carry on my work: grading, IEP reporting, etc. Our IEP coordinator can now take care of business from home, with a little help from a friend.
Another fantastic solution affecting daily practice.
Very Exciting
Reply 3Sounds great for setting up development and staging environments
This is a great feature
Reply 4I can imagine this would be very handy. I will play a bit and check it out.
Sorry my bad...
Reply 5The folder location is /usr/lib/inithooks/bin/
And I'm not 100% it's called mysql.py (but i thnk it is)
Run
ls /usr/lib/inithooks/bin/
to see all the scripts then assuming it is mysql.py
/usr/lib/inithooks/bin/mysql.py
Either from SSH or Webshell (I generally prefer SSH but Webshell should work too I would think).
Also to rerun all firstboot scripts:
turnkey-init
should do the trick
Call from SSH or Web?
Reply 6To instigate the script I assume one should be in SSH or Webshell?
Thank you for your note.
Looking for the files. I don't have an inithooks folder at first exploration...
/usr/lib/tklbam/mysql.py
I will look at the original also. Perhaps there is some remapping.
Thank you for your note.
------------
How to run the script? In Command Shell (under Webmin) I don't have permission to run it. In Webshell I don't know how to run the command. Bash did not work.
Plugging away.
thank you,
You can rerun firstboot scripts to reset passwords
Reply 7To do them all you could try turnkey-init but I'm not sure how that'd go on an AWS instance...? Otherwise IIRC firstboot scripts are in /var/lib/inithooks/bin/ /usr/lib/inithooks/bin/ [edit - confirmed]
The one to reset MySQL password is simply called mysql.py [I think...]
Sorry for the late reply
Reply 8I know Liraz will be doing some maintenance and enhancements on TKLBAM quite soon, and will probably contact you if he can't reproduce the issues you mentioned.
As a side note, I just announced TurnKey Hub Server Snapshots, which might come useful until we've got all those TKLBAM issues sorted.
Problems with Magento and Joomla -- MySQL broken with Restore
Reply 9I have had trouble with both Magento and Joomla trying to Restore to a New Cloud Server.
In Magento I simply could not get into MySQL. I suspect the Restore had invisible problems.
Perhaps the same with Joomla, but beyond that MySQL is not running and it won't take my password to see into it.
Are there any reset scripts that I could watch.
In Magento I have not been able to restore to a Preset New Server either. I have not yet tried this in Joomla though I expect I will in the next few hours.
Awesome potential with this but the TKLBAM-Restore process has given repeated troubles, doing this or to simple new Machine Builds in Esxi. Often increasing max_allowed_packet will help but this week that did not suffice.
Nice... lets see where that takes us
Reply 10Definitely need to run the commands from something like what I call / "root"..
cd /
then the file is
/usr/lib/inithooks/bin/mysqlconf.py
then simply
turnkey-init..
though I did not enter the Hub Key. that may have been a mistake. Seems to think it still has it when I look at the TKLBAM panel.
This did get MySQL running. I am not yet clear whether Joomla will have access but we will see what happens with a Reboot. I'll bet that search engines read "strikethrough" as it has not been striken.
Joomla though is not starting up.. Maybe something in the startup file to tweak.
Database Error: Unable to connect to the Database: Could not connect to MySQL.
I did get into PHPMYADMIN
I expect that we "rehashed" something so that the encrypted password in /var/www/joomla/configuration.php does not jive anymore. Second subject is that all the USERs in the MYSQL database are also hashed so you can't even look at the names. Likely something on the Amazon side.
It would be worth documenting this in the forums... I will see if I can add some of this to some recent related post.
Will give it another spin.
thank you!
No need to cd to root
Reply 11As long as you are running as the root user all of the commands I use above should work from any directory. Here's why:
turkey-init
is a command that should run from anywhere as it is located in a folder which is defined in the system path variable (just like in Windows, C:\WINDOWS\system32\ is included in the system path so you don't need to cd to C:\WINDOWS\system32\ everytime you want to run commands like ping or ipconfig).
/usr/lib/inithooks/bin/mysql.py
uses an absolute path so it can be executed from anywhere. Note the leading '/' which denotes that the path starts from root (to compare again to Win: it's like saying C:\some-folder\custom-script.cmd). Relative paths start without the leading slash (and thus indicate that the path starts from the current working directory).
ls /usr/lib/inithooks/bin/
Is a combination of the above 2 examples, the 'ls' command is in the system path so will run from anywhere and the directory to list is defined by an absolute path (again note the leading slash).
As for your Joomla DB connection, if you run the 'turnkey-init' script, it should regenerate the random secret MySQL password string for Joomla, but should also include this new password string in the Joomla config file so it should connect without needing modification.
AFAIK if you don't want to run 'turnkey-init' then you can manually reset the Joomla MySQL user password (from phpMyAdmin is probably easiest) and edit the Joomla config file to include this same password. I've never done this with Joomla but i have done similar things with other webapps and the theory should be the same.
Joomla Running now.. in a few steps
Reply 12I needed to run :
mysqlconf.py
joomla.py
Which got the site showing up.. I couldn't get into the backend, so I went in via PHPMYADMIN and reset the Joomla SuperUser Password... Once done, I got in and could see that I basically had a empty, though built website... No changes would stick etc.
At this point I got both the ESXI Site and the Cloud Site open in Navicat and I transfered the Data in the Joomla Database to the Cloud site.
Everything is working now. I could see that the "rokuserstats" datafiles are huge so I need to clean those out.
Will test some and see if I can get Magento Transfered over. Likely the Joomla won't run well as a Micro Instance, but I am not sure. I am sure I need a small instance for Magento.
PS: sorry for the late response. It's been holiday season over here.