Milestone Recording Method

I could be mistaken, but I do not believe Milestone truly records TO a database.  There are certainly user settings and other items captured in the database.  However, I do believe Milestone indexes the recorded video files information into SQL.  From what I have seen it does an excellent job of repairing that index if anyone shuts down the server unexpectedly, particularly on newer version.  The only database issues I have ever had is when someone sets it to record to the OS drive (C:) with no limit and the SQL server can no longer write to the drive.  Don't do this!

Our media database is implemented in such a way that our Recording Server is essentially a database server itself. We do not use SQL or any other commercial/open source database software for storing or indexing media data. The Recording Server stores the media in the database which is persisted to disk in .PIC or .BLK files, with some mix of index/metadata files to accompany them.

It is definitely possible for corruption to occur and for that to result in some downtime while the data is reindex/repaired. This can happen if the power is lost, if the storage fails in some way, if the OS blue screens or the software crashes unexpectedly. Power loss is the most common failure causing problems like this.

However it happens, there are various ways to mitigate/minimize downtime. First, if you're running XProtect Corporate or XProtect Expert, and you're not archiving, you can speed up the rebuild process by having a live database for a few hours of data and an archive drive for the rest. When the live database is rebuilt/reindexed, we can start recording to it and rebuild the archive index in the background. With less data in the live database, the reindex should be fairly quick.

If uptime is critical, a failover server should be used. The failover Recording Server will kick in if the Recording Server is down.

If those seconds of video potentially lost during Failover startup is not acceptable, edge storage should help here. With edge storage enabled, we'll fill in the gap in the database between the last received frame and the next image received from the camera with whatever is stored onboard the camera.

I don't have the actual statistics for you but my feeling is (one of) the #1 cause of database reindexing/repair is power failure. Where recording is critical and not simply a "nice to have", it's important to have a UPS in place.

Often times customers will tell us it's imperative to get a server online and they can't wait for a rebuild of the index, but when asked if they have a failover server in place the answer ends up being "nope". It's a shame when the design/implementation of a system doesn't match the expectations and level of importance of the data. Sometimes this happens to minimize cost, sometimes it's an education thing and the people involved simply weren't aware of their options.

With regard to the strategies used to store/index the media data, there are already a lot of ideas internally about how to further improve the database resiliency to hasten or even minimize/eliminate the need for rebuilding after power loss for example. There are various trade-offs with different strategies, and we're always open to suggestions. As of today, if a rebuild is required, it is usually relatively quick (relative to the amount of data to index), and the use of Failover Servers will greatly minimize any impact to users.