Answers.Body: <p>In general, importing/exporting using csv means you will lose data, eg log history of change, the "real" creation date instead of the restore one... 
  If you can at all, I would suggest to backup restore the database itself, rather than only the contact via csv.</p>
  
  <p>This being said: do you have an error message? it might be a matter of memory, try to increase what php can use. Or select on the export what fields you really want to export, the default tend to include lots you don't really need.</p>
  
  <p>If you can, try to create a temporary table that you import/export with phpmy admin (not civicrm_contact, say got for backup_contact), on the import step you can choose to import from sql rather than csv</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-01-29T21:27:49.237Z
Answers.Text: I'll take this a step further that you can NOT make a backup via CSV.  CSVs are flat files; CiviCRM is stored in a relational database.  You'd need close to 200 CSVs to accurately represent CiviCRM data as a CSV, and most of those CSVs can't be exported from the Civi UI.
Answers.UserDisplayName: Jon G - Megaphone Tech
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-01-29T21:57:21.683Z
Answers.Text: Jon is absolutely correct, you will loose data, ie. it won't be a complete backup/restore, but might be enough, depending if you care about what is lost in csv translation ;)
Answers.UserDisplayName: Xavier
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-01-29T21:23:33.700Z
Answers.LastActivityDate: 2017-01-29T21:23:33.700Z
Answers.UserDisplayName: Xavier
Body: <p>Running CiviCRM latest on Joomla latest, Dutch translation, locally on Windows 8.1 and xampp, online with hosting; Joomla and CiviCRM installed and working. Now I would like to backup the complete installation. </p>
  
  <p>I exported all of my 2000 contacts to a CSV file. I am trying to import the 2000 contacts from the same file, on localhost as well as online.
  The first step is successful, CiviCRM adds the first row as labels, the second row with data. The second step, creating the mapping the labels fails for all.  After the mapping I get an error on all contacts, so no contact is imported at all.
  If I choose to import only the obligatory * labels, names, mail, CiviCRM imports only those.  So I end up with only the contacts and have to do the rest manually (no email, no bulk, etc.)</p>
  
  <ul>
  <li>Is the order of the importing columns in the CSV important? So, first column = name, second colum= mail etc?</li>
  <li>Is the translation in Dutch causing problems mapping?</li>
  <li>I tried to edit the CSV with open office and saving in utf8, the same problem; does the file change after editing in such a way that importing is a problem?</li>
  <li>is it possible to backup by exporting the database to SQL file and if needed restoring by uploading the same SQL again with PHPMyAdmin?</li>
  </ul>
  
  <p>Thank you</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-01-29T07:13:42.403Z
Comments.Text: excuse me for the bad formatting,enter didn't seperate the lines? Rob
Comments.UserDisplayName: Rob
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-01-29T10:01:17.617Z
Comments.Text: Just wondering, is the CSV created from a CiviCRM export or has it an another source? It helps if you add a screen shot of the misbehaving mapping.
Comments.UserDisplayName: Kainuk - CiviCooP
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-01-30T09:31:22.863Z
Comments.Text: thank you for your answers
  problem is the database containing the civi has been very corrupted; we managed to restore the joomla part and only have an older backup cvs file for civi even if I try to export in a new installation of joomla and civi I still get some errors importing the same file again, olny some fields like name etc. can be restored; the rest we have to do manually the import php.ini etc is ok, we can import 90 MB files but as said before they are corrupt error messages are of civi only reporting the data cannot be imported
Comments.UserDisplayName: user4246
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-01-31T15:37:01.100Z
Comments.Text: From the situation you've described, I would consider hiring a professional to restore your data: https://civicrm.org/providers
Comments.UserDisplayName: Jon G - Megaphone Tech
Tags: <joomla><import>
Title: Best strategy to restoring backup by importing csv file
ThreadText: # Best strategy to restoring backup by importing csv file
  
  (Asked by: username_0 on 2017-01-29)
  
  Running CiviCRM latest on Joomla latest, Dutch translation, locally on Windows 8.1 and xampp, online with hosting; Joomla and CiviCRM installed and working. Now I would like to backup the complete installation.
  
  I exported all of my 2000 contacts to a CSV file. I am trying to import the 2000 contacts from the same file, on localhost as well as online.
  The first step is successful, CiviCRM adds the first row as labels, the second row with data. The second step, creating the mapping the labels fails for all. After the mapping I get an error on all contacts, so no contact is imported at all.
  If I choose to import only the obligatory \* labels, names, mail, CiviCRM imports only those. So I end up with only the contacts and have to do the rest manually (no email, no bulk, etc.)
  
  * Is the order of the importing columns in the CSV important? So, first column = name, second colum= mail etc?
  * Is the translation in Dutch causing problems mapping?
  * I tried to edit the CSV with open office and saving in utf8, the same problem; does the file change after editing in such a way that importing is a problem?
  * is it possible to backup by exporting the database to SQL file and if needed restoring by uploading the same SQL again with PHPMyAdmin?
  
  Thank you
  
  **Tags:** joomla, import
  
  > **Comments:**
  > **username_0**: excuse me for the bad formatting,enter didn't seperate the lines? username_0  
  > **username_1**: Just wondering, is the CSV created from a CiviCRM export or has it an another source? It helps if you add a screen shot of the misbehaving mapping.  
  > **username_2**: thank you for your answers problem is the database containing the civi has been very corrupted; we managed to restore the joomla part and only have an older backup cvs file for civi even if I try to export in a new installation of joomla and civi I still get some errors importing the same file again, olny some fields like name etc. can be restored; the rest we have to do manually the import php.ini etc is ok, we can import 90 MB files but as said before they are corrupt error messages are of civi only reporting the data cannot be imported  
  > **username_3**: From the situation you've described, I would consider hiring a professional to restore your data: https://civicrm.org/providers  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_4 on 2017-01-29. Score: 3
  
  In general, importing/exporting using csv means you will lose data, eg log history of change, the "real" creation date instead of the restore one...
  If you can at all, I would suggest to backup restore the database itself, rather than only the contact via csv.
  
  This being said: do you have an error message? it might be a matter of memory, try to increase what php can use. Or select on the export what fields you really want to export, the default tend to include lots you don't really need.
  
  If you can, try to create a temporary table that you import/export with phpmy admin (not civicrm\_contact, say got for backup\_contact), on the import step you can choose to import from sql rather than csv
  
  > **Comments:**
  > **username_3**: I'll take this a step further that you can NOT make a backup via CSV.  CSVs are flat files; CiviCRM is stored in a relational database.  You'd need close to 200 CSVs to accurately represent CiviCRM data as a CSV, and most of those CSVs can't be exported from the Civi UI.  
  > **username_4**: Jon is absolutely correct, you will loose data, ie. it won't be a complete backup/restore, but might be enough, depending if you care about what is lost in csv translation ;)  
  
  ---
  
  