General developer forum

I deal with this by creating completely new installations each school year. I then load all the classes, but only the course data, via backup and restore. We have a script that automatically creates the user accounts and assigns them to the proper classes. I keep the previous year's installation at a separate URL (ie. http://2005-06.school.com) That way we have a usable archive for teachers to reference and our current installation is free of cruft.

I believe there is already an admin option to delete logs older than some time. With a large installation, you definitely want that turned on. Yes, Admin -> Server -> Cleanup.

There already is the course_reset functionality, which discards most of the student-generated content (e.g. forum posts) and as of recently wipes out all the data about quiz attempts.

And you can of course, delete entire courses. And deleting a course should delete all associated data.

However, it is probably more a process question. How long do you need to keep information about finished courses available (there may be legal reqirements)? You probably need a procedure that says after X months, take a backup of the course and archive it, then wipe out all student data. Then after a further Y months, Completely delete the course from the system.

I would do this as a manual process in the first instance, perhaps helped by some custom reports (it is easy to stick new ones in the admin/report folder) that list courses that have been finished more than X months ago.

Later, when you are confident, you can consider completely automating it.

We've been grappling with this as well. Here's what we've decided to do. I'd be interested in feedback/suggestions on this strategy from others. Especially re data that will linger in our 'current' instance after trimming.

Goals:
* Maintain a well-performing site for current activities
(This means finding a way to trim data)
* Minimize downtime and disruption for users.
(This means consistent URL for active site. Limited migrations of courses.)
* Maintain course data for 7 years.

Strategy:
* At end of academic year (in August), make a clone of the current site and give the clone a name representative of its 'archive' purpose, e.g., moodleAY0607.school.edu. AY0607 = Academic Year 2006-2007, August to August.

* Trim active site of all courses no longer active or being developed.

* Trim archive site of all current/ongoing and future courses. (Keep it available and maintained for 7 years.)


We've developed some additional 'trimming' reports to the existing reports to facilitate this. For example, we've developed a 'trim courses' report that tries to identify courses that may no longer be active and gives us a single 'click' delete with a button. Same for users.

The one thing we'd like to improve here is the deletion of users. When we decide they're ready to go (e.g., they haven't shown up on the new site for a few semesters) then not only set their "deleted" value to 1, but to really delete them from the user table. If what Tim Hunt says is true, these users should have little to no data in our trimmed system...but we'd still like to trim our user table in our 'active' instance.

The real problem is not to purge data based on some criteria
or to delete logs older than some time.

The real problem is to archive data based on some criteria,
i.e. to delete data from current Data Base and at the same
time to insert the same data into the second Data Base "HISTORY"
related to educational history records about students, teachers, courses and etc.

The both Data Bases have to be usable through Moodle user interface.

Yes, Admin -> Server -> Archive

The Time Machine is my 2c.