TKLBAM Restore problem

Jan Joost de Vries's picture


I have a development system (TKL drupal6 appliance) running on my macbook in VMware fusion. I tried to sync it with a EC2 instance (I started one for test purposes) . So I backuped my development machine en resored the backup on the Amazon ec2 instance. The results were not what I expected.

The restore seems to have restored the drupal mysql stuff fine. But it didn't restore the custome theme I was working on local dev machine. So I tried to use the filesystem overides to explicitely backup the drupl themes aswell. After a subsequent restore only empty (custom) theme folders were restored.

I am wondering what went wrong / what am I doing wrong?

Jan Joost de Vries's picture

I have noticed that the backup was made from a ubuntu 9.x based machine and the restore is on a tkl 11.1 machine.. perhaps that explains this behavior.

Regards Joost de Vries

Jeremy Davis's picture

You say that you are using TKL Drupal6 appliance as a dev environment, but in your second post you say that it's "Ubuntu 9.x"!? If it's an Ubuntu setup (rather than TKL) then I'm surprised that TKLBAM works at all.

If you mean that its a v2009.x TKL appliance (Ubuntu 8.04 based) and you are restoring to v11.x (default with EC2) then there are a couple of options. You could try migrating to TKL v11.x completely using TKLBAM - adjusting any inconsistencies prior to a second full backup. Or you could try restoring to a 'legacy' (ie v2009.x) EC2 instance.

Either way it's good practice to a avoid putting themes etc in 'naughty places' rather than adding overides (although short term it shouldn't really matter).

Jan Joost de Vries's picture

You are right, I have been using a v2009.x TKL appliance to develop a drupal based website / theme. At first I tried to restore for the legacy vmware image to the TKL v11.x EC2 instance. I didn't know much about Debian and "the Debian way of doing things" and 'naughty places'. But I do now (I think) . So I will try to ajust that.

At this moment I have succesfully restored a legacy backup in EC2 and manualy fixed the missing files located in the 'naughty places' (next thing on my list to fix) And got everything to work at first sight. But when I reboot the instance MYSQL fails to startup again and complains about a missing socket. Could this also be caused by something I am doing wrong here? I have checked /var/run/mysqld and after the reboot the mysqld.sock is gone?? 

Thanks for the help.

Jeremy Davis's picture

That'd be my guess anyway. Don't worry too much about the socket error at this point. AFAIK that is a symptom rather than the cause of the issue.

I'd run a diff between the default TKL my.cnf and your restored one. Prior to your restore (ie in a clean install of TKL Drupal6) backup the cnf file

cd /etc/mysql
cp mysql/mysql.cnf mysql.cnf.backup

Now run your restore/migration (or use your existing broken appliance, just upload mysql.cnf.backup to /etc/mysql). And run a diff on the 2 files:

cd /etc/mysql #if you're not already there
diff mysql.cnf mysql.cnf.backup

You can manually adjust the .cnf file with nano (commandline text editor).

nano /etc/mysql/mysql.cnf

Also, I found an 8mth old forum post referring to a issue with /etc/inti/mysql.conf after an upgrade from Ubuntu 8.04 -> 10.04 (what you're effectively doing, although in an arguably beter way - TKLBAM). Seeing as 8.04 is still supported I would think that this should be fixed by now but may be worth double checking.

Let us know how you go.

PS you don't have to reboot to test your changes. Just start/restart MySQL. Use one of these:

service mysql start
service mysql restart

Post new comment