Member Discussion

Milestone VMS Live / Archive Databases

Milestone has live and archive databases. Do other VMSes?

What are the pros and cons of it?

Live DB is always on risk (which is most critical last few hrs video) hence milestone recommend RAID 0+1 for Live DB

What does that mean "on risk"? What exactly is the risk angle versus being written to disk with the rest of video. I'm always been curious myself about the concept of this "staging area" for video before it's put with the rest of recorded video.

By association, ONSSI also has the LiveDB.

The key physical aspect of those drives is the combo high RPM plus SAS reliability (this can be agrued if using Enterprise class drives like we do).

The performance increase result comes from being able to write quicker to the space. Making the space RAID10 will get you max performance.

I have verified the effectiveness of this design setup in my lab many times. The other key thing one has to do is to match up the SIZE of the LiveDB array with the Time it takes to actually perform the Archiving function and the overall camera input rate.

For example, comparing to a regular VMS that does NOT do this (or anything else special to storage), one has the potential to see a nearly 150% recording factor with a LiveDB and local DAS Archiving for the Corporate code level (which is the most efficient). Even with the lower code level there is a similar factor for throughputs rates below 300Mbits.

A key thing to be aware of is thay you MUST define an archiving schedule that will prevent the LiveDB drive from getting full. If you do not get this right, your performance will be miserable because the system will not be able to 'auto clean up' faster than the new camera data comes in.

Mike, what happens if you only have 1 database instead of live + archived ones? There's a performance decrease? How?

This bears emphasis:

"A key thing to be aware of is that you MUST define an archiving schedule that will prevent the LiveDB drive from getting full. If you do not get this right, your performance will be miserable because the system will not be able to 'auto clean up' faster than the new camera data comes in."

And then you lose video because it does not get recorded. :(


Mike, I appreciate the detailed information and trust your lab results. But what's still curious for me, is if, for example, let's say a system has 1TB of live storage drive space and 29TB of iSCSI storage. How is it more efficient to write 1TB of data to a drive, then move that data to iSCSI storage (meaning the incoming video data is written a second time), versus writing all incoming data once to the iSCSI storage unit?

Even if the Live Database drive is faster than the iSCSI connection, aren't you still bottlenecked since data has to go through the iSCSI connection eventually anyways?

1. Why RAID 0+1 : Coz this data is critical last few hrs and hence must be protected from disk damage, it may not be able to retrive if got corrupted.

2. Why 15K RPM SAS : to get fastested possible speed to transfer this data into "Archives"

since the Live DB shall be first written on these drives, then "buffered" and finally "Write" on "Archive" DB...... which means these Drives have to handle the same Data 3 times, (2 Write and 1 Read operation)

3. Disk shall also be formatted with NTFS & highest possible "Allocation Unit Size" (typically 64K).

4. What is Risk : there are chances of getting this DB corrupt hence has to be transfer to Archive DB ASAP. hence Schedule to transfer this DB shall be set as low as possible (typically 1 hr). to match the available SAS drive size and this schedule, typically for 20 cameras , 1 SAS drive shall be allocated.

5. What does some of the other VMS do : - Send DB directly to "Archivers" may not have such risk. provided VMS have machanism to read and reindex such "Archived" DB (if at all got corrupted)

"Coz this data is critical last few hrs and hence must be protected from disk damage, it may not be able to retrive if got corrupted."

What if you simply have redundancy for all your recordings? Then you are protected from disk damage without implementing 2 databases and the need to transfer across them, yes/no?

My understanding of the live/archive database configuration (admittedly, from other manufacturers) is that it most certainly does not increase performance. Logically, I'm not sure how it would.

At some point, the video written to the live DB will have to be read and rewritten to the archive DB, meaning the live drive will be doing double duty during that time period, with more load on the machine as it's reading and writing instead of simply writing in the first place. Sure, I can see that being less of a problem with SAS drives, but you could avoid it altogether just by writing to one database.

Here is a link to a white paper that Milestone wrote about how their storage model has improved with it latest versions. It also answers many of the questions posted so far.

Or do a search for 'Milestone storage architecture'.

Here is a sentence that may be the most important one.... Archives become 'sequential' data. The LiveDB structure is NOT sequential due to its nature.

"Once the recordings are stored on the live disks, they can be archived one database at a
time to the archive disks. This way provides better disk performance as the archive
writings now are sequential (one camera at a time), and if the disks are busy for a second
or two, the data is not lost because it is stored in the live database until all of it has been

Another key element of having an Archive space.....even if it is stored on the same large array... it is able to be backed up easily. This is not true of the LiveDB itself.

The tricky part of the iSCSI is the variability of the storage target itself as well as the network it it installed on. The LiveDB serves as a cache buffer to accomodate this variability.


I am still not clear why live + archive is better than a single VMS database.

Of the above, the one proposed advantage is:

"if the disks are busy for a second or two, the data is not lost because it is stored in the live database until all of it has been archived"

For this to be a competitive advantage, other VMSes (with a single database approach) would need to regularly lose data. Is that what is being contended as the main advantage?

From the Milestone whitepaper, there is another major claim:

"The storage recommendation for a typical Milestone XProtect Corporate surveillance
system with archiving is to use SCSI or SAS disk technology for the ‘Live’ disks because
they offer a good non-sequential write performance and mechanical endurance, and to use
larger, relatively inexpensive server class SATA disks for the Archive disks."

This begs the question: Do other VMSes require all SCSI or SAS drives? Does Milestone's multi-database architecture enable it to reduce storage costs over their competitors? Does Milestone or anyone else have any proof of this compared to Genetec, Exacq, etc.?


In general, I can say that for a given CPU/RAM combo and a common SATA storage with the addition of the SAS-high rpm a pure DAS setup for all storage arrays.... that I can achieve a higher throughput with the Milestone solution.

There is one exception VMS where the programmers did something very unique with their storage pipeline, that will always do better than any other VMS (well...the ones I have been able to test anyway). The main thing for this VMS is thet they do NOT use SQL to handle the metadata/video data.

"I can achieve a higher throughput with the Milestone solution."

How much higher? When does this become significant? I presume if someone has 20Mb/s of throughput on a modern machine, it won't make a difference, but, at what throughput level is it material?


A very good question.

Indeed for the lower throuput values, you do not need this LiveDB at all. We build out our 200Mbit systems with LiveDB.... our 100 Mbit ones do NOT include it.

The amount of playback video being used is a factor. When the Archive is on the same array as the WILL archive faster since it does not have to move the data, but it will cause more interference with the new video being stored because both pipes want to access the same array and the data itself is not sequential.

A recent test of this mode went from 394 Mbits to 467Mbits all else being equal...on Corporate.

The other way to look at this is how many spindles of 7200 RPM drives will let me avoid needing high RPM drives. The suggested ratio I see from another tool is 4 to 1 for rates above 150Mbits.

Given the date of the paper, 2011, and the contents, my impression it may have been a nice idea at the time, and may help if the recording server is writing to a SAN where traffic caused by other servers may adversely affect throughput levels, whereby the "Live" database would act as an additional buffer to system memory. But I'd think it's otherwise superseded by the availability of larger system memory and faster disk drives. If the systems database engine is not code bloated and the structure written well enough, a system should have enough memory for fast enough indexing for video retrieval, which is the only real benefit I gleaned from the paper which was to reduce file fragmentation.

Now that's only my amateur opinion. I am neither a database developer nor programmer.

Luis, my understanding is that this architecture was originally developed 10 to 15 years ago. At that time, this might have really solved a practical problem. Presumably, Milestone had a good technical reason to implement it when they started. What is not clear to me is whether it is still valuable / useful / appropriate given today's state of technology.

The sales pitch for Milestone is that you can use fast drives for incoming video feed and less expensive drives for long term storage, however with the Corporate software you can if you wish record to one database.

The idea is that the fast drives will handle a huge load and the video will be procesed for motion, once this happens and the amount of incoming data has been reduced it is then moved to a more organised structure on an Archive database. Video on archive disks is then failry static untill someone wishes to review some footage.

We have seen a Raid 10 disk array with high speed SAS drives can handle significant amount of cameras and that a raid 6 array is reliable for long term storage so it is possible that Milestones Live and Archive database has some merit.

DB: doesn’t that refer to the Data Base (SQL usualy)?

While the video records are the video files.

The first is usually measured in GBs while the other depends on the number of cameras and storage duration etc... which could reach up to PBs.

On the subject of SAS vs SATA and recording to the final destination VS temp recording and then shifting:

A SATA based ISCSI storage could reach to more than 400MB/Sec. So, improved performance of SAS over SATA would be noticed in cases of extreme throughput/bandwidth with other factors in play such as RAID controller and others.

The question is what is the ability of the the VMS to handle such a load on a single server. And in case of multiple servers, you will probably require a second storage to contain the growing video files' size, so another 400MB/Sec.

I would doubt the storage or the drives being the bottle neck, i believe it’s still the OS/VMS.


This is my personal experience with live DB and archive DB. If you didn't use the live DB and the system/service crashes for any reason then the milestone service will not be started unless it checks the database to ensure the consistency and by the way it is a property file format as far as I know. So if you have couple of TB of data then it may take hours before starting the service. Long time ago Milestone made some modification and tricks to overcome/eliminate this behavior but this didn't work with me at that time. I don't know where they are standing now in this regard but I didn't buy what they are saying about performance enhancement by doing so. Also, this will make you take into consideration another factor in sizing the servers whether the internal hard drives / RAID controller will be capable or writing to the live DB and simultaneously writing to the archive DB?


Just a curious question, if having a Live DB and then archiving why not use SSD drives for the Live DB?


A reasonable consideration however there are is huge technical hurdle for SSD as a storage target for ANY VMS.... the constant writing will wear them out much quicker than what would be desired for a high cost component.

So one would have to over provision the amount of SSD storage to account for the excessive wear or be in a application where the drives are removable/replaceable (like in our mobile XNVRs).

From a performance perspective..they run great and have many favorable environmental properties (temperature and vibration).

I think it was developed when MJPEG was the major compression method and the idea was to have 25fps live DB and say 6fps archive DB. As H.264 is not scalable, there is no way for this. Another option to use archive db is when it is located on the network storage and connection is not reliable. Then it is good to record locally first and then move to the network drive when it is possible. So, I see only this 2 options. There is no any other reason to have two db with the same data on the same server.

do you have to even use the archive db? what happens if you tell it you archive every ten years or something? does it slow down?

It's a nice niche feature for use in mobile surveillance in busses, and vehicles in that the local vehicle server can contain the days recordings and then archive it off the vehicle when it returns to the lot via a wireless network to a SAN/etc. Although now a days several other vms have similar features available.