Ojs 2.4.7.1, everything worked fine for more than 2 years.
Following a failed entire site backup (finished with “not enough space on disk”) some errors (malfunctions) appeared :
all the archives (the list which displays the published issues) displays now a white page (the header disappears).
some sorting (by author, title) works, some display a white page with\without header.
some created pages with the custom page creator are displayed some are not (blank page \ with or without header).
All other functionalities seems to work, published articles are still on their places.
Accessible only if having their link \ address, not by browsing issue, article list (the article lists exist, the issues exist, only the list of the issues is gone).
Thank you very much for the remarkable quick answer.
Before seeing your answer, on an installed OJS platform with just one journal I did the following steps:
cleared all the cache’s.
then went to every setup step and confirmed every page (without modifying contents).
did the same operations with the plug-ins in use (custom page, block, etc).
Everything looks fine now, all links \ queries are working.
Nothing new appeared on the error log (before my intervention and after).
Is this kind of behavior (archive, published issue list missing) a consequence of the lack of disk space? Never happened before (the malfunctions and the disk space shortage).
Is possible that the data base(s) went corrupted?
I’m really not familiar with, but is there a scheduled maintenance task that may trigger such consequences? (meaning tomorrow things will be back).
Really sorry for the elementary questions and a BIG thank you for your help.
Yes, it’s likely that filling up the disk caused this due to a corruption in the cache.
The database should include reasonably robust integrity checks, so I think the likelihood of your database being corrupted is pretty low.
I’m not a server administrator so I’m less well versed in good practices for managing server space, but it’s pretty common to run your backups onto a different filesystem so that an out-of-control backup won’t take down other services. Other kinds of segmentation (e.g. keeping your database data on a different partition) might also be useful. Our servers generally include a notification tool for when space gets low, but if your backups run at 3am and there’s no sign of trouble until then, it wouldn’t save you in this circumstance.
Regards,
Alec Smecher
Public Knowledge Project Team
Thank you very much for your help.
Things appear to be stable after the cache cleaning.
We checked the database and all seems OK.
We will take care in order to avoid disk space incidents on the future.