Retrograde Upgrade

Retrograde Upgrade

by Bill McNutt -
Number of replies: 6

We were running Moodle 3.0.3 when we suffered a corruption of the \moodledata\filedir folder.

At this point, we discovered that our backup system had failed, and the only backup we had was VERY old.  Having no choice, we applied the old backup and things appeared back to normal, albeit with a significant data lose.  (Yeah, yeah, I know.  YOU cut a budget for proper backup equipment.)

Several weeks later another problem has reared it's ugly head:  very, very poor performance when loading the "Edit Submission page."  It takes up to three minutes for the file selection interface that lets you upload a file to appear.

A review of the version number tells me part of the problem:  my restore of the \moodledate\filedir folder appears to have pre-dated my upgrade to Moodle 3.0.3.  Settings>Site Administration>Notifications tells me that my current version is:

Moodle 2.9+ (Build: 20150625)
Copyright © 1999 onwards, Martin Dougiamas
and many other contributors.
GNU Public License


But the theme that I am using is clearly on I installed AFTER I updated my code to 3.0.3.

I believe that I restored my \moodledata\filedir folder for 2.9, but left my other folders at 3.0.3.

In an effort to resolve this, I attempted to apply the upgrade, and failed 100% of my plugin dependencies.  There's an entire PAGE of them.

Can anyone make a suggestion as to how I might can unknot this?


Bill

Average of ratings: -
In reply to Bill McNutt

Re: Retrograde Upgrade

by Ken Task -
Picture of Particularly helpful Moodlers

One question ... which, unfortunately, may add to your pain .... what did you do with the DB in whatever you did when?   Data contained in DB concerning filedir must match.  All the plugins now have version dates .... even core.   Versions dates in files should match what's in related tables of Moodle.

'spirit of sharing', Ken

In reply to Ken Task

Re: Retrograde Upgrade

by Bill McNutt -

I thought that might be the case.

I left the DB alone.  That it's it's still running the one compatible with the 3.x version of the software.  It has months of activity stored in it.  There's nothing wrong with our SQL backups, though. I may be able to backrev that database.  What would I lose if I did that?

In reply to Bill McNutt

Re: Retrograde Upgrade

by Bill McNutt -
I was wrong.  The SQL backups from that far back are unavailable.
In reply to Bill McNutt

Re: Retrograde Upgrade

by Ken Task -
Picture of Particularly helpful Moodlers

It's looking 'bleaker' .... last hopes ...

Is this implementation of Moodle and the OS it runs on in a virtualized environment?   Got a backup of that?   If not too far back, one could restore the virtualized environment and that should allow you to get to a working moodle.   Make backups of code, data directory and DB (if DB on same server).   Could use those to restore to production site ... knowing that data loss cannot be prevented.

The longer way ... depending on response to next question:

Was the site running autobackups of courses - full courses ... including users?

IF so those would be spread out all over filedir but not touched by any upgrade attempt.

Here again ... expect loosing some data but one could painfully find those backups and restore those courses to a fresh install of Moodle.

Am really now out of ideas.

'spirit of sharing', Ken



In reply to Ken Task

Re: Retrograde Upgrade

by Bill McNutt -

No, the server does not run in a virtualized environment.   If it did, I'd have gone there already.  

Nor was the site running auto-backups of courses.

All I have is a month of daily backups of the SQL database that post-date the corruption of the /filedir directory,

a copy of the /moodledata directory that's about a year old that was set aside

And a copy of the moodle code from about the same time as the /filedir directory


But the server works, in a horrible, limping manner.  The users can all log in. They can see their course material, see the extant submitted responses.  The grades all appear to be there.

The problem is that when they want to upload an assignment, it takes three minutes for the interface to load. If that hadn't happened, we wouldn't even know there was an issue.

What blew up in my face was my attempt to upgrade from this poor, mutant hybrid to 3.x.  I was able to roll back to the poor mutant hybrid because appearances to the contrary, I'm no fool. I copied everything before I started dinking with it.

But you've given me a plan "C."  (Plan B is to lock the current server and create a new instance for going forward and used this busted ass mess for reference only.)


Plan "C" - Attempt to back up all the courses, with uses and attendant data, and restore them to a new instance, one at a time.  Painful, but if the backups will run, doable.

In reply to Bill McNutt

Re: Retrograde Upgrade

by Ken Task -
Picture of Particularly helpful Moodlers

In for a penny ... in for a pound ... is that what is said?

Question: php version on current production server is?

PHP 7 is true 64bit for your platform ... for the longest time Windows folks have suffered with 32bit PHP for years (32bit PHP on 64bit hardware).   Wonder if current server, given it's current delicate state, could benefit by upgrade to PHP 7?   You are already running a supported version of Moodle in 3.0.3 (or did I get that wrong).

Does Windows have any good tool like MySQLTuner for MySQL DB's?

I'll go a little further in making some suggestions for new box ... new box php 7.   Record every tweak you have made to IIS, PHP, msssql for current production and put them in place even before you start to rebuild the new server.

And, while building new, look into 'poor man's backup solutions' ... does anyone make rsync for Windows?   Thought newer versions of Windows now had availalbe for installing many of the tried and true Linux tools ... bash shell, etc.

Nice to hear you do have plans now.   Do hope the easiest works and if not the least painful alternate plan.   Best of luck!

'spirit of sharing', Ken