Best practice for moving content from production server to dev server
Modifying an existing project without loosing data is a common need.

Use Features

One of the best practice I know, is to use the Features module to deliver all the modifications you have made on the production server. Features allow you to make custom modules containing content type structures, views definitions, and a lot more.

You'll probably also need to use the Strongarm module to be able to retrieve the settings variables of some part (modules configuration for instance).

Those modules really help to deploy modifications on a production site, even using git. You'll find easily some good tutorials about using Features.

The only important part to know is when you start using Features, it's difficult to stop using it. Because it will create and implement custom module containing all the specifications of your website (content types, fields, views, pages, ...). If you disable it / them, everything disappear.

Export modifications

If the modifications on your project are not to complicate (mainly content types structures and views), you can use the export / import possibilities offer by some modules (views for instance).

You can also use Bundle Copy module for the node content types export and import part.

Hard way

After, there is a hard way I use sometimes. It is working only if you did not change the fields settings of your existing content types, and if you just add some (fields and content types).

You can copy in your development server database the content tables of your production server. You have to well know all your content types, and specifically the fields used in them (specially the machine names of the fields).

=> You will lose all the new and modified nodes of your dev server. Then do not hesitate to make a backup of your database first.

If you are in the case, you can copy from the production server all the content tables :


node : the base node table with all the content informations
node_revision : if you want to get back the revisions informations
for each one of your content type fields :


the data table : field_data_[field_name] (ie : field_data_body)
the revision table : field_revision_[field_name] (ie : field_revision_body)

url_alias : The custom path of your content (if needed)
taxonomy tables : if you need to, but it can be tricky 
user tables : users and users_roles (if needed)