4

Unfortunately I tried to (auto)upgrade to v2.5.latest on a live site (after testing on another development (but different site)) and it failed resulting in the site being down. What is the best way to restore the site to pre-upgrade and working state? I plan to

  1. Remove the existing database and replace with the one created by the backup process - that part seemed to go OK.
  2. Replace the /craft/app directory from the version that matches the database backup.

Are there other files/things I need to do to recover the situation?

3

That should do it!

Auto-updating to 2.5 is causing a few people headaches, mainly because people are bumping up against their php.ini setting limitations. It's a pretty significant update, requiring pretty significant server resources to handle the transition.

Once you've successfully rolled back, I'd recommend performing a manual update. This takes a lot of pressure off of your server, and only leans on your server resources to run the database migrations (which definitely shouldn't cause any overloads).

  • Thanks Lindsey. I sort of resorted to that when I rolled the database back first but left the new files in place. This left me with the 'Finish up' button. So I tried that - same process - I do get all the way through to the All Done tick icon at the end - and only then do the error messages start. And the front end remains down. So would that suggest the problem is happening when the files are being copied over? – Jack McKenzie Dec 7 '15 at 4:58
  • Absolutely. The file syncing mechanism of auto-update is what's being the biggest drain on your server, and unquestionably the part that failed halfway. You'll want to scrap your current app folder, and completely replace it fresh. Don't let any old files merge with new ones. – Lindsey D Dec 7 '15 at 5:01
  • Check out this awesome breakdown by Brad... specifically the subsection entitled "Does Craft practice safe-updating?" – Lindsey D Dec 7 '15 at 5:02
  • I've found that I'm having to manually update most of our Craft sites when they run on my Mac in local development; it's an owner issue rather than permissions. Apache runs as _www but the filesystem is owned by me. Seems to screw things up even though app and its contents are 777. – Matt Wilcox Dec 7 '15 at 9:10
  • Update: after restoring the site to the pre-update version as per the discussed method, I then carried out a manual file update and that allowed the database migration process to go smoothly. From now on, I think I will do the updates manually as this makes it easy to have all the files ready on the server for an immediately rollback should something go wrong. It also helps know what to do! – Jack McKenzie Dec 7 '15 at 10:07

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.