Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

At the place I currently work they do some thing I consider strange in the way they work with the MySQL datadir. The directory in which the files that actually store the data are kept.

$ grep datadir /etc/mysql/my.cnf
datadir = /var/lib/mysql

Where all the .frm .myd .myi files are found.

When moving data around on the network or doing client installs they copy these files directly out of the this directory and past them into which ever directory they have set up MySQL to use on the client side. They do the same thing at the office.

I was taught as a Database Administrator that you should work with the scripts. Export the data and structure of the database as a SQL script and import it as a SQL script when you want to start working with it. This is to protect the data integrity. As those files can be in a state inconstant with a working copy of the data. As caches may not have been written to the database files on the disk. I see that they stop the MySQL server when doing the copying and pasting so that should prevent the data becoming corrupt.

I was wandering what industry best practice is around this issue. It seams strange to me. Considering how they view security, concerning passwords and root access I think they have developed a bad practice and are doing it ignorantly. They don't have a strong understanding of some of the fundamentals of how database systems should work. Am I wrong, should I just go with the flow and not get involved with trying to change these practices.

share|improve this question
up vote 1 down vote accepted

Generally you will use the proper backup mechanism, mysqldump in the case of MySQL, along with testing that the backup can be successfully restored. It's better to pretend that every backup and restore is being audited by someone very official looking.

share|improve this answer

If they are setting up a duplicate of an existing db e.g. starting db state for an application AND the db they are copying is not under heavy use (ideally almost no use) - then this is a quick and simple method.

If the database is under even light use however, this is pretty poor as you risk various lock delays and it's difficult to know exactly what state you will be copying.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.