Tried to download the over 500.000 files, but that may require days (25.000 solved). So possible delete manual folder for folder might be easier to keep the oldest versions in en: de: pt: zze origin. -> not so, it takes a huge of time, an hour for one folder.

Sorry, I was very busy lately. But it looks like the reason was found. Good to know what is happening to all this disk space and how to keep more of it available for use.I am now making a backup of ATI.eu and will try to make a script for the cleanup cronjob later in the evening.

Quote

Tried to download the over 500.000 files, but that may require days (25.000 solved). So possible delete manual folder for folder might be easier to keep the oldest versions in en: de: pt: zze origin. -> not so, it takes a huge of time, an hour for one folder.

I have already completed the backup with the Greensta backup function and am downloading it now. So the current state of the Wiki should be safe.

Deleting attic files with a cronjob script directly on the server later should run fast.

Cleanup cronjob is now running every hour.It is set up to delete nothing which is newer than 30 days, and also to always keep at least the first three and the last three versions.At the moment only cleaning up in "data/attic", but there are other places like "data/media_attic" (not much there at the moment), the cache (some gigabytes) and maybe more. Just not quite sure yet about how everything else works, not wanting to delete too much. So there is still room for improvement.Disk space usage for accesstoinsight.eu is now shown as 8.02 Gigabyte. Not sure how much it was before.

* Now leaving for tonight. May all the deleted files find a fortunate rebirth, if not release into nibbana.

Oops. The reason was that I had assumed without checking that files would be sorted by filename when reading directories in PHP. So the first and last 3 of a randomized list of revisions were kept for each file.

Now that is fixed. If necessary, the old revisions could still be restored from the backup if one can download the file. But it seems that Greensta is still having the same old problems with not being able to download large backup files (download stopping after 1 gigabyte). I have written an email to Greensta to inform about the problem.

Good to know. Maybe the Cleanup plugin is a cleaner overall solution, already well-maintained by others. But with the cronjob now everything seems to be running fine, and it is easier to maintain one's own custom logic of what to clean up (i.e. keep first and last three at the moment).I will try to add media attic and cache cleanup soon.

If necessary, the old revisions could still be restored from the backup if one can download the file. But it seems that Greensta is still having the same old problems with not being able to download large backup files (download stopping after 1 gigabyte). I have written an email to Greensta to inform about the problem.

My person does not think it is necessary to restore, still huge general modifications. How ever, if there is a backup available for some times, in cases, that's sure fine.

...Good to know. Maybe the Cleanup plugin is a cleaner overall solution, already well-maintained by others. But with the cronjob now everything seems to be running fine, and it is easier to maintain one's own custom logic of what to clean up (i.e. keep first and last three at the moment).I will try to add media attic and cache cleanup soon.

Maybe a function that deletes older Versions made with in a timeframe of say 24h, or 48h as well, would be good, since the versions-producing replacment sessions are surely nevertheless able to fill the webspace within one or to days again.It then might even not require to delete all older after the busy times at the beginning.