I'm working on a Wordpress site and accidentally ended up modifying the Database via PHPMyAdmin in a way that affected all the posts on the website negatively. I regret the fact that I should have manually made a DB backup before working on it. After having tried to resolve it by importing the original data I had at first, I seem to have lost more data than I anticipated. Is it possible to restore the Cloud9 MySQL Database to a specific data and time in the past?
Related
I have an error with Xampp where it will not connect to my database. I have had this error several times in the past and no solutions have helped. I find that uninstalling and reinstalling ends up being the fastest method, however, by doing so I lose my database tables. As I have no access to the default export and import functions, I was wondering how I transfer the tables across.
Last time, I copied and pasted these files into the same directory when I reinstalled Xampp and the tables transferred but the data within did not. The tables had also lost some functionality as well.
If anyone has any methods to do this I will greatly appreciate it.
The best way to backup and restore your data is to dump the database to an SQL file. You can use the provided mysqldump tool for that, which is the best tool for the job.
Copying the entire MySQL "datadir" (which is probably one level up from the screenshot you've posted) and completely replacing one of your new stopped MySQL instance will probably work, but is not reliable and is not supported. Since there are other files (such as ibdata1) that handle the overall health and functioning of the entire MySQL instance, you can't only copy over individual database directories. Furthermore, you should only do this when the original and replacement MySQL servers/daemons/services are completely stopped because otherwise there are file corruption or concurrency issues.
Since you're running the server on your own computer, you should grant yourself sufficient access to be able to use mysqldump and use that regularly as a backup, since file-level backups of the data directory are not reliable.
Prior to the formatting of my PC, i backed up the entire database set through phpmyadmin.
Now when i am restoring my exported sql file, its showing me an error "#1046 No Database selected".
Going through many question answers, i got to know that i should have exported the databases one by one. But now the mistake has already happened, and i have no other alternative to backup the database again, i am left with the already backed up file of "Entire Databases of server".
How to recover them now?
I have been working on a web application using ExtJS with a SQL Database hosted on phpMyAdmin using MAMP. About 2 weeks ago, I had to dump my old HD because of bad sectors and I got an SSD as a replacement. After installing my applications again (IDE's, Document Editing Softwares, MAMP, etc), I had to reinitialize my databases in phpMyAdmin.
Luckily, I had one of them online in production so I just exported the SQL from the server and I had a local copy again. However, there's this one other website that I do not have a backup to the SQL file of -- and I need to get that SQL file because I can't create it from memory (I think it had 30+ tables already).
I know I can plug in my old hard drive, boot from there, open MAMP, open phpMyAdmin, then export my database. However, that's too much work and I am not sure if that's a good idea.
Is there a way to extract the SQL file of a phpMyAdmin table by using the file directory/structure alone? I think MAMP is supposed to store the data somewhere so that phpMyAdmin knows where to get its SQL tables.
Update
I found my "database" under /Applications/MAMP/db/mysql/ProjectName/ but they're .frm and I'm clueless on how to open this.
Take a look at this answer: Restore the mysql database from .frm files
You'll need a couple more files other than the .frm, but you can solve it with the files alone, no need to plug in your old drive again.
I am having a problem backing up a database. I’m moving between vps providers and usually would use the WHM transfer tool. I did it this time also but got database error messages after the transfer and when I compared the 2 databases I noticed that the newer one was 200Mb smaller than the old one n the old server so I have been trying to take a manual backup but I’m having the same problem..
The original database is 1.1Gb. I’ve tried dumping it via command line, exporting from phpmyadmin, cpanel backups etc but each time I`m left with a smaller database.
I have checked both old and new databases, all the tables are backing up fine but its the contents of them which are not fully backing up. which makes me think it may be a timeout issue, .. But I am not 100% sure. I have tried changing settings in php.ini and my.cnf but I am not totally sure what is causing the prob.
Any advice would be greatly appreciated
I've just installed MySql Workbench 6.0.09 on recommendation. The main reason was to copy my Wordpress database which is stored in MySql.
I'm using the import/export function with a single file, however it doesn't seem to populate the new schema whether I create it before hand or let the process create it.
I've read somewhere that this cross schema copy doesn't work in older versions, but I'm unsure whether this is still the case, i'm doing something wrong, or there is a permissions issue. It seems unlikely that I'm doing something wrong as there is literally a few clicks to deal with.
Anyone advise?
From the discussion above I conclude this question is about creating a duplicate of an existing database using MySQL Workbench. There are several possible approaches for this scenario:
Createa a dump of your source server using the Data Export feature in MySQL Workbench:
. Then restore that dump on the target machine (via Data Import/Restore).
Do a quick an easy shot by using Schema Transfer Wizard. See menu -> Database -> Schema Transfer Wizard...
Start a normal MySQL to MySQL migration using the Migration Wizard under the same menu item. This would also allow to migrate to different MySQL versions.
I didn't find an answer to this however, I did work out a solution.
1) I took a backup of the existing database.
2) I edited the script produced by the backup. I edited the database name on 2 lines at the top of the script then ran it.