Wiki backup question

[Jules Richardson]

Yes, that's part of my concern - that the data might be installed "internally" by the software in some highly-encoded form such that it's difficult to recover from a crash (and these sorts of issues tend to get worse as time goes on).

In the event of some major catastrophe I don't think I'd mind too much if the audit trail of who created/edited what and when was lost - but it'd be nice if the raw article text (and images) could be migrated to a different system relatively easily if it were ever required. I expect some flavours of wiki software handle that aspect better than others.

Tim mentioned "RDBMS and a bunch of files" though, so perhaps it's nice enough to just store the "audit" part in the DB (and how articles link to each other) with the actual data kept seperately as plain-text.

cheers

Jules

[Tim Watts]

Jules Richardson ( [e-mail]) wibbled on Monday 03 January 2011 14:51:

If we assume the Wiki markup format remains stable over time (at least by not changing or deprecating markup tags) then spidering in edit mode, whilst requiring some moderate perl script-fu, would be quite a good method - in that you could backup up an MediaWiki with no more than an edit-capable account.

With some cunning it should be possible to bulk re-populate a blank MediaWiki using the same approach in reverse. It would not be a trivial scripting exercise, but logically it should be sound.

I am surprised (if it is the case) that they don't have an app level backup/restore function that produces version agnostic backups including all media and history. I don't think that would be particularly difficult if you are hooking into the running code and maintaining the backup functionality as part of ongoing development.

It would be harder to manage as an external system for the same reasons.

I wonder if there is an API interface to the system - don't have time to look right now...

[Andy Dingley]

It's the XML. That's the favoured approach for "app level", although the process of generating it can be lumpy, unless you have some extra tools to hand.

It's called HTTP 8-)

[John Rumm]

ok, recap of the backup strategy as it now stands:

The wiki server has the files on a mirrored set of drives.

Grunff has setup a nightly snapshot of the wiki's file structure, and export of its DB, and also a copy of the FAQ.

I am setting up a regular task to grab a copy of that to hold at least one on one of our production servers.

With luck Geoff will hold yet another copy on one of his machines.

So that ought to cover most eventualities.