jetrost's picture

I'm using turnkey mediawiki 1.15.1. I tried installing an extension, and it ran a script which created a blank folder in the mediawiki/extensions directory. The blank folder (it had no name) did not seem to do anything, so I deleted it. Afterwards, when accessing my wiki, it brought me to the "Please set up the wiki first" page. I checked the mediawiki directory, and the mediawiki/extensions folder was no longer in existence. Apparently, when I deleted the blank folder, it had deleted the entire mediawiki/extensions directory and all of its contents. 

This is the point at which I wish there was an "Undo delete" button or a "Recycle Bin" which I could resurrect the deleted directory from, since whatever I did caused my wiki (and all of the articles in it) to be inaccessible. Now, I am trying to find a way to salvage at least the articles somehow.

I had not created a backup or snapshot of the virtual machine or wiki when this incident occurred. Is there any way I can manually get the database files that contain my articles and move them to an unbroken installation? Or any other way I could salvage my information? 

Alon Swartz's picture

It's always a good idea to have backups, and TKLBAM makes it so easy, so I recommend using it in the future.

That said, might I suggest using TKLBAM now to backup your system. Then, launch a new TKL mediawiki server (don't delete the old one just yet), and attempt to restore the backup. Hopefully it will work and you'll have access to your original wiki...

jetrost's picture

I did as you said, but it resulted in the same broken system on the new installation. 

I found a log of the broken system (screenshot following). Is there anything else I could do with this new information to try to salvage my wiki articles somehow?

Jeremy Davis's picture

Perhaps you could try doing in manually.

Export your current database on your old appliance (it's really easy with phpMyAdmin). Then import it into a clean instance (phpMyAdmin again). Then copy the mediawiki folder (as seen in your screenshot) from your old instance across to your new instance and write it over the top of the new filesystem. Either bundle it up with tar.gz or use rsync (so you maintain permissions etc). You may still need to tweak permissions etc a little to get it to work but hopefully it will.

jetrost's picture

How do I use phpMyAdmin? Do I use it in the webmin interface? Or run it from the virtual machine CLI? 

Nevermind, I realized how to find it. I'll give it a try right now.

jetrost's picture

After making a clean install and verifying that it was working, I made a backup of it via TKLBAM. I will call this "backup1". I also made a backup of the broken installation, and called it "backup2".

I restored "backup2" (broken) onto the working clean install, and it proceeded to break the clean install.

After this, via the webmin interface, I chose to "Rollback" to the pre-restore snapshot (which it automatically created), and after that had completed, the clean install was still broken. 

Interestingly, I then restored the initial backup of the clean, working installation to the now-broken clean install with "backup1". This appeared to do nothing, as it was still broken and I could not access the wiki. 

I did notice that in the restore log from the first restoration, it called "rm /var/lib/mediawiki/extensions..." 

Jeremy Davis's picture

If you have a look in the TKLBAM docs,  specifically here, you can do a restore omitting files. You will probably still need to copy across some files (from the old to the new) to get it to work, but it may make it a little easier!? (Although if you've mastered phpMyAdmin by now this probably isn't a huge help - assuming a pretty much default instance of a TKL MediaWiki, the only things that would be diferent are the DB and the filesystem).

Perhaps read through the docs fully and see if there is a way to manually restore and/or edit the commands TKLBAM executes on restore?!

If not then perhaps this is something for the devs to consider documenting (I'm sure it's possibly - just above my pay grade - especially when I don't have a current need to do something such as this).

Another thing that may be worth a try is doing a manual backup to local storage and have a dig through the backup and see what you can see...

jetrost's picture

I was able to salvage the content of the wiki through your previous suggestion by playing around with phpMyAdmin and trying to copy the /.../mediawiki directory. I actually was unable to copy the mediawiki directory from the old system to the new one because of the fact that it had been deleted from the old system. Also, there was a delay in confirming that the phpMyAdmin exports/imports had worked because I assume I had not refreshed/rebooted the proper running service. Thankfully, now I have the content, but not the extra extensions I had installed on the old system. 

On an interesting discovery, I found that simply creating a virtual machine snapshot through VMware Server (or other virutalization software running the virtual machine) is easier and often quicker than using the TKLBAM function.

Anyways, I do appreciate your help Alon and Jeremy. 

Jeremy Davis's picture

Although personally I'd still be inclined to use TKLBAM as IMO multiple points of redundancy is what makes a backup regime successful in a worst case scenario. For example, saving snapshots on the local machine will be fine for inadvertant config problems (such as your recent experience) but won't be much use to in the event of a hard drive failure. Saving snapshots to network storage (such as a NAS or another server/machine) will be great in the the event of local hardware failure, but little use in the case of a building fire, flood or other disaster.

IMO you are best off with having local, network and remote/cloud backups. That way you have all your bases covered and you can restore from the easiest, quickest point. Whilst snapshots are easy to do as a one off, TKLBAM is the winner hands down IMO when it comes to automated backups! And it doesn't matter how easy or quick the process is, odds are if it requires manual human intervention it will be unreliable (ie it will get forgotten).

Although it's now irrelevant as you've basically resolved your problem, but thought I'd share another idea anyway (in case someone else comes across this thread). In your situation the easiest way to go may have been to exclude the the deleted folder from the backup (which would hopefully not re delete it). See the docs here on omitting files/folders

Add new comment