We have an Omeka project hosted on university servers. The particular server the project lives on was compromised by hackers and used in a DDOS attack at the end of 2015. Campus IT identified the attack, fixed the server-side security vulnerability, and backed up all directories. After that, they wiped the server clean, assigned us a new one, and we got Omeka back up and running on it.
Here's our problem: when campus IT backed up the directories, they did not export the databases as .sql files. I also had failed to make such a backup beforehand. As such, my Omeka project currently has all its data (i.e., all of the images and items), but there's no structure, and lost metadata.
I suspect I'm just out of luck here, but here's a shot in the dark: I'm positive that I'll need to recreate the collections and reupload items manually, but I'm just curious if the metadata that existed with the items existed outside of the database. That is, might it be somewhere in the directory, even as a hidden file, or embedded somewhere else? Or will I just have to go through the tedious process of manually recovering all of this information?
I'm pretty sure I know the answer to this, I just figured I'd give a shot in the dark question.
As I think you're probably guessing, Omeka only stores Item/File/Collection metadata in the database. If there's no backup that you or your IT made, then there's in all likelihood no file containing that information.
Are you certain they don't have any backup at all of the database? It would be pretty unexpected to back up all the files but just wipe databases with no recourse.
Another hopeful, shot in the dark option -- since the site is still there, they must have had _some_ copy of the database that they restored. Otherwise, you would have been asked to install Omeka all over again. Perhaps they restored from an old backup of the database, but not from their most recent backup?
I was able to track down a copy of the database--an older one, but one that works, nevertheless.
Here's my issue right now. I upload the .sql file to the server. Here what I run at the command line:
$mysql -u NAME -p DATABASE < database.sql
Everything looks fine and dandy. However, when I go to my omeka instance, it's empty. My files are all in the [omeka]/files folder. Ideas? Should I just go through the manual "upgrading Omeka" process, and see what happens then? Or is there some mysql-fu that needs to be done?
Actually, I lied. I just ran that command again, and I get:
ERROR 1062 (23000) at line 46: Duplicate entry '1' for key 'PRIMARY'
http://pastebin.com/vh7rbxqZ is line 46 and the lines beneath it.
Thanks for any help!
There might be some mysql-fu involved, depending on the details of what's already in the database, and what the copy of the database provides.
From what you've said, this doesn't surprise me. It sounded like minimal existence of items and collections were still there before this try. The errors look like they come from trying to create duplicate entries for items and collections.
The missing data -- the metadata -- would be in different database tables (
So, you could dig through that .sql file you got any try importing table by table to avoid the duplication.
Or, you could try completely emptying the database you have and import the .sql into that empty db. That's a more drastic approach to avoiding the duplication, but might be more straightforward.
In either approach, definitely make a backup of the existing database beforehand.
I backed up the existing database as an .sql. I dropped the database, recreated a new one with the same name, and populated it from the .sql file.
I go to my omeka instance, and am now getting "Public site is unavailable until the upgrade completes." I assume this means things are working, and I'm just in a waiting game (which could take a while, because I had a really large database/omeka store). This the right thinking?
Sounds likely. As long as the upgrade started, you should start seeing results.
It sounds like the database backup was from an earlier version of Omeka, which doesn't match the new files that are there. That's not a surprise. Next check will be how things look after the upgrade takes place. And, to make sure that the upgrade is in process.