3

The person who was supposed to be maintaining my CiviCRM on Drupal instance flaked on my a while ago and my site has been sitting vulnerable. Due to hosting changes, I decided to just set up a clean new instance on the new host but I need help as to how best to move the Civi records (and also config if possible!) over considering my old MySQL database may have been compromised.

Help! Thanks a lot!

| improve this question | |
  • Can you clarify in the question if the issue here is that the system has been left with security flaws, and the concern is that there may have been injections of undesirables in to the db (which is how i read it) rather than a corrupt db in the sense that the schema is now in bad shape? – petednz - fuzion♦ Jul 27 '15 at 4:30
4

Before pronouncing the old database deceased, I would make sure the structure is correct and if not what is broken. You can try this: https://github.com/progressivetech/civi-schema-harmonizer or http://wiki.civicrm.org/confluence/plugins/servlet/mobile#content/view/86213632. The current dB may be ok.

| improve this answer | |
  • 1
    As someone who does CiviCRM migrations professionally, this sounds like a LOT less work than migrating the data. – Jon G - Megaphone Tech Jul 26 '15 at 18:50
2

If you wish to transfer the content of the database a) export the existing data. You can do this as an action from the search/find screens. Export contacts, activities, memberships, contributions as separate files. b) on the new system, import each file. Use the old contact_id field as the external_identifier to help all the records match up.

This is easy in concept, not so easy in practice! If you have custom fields, you'll need to recreate them. If there are custom option lists, those will also need to be recreated ... as well as member types, financial types (if custom), etc.

So .. if you can, stick with moving the database. If necessary, you can roll up the sleeves and expect to spend quite a bit of time exporting and importing.

| improve this answer | |
1

Sounds like you may be in over your head. I recommend hiring a professional to help you with this.

In general, questions on this site should be in the realm of "I understand X and Y but have a question about Z" rather than "I need you to walk me through X Y and Z and I haven't really read A B or C either." Your question sounds more like the latter category but it might just be the way it's worded. If you disagree, please feel free to edit your question to show more of your research and understanding of the migration process, and the specific step you need assistance with.

| improve this answer | |
  • Believe me, if we had money I'd just pay the money. We are a small community-run food cooperative and can't really afford to pay anyone. I read this book.civicrm.org/user/current/common-workflows/importing-data and am wondering whether I could just download the various records (contacts, members, payments) as CSV and upload them to the new CiviCRM instance. I am skeptical that it would work well but I want to know what my options are before I throw my hands up. – Camille Acey Jul 23 '15 at 18:49
1

Agree with Coleman. It should be possible to get an audit done of your old civi db to look for any suspicious data and based on that determine if your db can be copied over or whether the data needs a full export/import. We are just about to rip in to a site that was compromised as a result of DrupalGeddon to see if we can assure ourselves and the client if the civi data is 'clean'. We will probably document how that went in case it is of help to others in the future.

| improve this answer | |
  • I'd appreciate such documentation. – Camille Acey Jul 23 '15 at 18:53
  • 1
    Noted. Hopefully we get to do this audit next week. Maybe we can then offer to run same through yours to help test our process. – petednz - fuzion♦ Jul 23 '15 at 22:34
1

Here's some tips that helped me when I had issues with a db that wouldn't upgrade due to errors.

My original database was stuck at 4.3.3 and had gone through many upgrades and a couple times had some errors on the upgrade. Even after switching to civihosting my 4.3.3 database gave a trigger error that triggers weren't enabled. We (Hershel and I) determined that it had to be with the db. So I got the bright idea to compare the structures of the corrupt db with a clean 4.3.3 structure. Here are the steps I took:

  1. I did a structure dump of the Corrupt DB minus the custom tables. I imported the civicrm.mysql file from the 4.3.3 build into a clean db
  2. I did a structure dump of the clean import and then compared the files using a Diff tool.
  3. There were alot of issues that confirmed for me it was the db. I ensured that all column names matched between the two db's.
  4. I then did a structure dump of the custom tables in the corrupt db, then a data dump of the custom tables in the corrupt db, then a data dump of all the other tables in the corrupt db.
  5. Then I imported into the clean db in the following order: the structure of the custom tables, the data of the custom tables, the data of the other tables.
  6. Then I ran the upgrade to 4.3.5 and it upgraded without any errors
| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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