mysql backup may be missing some resources in the filestore

[Allison Stec]

Last night it seems my db was thrown out of whack when a backup failed.

I have a mysql backup from early monday morning that i may need to use to bring a system back up. However, staticsync was run during the day monday and now the filestore contains resources not in the backup.

What sort of problems will I run into? Is there anything I can do to bring the db back inline with the filestore?

Thanks,

~Allison

[David Dwiggins]

You might be able to use my recover.php script (in the tools folder) to recover the new resources into a new database, and then use some SQL dump wizardry to copy the resource and resource_data records back into your backed up database.

You would want to set the $start_id to be one more than the greatest resource you have in your backup.

Come to think of it, you might even be able to run this against your existing (restored) database as long as you set the start ID to be higher than the highest resource in the system, and don't add anything else while it's running. 

This works by reading metadata out of the XML files on disk and repopulating it into the database.

It would be possible to craft a more elegant solution to this, but I'm not sure there's enough demand to warrant the work. However, let me know if you want to discuss.

-David

--
 
 

[Allison Stec]

thanks david.

i'm in the process of trying to fix the current db. I'm also working on restoring the backup copy as well.

I'll try your second suggestion first (running recover.php on the restored db and setting the start ID accordingly).

thanks again

--
 
 

[Allison Stec]

I'm getting an error with recover.php on line 140: "undefined variable: fields_title"

[David Dwiggins]

I'm not 100% sure if this is the source of the problem, but I think my instructions before were a bit too simplistic...

This script is designed to copy stuff from an old filestore (where the scramble key is unknown) to a new one with a new scramble key.

So for it to work in you situation, you would need to move the relevant portion of your filestore over to a parallel filestore, and then fill in 

$source_filestore_path = '/path/to/old/filestore';

at the top of the script, along with the starting ID. 

then you would run it, and it would go through the old filestore ID by ID starting whereever you tell it to, move the files into the new filestore, and enter their metadata into the database.

This may be the source of the error you're getting. If not, there could be some other bug. (I do know that this script has worked for me in testing, and has worked for two other people who had lost their scramble keys. So in general I think it is functional.)

Sorry this is a bit complex. The script could definitely be revised to work more cleanly in your specific use case. But I think it could be made to work as is if needed.

-David

--
 
 

[Carsten Hülsmann]

Dear David,

i have the same problem now. Could you explain what i can do?
I've set up a fresh install of RS and got an old filebase but not the scramble key.

I wrote the path to it in the config but only get that error message.

This is what i wrote into it:

$source_filestore_path = '/mediabase/test';

I already tested a full link to the folder "filebase" same error.
Have i to copy the filebase into the structure of the fresh installation of RS?

Kind Regards
Carsten

[Andrew Lent]

I am currently getting the same recover.php on line 140: "undefined variable: fields_title" error. Did you find a solution?