MySQL recovery from another drive?
-
Hello -
I’ve had a FOG box running happily on an i7-920 w/ 8GB of ram here at the high school I support for almost a year now. It had a 250GB system drive and a 1TB storage drive that I moved my /images folder to, and everything was running fine. The whole thing was originally built (I think) on Ubuntu 10.04 x64 Desktop. At some point, i upgraded Ubuntu to 11.something and had no troubles.
Last week, I checked FOG for any Ubuntu updates, and saw I had the option to upgrade to 12.04. Having the 11.whatever upgrade go well, I (stupidly) thought “hey, why not” and committed to the upgrade… fast forward to next morning, nothing works on the FOG server - couldn’t even get the keyboard or mouse to respond.
Since I am a Linux newbie, I figured I was better off rebuilding the box then trying to hack my way through Linux and figure out what was wrong. I figured as long as I didn’t hose anything off the hard drives, all the data would be there to recover.
So I installed a new 80GB drive, and disconnected the old 250GB system and 1TB storage drives to be safe. I built Ubuntu 12.04 x64 Desktop on the new drive, and it worked fine. Next I installed FOG. It too works fine. I then powered down, connected the old drives, and booted. I successfully copied over my tftpboot, vat, and opt directories to the new system drive and rebooted. All looks good so far - my PXE menu and custom graphics were restored, my custom kernels came over and their options in the PXE menu, etc. I carefully remounted the storage drive and connected it to /images and can tell the new installation can see the drive, and even the FOG console is reporting the correct data consumption of my storage drive, but none of my images are showing up in FOG.
From what I’ve read, this is because I’m missing my old MySQL database - this makes sense, because all my options in FOG that I understand this controls were not there… I’m missing my inventory, customization in FOG options, etc. The old MySQL data should be untouched on the old system drive, which has not had anything releted / formatted / etc. However, everything I read that gives the option to dump and restore the MySQL database assumes you’re doing that with the instance you are trying to dump running. Since the instance I want to dump and restore is on another drive, and not the running MySQL instance for FOG, I don’t think I can do that…
[B]SO, my question is - given that I have not changed, deleted, or altered the contents of the old system drive with the old MySQL database I’d like to recover to the new MySQL installation on the new system drive, does someone know of a way to dump / backup / copy this old database, even though it is not “running”?[/B]
Visual reference:
sda - 80GB “new system drive” - current Ubuntu / FOG installed and running
sdb - 250GB “old system drive” - old Ubuntu (broken) /FOG install, with MySQL database I want to recover
sdc - 1TB “storage” drive - houses images from old FOG install, currently mounted to sda /images but not visable to FOGDisclaimer: I am again a linux newbie, and blithering idiot when it comes to MySQL, so I don’t really know how this works. Any help would be appreciated. [B][/B]
-
shut down mysql. backup data files, copy and overwrite with data files from old hd. start mysql. profit, hopefully.
-
-
Bingo.
Sorry for the long delay in my response - end of the school year and busy here. Just confirmed I was able to resurrect my FOG MySQL database and I’m finishing up my first test image now. Looks like (fingers crossed) no lost data.
The steps I followed were:
I stopped MySQL before copying anything over using:
[CODE]/etc/init.d/mysql stop[/CODE] From: [url]http://abbysays.wordpress.com/2008/05/20/how-to-startstop-mysql-server-on-ubuntu-804/[/url]
Then, I copied over my MySQL files, which are located in [B]/var/lib/mysql [/B]on the old drive to the new drive. Since I am lazy and prefered to do this the graphical way, I used “gksu” in terminal, then ran “nautilus” at the prompt to get a “root” window I could copy, drag and drop from / into.
Of course, that’s not the way Linux likes it, and it caused problems. I went to restart MySQL with:
[CODE]/etc/init.d/mysql start[/CODE]
but all i got was a “fail” with nothing else to go by. Several websites suggested i check [B]/var/log/mysql.err[/B] and [B]/var/log/mysql.log[/B], but these files were empty. I came across this post here: [url]http://serverfault.com/questions/142315/mysql-service-wont-start[/url] that suggested I might need to change the permissions on what I had copied. As suggested, i ran:
[CODE]chown -R mysql /var/lib/mysql/[/CODE]
And when I then attempted to start MySqul again with:
[CODE]/etc/init.d/mysql start[/CODE]
SUCCESS! After doing a few cartwheels, I logged into fog via another computer, and ran a simple wake up job on a lab of computers - and they all booted! A few more fistpumps and I thought I was all set. I figured I should run a test image, just to be safe. When I fired off the image, fog gave me an error I’d never seen:
“Unable to connect to TFTP Server!”
…oh crap. Fortunately Google saved the day: [url]http://www.fogproject.org/wiki/index.php?title=Unable_to_connect_to_TFTP[/url]
I needed to change my fog user password, and where this password appears a few times in the fog interface. So I ran:
[CODE]sudo passwd fog[/CODE]
on fog and followed the prompts (note: you might want to choose a throwaway password as this appears in plaintext in the fog interface). Then, in the fog web interface, I followed the instructions on the fogproject wiki:
[LIST]
[]In management front end, go to [B]Storage Management[/B] -> [B]All Storage Nodes[/B]
[]Click on [B]DefaultMember[/B]
[]Change the [B]Management Password[/B] to match the password you just changed.
[]Then go to [B]Other Information[/B] and change [B]FOG_TFTP_FTP_PASSWORD[/B] also.
[/LIST]
[FONT=sans-serif][COLOR=#000000]That did it for me! Thanks very much to [/COLOR][/FONT][URL=‘http://fogproject.org/forum/members/chad-bisd.18/’][B][U]chad-bisd[/U][/B][/URL] for getting me on the right track! -
This post is deleted!