The primary HDD drive of my computer died yesterday, I got a new one and restored it but when I went to restore my mysql databases I realize I had no done a proper backup in a while.
Nevertheless, I do have the original database files from my previous installation as the datafiles were in the second HDD.
My question is, can I restore/create a new DB in the new machine using only the files from the previous installation?
Thank,
Ignacio
Yes, you should be able to do this.
I'm a bit unclear: when you say, "I do have the original database files" do you mean as a database? If so, go to phpMySql for the surviving database and choose Export. Export the database as a text file. Open the file with your favorite text editor and change the name of the database to match the name you are importing into.
Create the empty database where you want the new one to be, if it doesn't already exist. Now go to phpMySql for that database and import your text file. This should recreate all the tables and their data in the new location.
If instead, you only have the files that were the source of the data, then you need to use whatever tool was used to create the database in the first place. For example, if the data is in the form on an Excel spreadsheet, you would use MySql for Excel.
Hope this helps!
(after your comment that you have file backups of WordPress site)
In that case, you may not be so lucky. If you used a tool to do your backup, it may have backed up the database, but in general, the database is stored separately from your file system. So if you just copied the files yourself, you won't have the database. But do look for any file with a suffix of .SQL, which would be a database backup.
Next, contact your Internet Service Provider and see if they do periodic database backups. If so, you can recover from them.
For the future, see if your ISP provides automated backups (including database). And read https://codex.wordpress.org/WordPress_Backups.
Related
I am trying to use mysqldump for backing up my database and restoring the same in remote a machine for disaster recovery purposes. As I havent used it before, I am having a basic question regarding the same.
Once I dumped and copied over the file,on the target machine, while importing, will it perform the import such a way that it creates new entities while updating any existing ones and deleting any entities deleted in the dump?
Basically, will it keep the target mysql in sync with the dump i.e. the same as on the source?
Thanks
Long story short(ish):
Mysqldump will create an SQL file that, when imported in an empty environment, makes a database that is the same as the one the dump was created from.
So no: it will not "sync" anything (e.g. delete files or update records). You can actually look at the file and you will see statements that first create a database, then create the tables and finally insert your data.
They way it works that you take an empty server, import the database and you have you origional situation back. Nothing less, but definitely nothing more as well.
I have copied database folder from wamp/bin/mysql/data
As I open the phpMyAdmin, I see the database name, but when I click on them it is empty, as if no table has been created in them.
Where are my tables now? thanks
Copying the MySQL data directory is not a reliable means of backing up or moving your databases. The supported means is to export then import on the new server. There are a number of things that can go wrong, especially if you have InnoDB type tables.
The basic things you can check are file permissions on the new data directory, MySQL-level user permissions (assuming you're not already logged in as an administrative user, try doing so and see if things improve), and looking in the MySQL error log for any hints if there's something obvious, but it's very likely that something didn't transfer well.
I recommend that you go back to the original installation, verify your data, do a complete export (or "dump") to SQL format, then import that file to your new server.
I inherited the maintenance of a small web forum. Near as I can tell, it is powered by a MySQL database on the backend (the frontend is all PHP).
I need to extract some of the data (which also involves searching for the data I need to extract), but I don't want to touch the production database. I exported a database backup, which produced a several-hundred-megabyte .sql file.
What's the best way to mine these data? I can see several options:
grep through the .sql script in text mode, trying to extract the relevant data
Load it up in sqlite3 (I tried doing this, but it barfed on some of the statements in the script and didn't produce any tables. I have no database experience whatsoever though, so I haven't ruled it out as a dead end just yet).
Install MySQL on my home box, create a database, and execute the .sql script to recreate the data. Then just attach some database explorer tool.
Find some (Linux) app which can understand the .sql file natively (seems unlikely after a bit of Googling).
Any pointers to which of these options (or one I haven't thought of yet) would be the most productive?
I would say any option might work but for data mining, you definitely want to load it up in a new database so you can start query-ing the data and building reports on the data. I would load it up on your Home box. No need to have it remote.
I have a client who got a zipped file that has all the database they had in the SaaS app they were using. Now, we have a similar app but our column names are different (obviously) and in some cases we have less columns. So, now i want to upload all this data to my database but i am not sure how to do it?
I run phpmyadmin on the servers.
Extract the file on your desktop.
Login to your phpMyAdmin account.
Click the Import tab.
Select the file to import, file format, ect. and click Go.
Browse through the structure of the imported database to the columns of interest. For each column, click the pencil icon to edit the column (i.e. rename it), or click the X icon to delete it.
To merge data sets, after importing the tables, you would need to run your own query in the SQL tab to merge the data sets.
That are two different tasks in one question,
phpMyAdmin is able to import ZIP-files directly – you don't need to extract them on your local machine. Also be aware of max upload sizes and maximum script execution times, when importing huge database dumps.
To map an existing database to another structure involves a lot of manual work, like renaming tables and columns and copying data from on table to another.I would suggest, you import the old/original database to some "working copy" database and have your new database separate. That way you can use MySQL-features (INSERT INTO new_db.YX … SELECT XY_a FROM old_db.XY) to copy the data where it should go.
Well first you need to take a look at the data files and see how the columns/tables differ. After you sort that out you can go about about figuring out how it insert the data. If the files are large and there are quite a few i wouldnt use phpmyadmin. I'd ssh into the box and use the command line client or set the DB up for remote access and use a local copy of the client.
If youre lucky you won't have to do any processing on the data and you just map values from the old columns to the new columns as part of you LOAD DATA INFILE statement. Whatever you do youll want to test all this on a dummy db(s) first before you go running it in a live environment.
I've got the MySQL data files from an old server which has now crashed so I can not login to the server to do mysqldump etc. I am now trying to load the data on a new server. The only option I have is to copy/paste the data files that I have. But when I do so, some of the database tables throw this error "Table does not exist" when I can see it in my Navicat Window. The problem is only with some of the tables, not all.
My question is, how can I fix this error ? Or is there another way to import the data from data files?
The best piece of advice that comes to my mind is running a myisamchk on the respective table(s), paying special attention to the repair options.
Be sure to make backups of the data files beforehand.
Additional thoughts:
Make sure you have restarted the database server after adding the data files.
Are you sure you are addressing the correct table(s)? Note that on most Linux filesystems, the table name is case sensitive (as it's reflected by a file in the filesystem). So tablename != Tablename