ZoneMinder Forums

If the database if corrupted or otherwise lost beyond recovery it would be very useful to be able to recreate the Events table from the events stored in the filesystem.
Config and Monitor info can be easily backed up, or reentered manually if needed. But several gigabytes of events with no ability to run filters on it is not quite useless, but far less useful than if it could be reloaded into the database.

How about leaving a copy of the sql statements that initially create the database entry in a .sql file in each event directory. Then a recovery utility could "walk" the filesystem and reload the database by executing the sql files in each directory.

It is worth thinking about. It would not be possible to directly recreate the events details from the image files, as precise timing and scores etc would be missing. Also there is always the likelihood of zmaudit coming along and deleting the files if the Db entry is wrong.

I think perhaps a summary file would be the best way, a bit like your SQL idea but in a more general format. The disadvantage of this is continuous file writes during event creation which might slow down general operation unless it is an option.

I will have a think

The disadvantage of this is continuous file writes during event creation which might slow down general operation unless it is an option.

How about having it as a filter option?

Yes, that is possible. You could do most of this at the moment by creating a small script to 'mysqldump' the SQL into a .dump file in each event directory. That doesn't cover restoration of course but provided zmaudit hasn't wiped the files you could run a 'find' on .dump files and restore that way.

Not a bad idea actually.

OK I have a shell script that works from a filter. I'll post it in the Contributions forum.

During a db recovery zm would not be running, only mysql needed, so zmaudit should not be a problem.

I'll post a recovery utility script soon.

Do I understand correctly that only one "execute command" filter can be used on each event? If so it would be nice to have this function as a "built in" so as to free up the "execute command" for other functions.

Yes, only one execute command per filter, though you can have a master script that calls other ones. However I think perhaps having a backup function might be possible as a builtin function as you suggest.