CiviCRM Community Forums (archive)

Martin - getting through the upgrade step by step might be a real chore. My advice would be to first review your DB backup to identify *why* it's unusable, because fixing that issue is likely a path to a much quicker solution.

That said, CiviCRM stores its upgrade processes in civicrm/CRM/Upgrade/ - there are .SQL and .PHP files in that folder (eg CRM/Upgrade/Incremental/php/FourOne.php, and CRM/Upgrade/Incremental/sql/4.2.alpha1.mysql.tpl). If you extract the statements from those files, and execute them in the correct order, you could then upgrade manually.

This is not a task for the faint of heart, nor one you should undertake lightly. See if you can get back to a recent backup, then go forward from there.

I've added a note to the upgrade guide recommending people to test backups before upgrading. I don't know if it'll get seen or just add to the many screens of warnings and notes already there, but I hope it helps someone.

FWIW, my process is to use the DB backups to test a reproducible upgrade process until that works flawlessly, then repeat the same process on the live site.

Use whatever works. You'll only be able to work out which of the two evils (4.1 or 4.3 on a 4.unknown DB state) is less worse by testing yourself. If it's letting your contacts do the basics and you aren't losing data, maybe that's not so bad.

Understandable that a DB backup from two months ago isn't going to be much help at this point. You may well be best off exporting to CSV and starting again (either with CiviCRM on a suitable hosting platform, or another software entirely). Don't shy away from that approach, it may do what you need to get fully operational again.

That said, here's my notes on taking the rockier road

The "repair" method I've used recently on a heavily customised DB which had trouble upgrading was to dump data to a data-only .sql file, reload the DB schema from the schema supplied with your DB, then reload the custom data from your .sql into the fresh DB.

I've been using a this bash script (modified for publication) to do this to a customised DB locally. That script does more than what you need, but it should cover what you need to do.

If you're stuck in a "partially upgraded" DB state, you (or your developer) will need to make your way through the upgrade steps and identify where your upgrader got to. By manually applying (or unapplying) a few updates for that minor version, you should be able to put your DB in a state which the upgrader can identify and support progress from.

Good luck.