1

Recently the wiki I administer in some sense has "crashed" due to a database that seems to be completely lost. Just the database, not the MediaWiki installation, extensions or media. Unfortunately, I didn't make any backups relying on the hosting service capabilities, and the large wiki was full on unique content available worldwide now not being accessible after about ten years of stable work. However, there is still a private mirror of the wiki made about a year or two ago that was used as an experimental playground from time to time. Thus both wikis have diverged history. One more thing that can play the crucial role: I have a Git clone of the wiki created with git-remote-mediawiki a month ago.

Actually I would really like to restore the database, and I have some scenario that probably might help restore at least a partial instance. Here is how I think it could work:

  • Clone the private experimental database so let the only survived database be untouched.
  • In the cloned database, if possible, trim the N last changes to drop all diverged changes (comparing to the lost live database). Is such trimming possible in MediaWiki? (Maybe some of the maintenance scripts?) How big should N be? Actually have no idea yet, probably a sort of "binary search" just reviewing both wikis. Maybe it should be even up to the very first revision if necessary.
  • Clone the git-mediawiki backup to keep the original safe, and change the origin in .git/config so let it point to the private mirror wiki.
  • Push the changes from the git repo to the origin in hope it would restore most pages. As far as I remember, the remote helper does not sync templates, talk pages, user pages and so on. Unfortunately, they seem to be completely unrestorable. Most templates might be restored by memory more or less.

Would it be possible to "trim" the last N changes in MediaWiki to drop the changes in the private mirror in order to restore the pages from the git backup?

|improve this question|||||
2

If you don't mind administrators being able to access those changes, the easiest is to revision-delete them: https://www.mediawiki.org/wiki/Help:RevisionDelete https://www.mediawiki.org/w/api.php?action=help&modules=revisiondelete

If you are looking for a simple solution, you could try dropping entries from the revision table in the database (probably makes more sense to use a cutoff timestamp than last N entries) and fixing the page table so that page_latest points to the last remaining revision for that page. No guarantee this won't break your wiki though.

|improve this answer|||||
  • I'd like to use the second way, but I'm afraid of making a sort of surgery over the wiki not knowing the exact db tables model and leaving some junk data behind. However, thank you for the tip. – Lyubomyr Shaydariv Feb 22 '16 at 7:23
  • It will definitively leave junk data behind, but nothing critical, I think. If you want to do it cleanly, you should use revision deletion. – Tgr Feb 22 '16 at 8:26
  • hm, but doesn't it just hide revisions rather than making a physical cut off revisions for entire wiki? – Lyubomyr Shaydariv Feb 22 '16 at 9:18
  • It does. Is that difference relevant? MediaWiki has no concept of permanent deletion, making sure everything is undoable is a key concept of the wiki model. Extensions have been created for that purpose (e.g. DeletePagesForGood), but I don't know of any that works per-revision instead of per-page. – Tgr Feb 22 '16 at 10:06
  • 1
    Deleted revisions are not visible in the history or anywhere else unless you have administrator permissions. Anyway if you really want to physically delete, you can run deleteRevision.php and then deleteArchivedRevisions.php. – Tgr Feb 22 '16 at 10:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.