What Counts As "Modified" for Automatic Backups?

What Counts As "Modified" for Automatic Backups?

by Natassia Stelmaszek -
Number of replies: 19

For Automated Course Backups there is a setting that tells the system not to back up a course that hasn't "modified" within a given period of time.  What events cause a course to be flagged as modified for the purposes of the automated backups?

I updated to Moodle 3.4 on December 21st and there was a sudden increase in the number of courses that were being backed-up.  I thought that something in the new code caused the issue so I set the system not to back up any courses that hadn't been modified within the past 7 days but that hasn't helped and it is quickly eating up disk space.

We have 216 courses on the system but not all of them are in use.  For the past several months the system was backing up 25 courses and skipping the rest.  On the day after the upgrade to Moodle 3.4 it backed up 94 courses and it has been doing that ever since. 

I timed the upgrade to occur during the university’s winter break while the students were gone and most of the faculty was on holiday.  I can imagine some activity to prepare for the winter quarter but not effecting so many courses and not all at once.

There are strategies that I can use to reduce the disk space consumption such as reducing the number of backups for a given course and shortening the time period before the system begins to delete old backups but I don’t understand why my current strategy is suddenly failing to produce the expected results.

 

 Natassia


Details:

Moodle 3.4 running on a virtualized server with CentOS (current version) as the OS.

Automated backups enabled to run on Sun, Mon, Wed and Fri mornings.

Saved to a specified directory

Maximum number of backups kept: 40

Delete backups older than: 120 days

Minimum number of backups kept: 1

Skip courses not modified since: 7 days

 


Average of ratings: -
In reply to Natassia Stelmaszek

Re: What Counts As "Modified" for Automatic Backups?

by Stuart Mealor -

You ask: "What events causes a course to be flagged as modified for the purposes of the automated backups?"

Not an official response, but I have always assumed that ANY change in the course setup or content will be logged as a change, and therefore mean the course has been modified.

An obvious example is adding a new resource.

But from your question, I wonder if something like a synchronisation of users from an external system would also count - if the user data is updated in any way?

"We have 216 courses .....  system was backing up 25 courses and skipping the rest .... after upgrade to Moodle 3.4 it backed up 94 courses ..."

OK, so it's not backing up all courses.

So it's possible a setting that was at default before, has a new default now in Moodle 3.4.

As a first step, I would go through the automated course backup page, check, de-select and re-select the settings as you want them, and then see what happens.

PS - in terms of conserving server disk space, do you really need 40 copies ?

In reply to Stuart Mealor

Re: What Counts As "Modified" for Automatic Backups?

by Natassia Stelmaszek -

Still hoping for an answer.

Reducing the number of copies is one option.  In the past we've had some rather bizarre requests from professors like, "I need a copy of the course the way that it was at the start of the month."  We could accommodate those requests while the number of backups was low and now the faculty seem to expect that we'll always have that ability.  I'd like to find out if legitimate course changes are being made or if someone is doing something silly that is causing me headaches.

I can conceive a situation where a large number of changes might be needed but not to 94 (now 98) being modified on at least a weekly basis.  I'm concerned that there might be some automated process, course configuration, etc.,  that is triggering the "Modified" status.

Natassia

In reply to Natassia Stelmaszek

Re: What Counts As "Modified" for Automatic Backups?

by Rebecca Trynes -

I have found something very similar happened in my upgraded instance of Moodle. I went from 3.1.5 to 3.3.2 and now a bunch of courses from 2 years ago are getting backed up due to a calendar event being added on an assignment that hasn't seen activity since 2015!

These calendar events were added just yesterday via the course report log.

Was there some code added to Moodle core that would have caused this new event to pop up in old courses? Maybe a new database column in the event table??? Or simply a new event for assignments that automatically add an event to the calendar? i might have to look back through the change log to see if I can work it out.

More importantly: when will it stop!

If anyone knows anything, I'd love to hear it.

In reply to Rebecca Trynes

Re: What Counts As "Modified" for Automatic Backups?

by Rebecca Trynes -

I suppose it could have something to do with any of the following updates that occurred in assignments?


=== 3.3.2 ===
* assign_refresh_events() Now takes two additional parameters to refine the update to a specific instance. This function
now optionally takes the module instance object or ID, and the course module object or ID. Please try to send the full
objects instead of the ids to save DB calls.
=== 3.3 ===
* All pluginfile file serving functions now pass through the options to send_stored_file() (all assignment plugins should do
the same).
* Fixed calendar event types for overridden due dates from 'close' to 'due'.
* Removed calendar event type of 'open', since mod_assign only has the 'due' event type. No point in creating an override event
for an event type that does not exist.
=== 3.2 ===
* External function mod_assign_external::get_assignments now returns additional optional fields:
- preventsubmissionnotingroup: Prevent submission not in group.
- submissionstatement and submissionstatementformat: When there is a submission statement defined.
* Proper checking for empty submissions
* Submission modification time checking - this will help students working in groups not clobber each others'
submissions
* External functions that were returning file information now return the following file fields:
filename, filepath, mimetype, filesize, timemodified and fileurl.
Those fields are now marked as VALUE_OPTIONAL for backwards compatibility.
Please, note that previously the filename was part of the filepath field, now they are separated.
* Submission and feedback plugins can now specify file areas related to their configuration data,
which will then be included in backup and restore; see assign_plugin::get_config_file_areas().
* Submission and feedback plugins must now return the specific list of configs available for external functions,
this can be done implementing the new assign plugin method get_config_for_external()
* Webservice function mod_assign_get_submissions returns a new field 'gradingstatus' from each submission.
In reply to Natassia Stelmaszek

Re: What Counts As "Modified" for Automatic Backups?

by Renaat Debleu -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Plugin developers

When I compare all backups, I can only find changes in the users.xml file.

So when the auto backup includes users (backup_auto_users setting is enabled), any change of a user preference of one of the participants is registered and seems to trigger a new backup.

Natassia, can you confirm that you also include users into the backups?

In reply to Renaat Debleu

Re: What Counts As "Modified" for Automatic Backups?

by Natassia Stelmaszek -

Renaat,

Yes, "Include users" is checked on the "Automated backup setup" page.  I doubt if real changes to user data would be the cause of this problem.  I am seeing the same type of excessive backups on our Beta test system which has very few users, all of them staff members and usually I am the only one that ever logs into the system.  Could the mere act of logging into the system trigger the updates?

I could not find a file named users.xml on my system under the moodle directory.  (CentOS 7, Moodle 3.4+)  Where is it?

Natassia

In reply to Natassia Stelmaszek

Re: What Counts As "Modified" for Automatic Backups?

by Emma Richardson -
Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Plugin developers

If you are including logs, I would presume that any action would trigger a change...

In reply to Emma Richardson

Re: What Counts As "Modified" for Automatic Backups?

by Natassia Stelmaszek -

"Any" action is a pretty broad term, backing up a course could be considered to be an action that is logged which in turn would trigger another backup leading to a perpetual loop. 

My reasoning is that someone, at some time had to write some code that determines whether or not a course should be backed up.  It might be a series of "if-then" or "case" statements that evaluates the administrators' settings under "General backup defaults"  and "Automated backup setup" along with a course's attributes or perhaps it is in the form of a flag that can be set by various processes.  It may be rooted in ancient Moodle code that no one has examined in years.  I'm not a developer but I'm willing to try to dig up the answer if someone could give me a clue about where to start searching.

Something happened coincident with my update to Moodle 3.4 that suddenly caused the number of courses being backed up on my system to quadruple.  Evaluating the criteria listed on the Moodle pages that are available to the administrator, says that it should not be happening.  I'm just trying to figure out how to get it to go back to "normal".


Natassia 

Average of ratings: Useful (1)
In reply to Natassia Stelmaszek

Re: What Counts As "Modified" for Automatic Backups?

by Séverin Terrier -
Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Testers Picture of Translators

Hi Natassia,

I totally agree with your point of view. I think that something introduced in Moodle 3.4 (an event in log ?) generates lots of uneeded backups, because courses are considered modified, which should not be the case (having an automatic backup should be an exception).

For me, this should be considered as a regression!

Séverin

In reply to Séverin Terrier

Re: What Counts As "Modified" for Automatic Backups?

by Séverin Terrier -
Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Testers Picture of Translators

Hi again,

After digging a little, i found that MDL-53537 introduced the course_backup_created event in Moodle 3.4, which is the cause of this problem.

Hope that knowing the origin of this regression, a solution could be find soon.

Séverin

In reply to Emma Richardson

Re: What Counts As "Modified" for Automatic Backups?

by Renaat Debleu -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Plugin developers

In automatic backup settings, I disabled:

  • users
  • logs
  • calendar events
  • user completion information
  • histories

But some visible courses are still backed up while in the database there are only \core\event\course_backup_created log entries for the last month.

Digging into the cron logs, I found that the function is_course_modified (checking timecreated > :since and crud <> 'r') returns true while this should not happen. The moment we find out why, ....  

Average of ratings: Useful (1)
In reply to Renaat Debleu

Re: What Counts As "Modified" for Automatic Backups?

by Renaat Debleu -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Plugin developers

We have a chicken and egg situation: because a backup was created, the course is considered to be modified.

If someone has an idea how these backup creation logs in all log stores can be ignored, a lot of CPU-time and storage space can be saved.


In reply to Renaat Debleu

Re: What Counts As "Modified" for Automatic Backups?

by Natassia Stelmaszek -

Is there a way that I can make certain that this gets on the developer to-do list?

Natassia

In reply to Natassia Stelmaszek

Re: What Counts As "Modified" for Automatic Backups?

by Séverin Terrier -
Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Testers Picture of Translators

Hi Natassia,

At least you can vote for MDL-61578, test the solution provided by Renaat and add comment.

Séverin

In reply to Séverin Terrier

Re: What Counts As "Modified" for Automatic Backups?

by Natassia Stelmaszek -

I looked at the tracker but I'm not a developer.  The only thing that I've ever used GIT to do, is to update my system after a code release.  I don't know how, or even if I am able to "vote".  I do have a Beta system that is experiencing the problem so I'm willing to test but someone would have to tell me how.

I'm probably just going to have to wait.

Thanks for working on this!

Natassia

In reply to Natassia Stelmaszek

Re: What Counts As "Modified" for Automatic Backups?

by Natassia Stelmaszek -

Possible Temporary Workaround?

I stumbled on something that stopped (for the time being) the excessive backups.  

A quick review, my problem was that my disk space was being rapidly consumed.  The root cause was traced to the fact that a recent code change created an infinite loop where the act of performing a backup was counted as a "change" to the course so that the course would get backed up repeatedly even when there weren't any actual changes made to the courses.

I accidentally prevented the scheduled backups from running for a week, after I resumed the backups the cycle seemed to have been broken so that only actual changes to the courses caused backups.  I suspect that the situation still exists and that although there are currently far fewer courses being backed-up, that they will continue to be backed up forever and the number of courses involved will slowly grow until the situation becomes critical again.

How did I interrupt the backups?  I meant to install an update for a plugin on my test system but accidentally began the process on my Production system.  I didn't realize my mistake until I got to the step where the system asks if you want to update the database and I stopped.  After I had installed and tested the update on my test system (about 1 week later), I updated the database on the Production system.

I still think that this is a coding problem that should be fixed but at least for me, it is not as urgent.

Natassia