When people think of an IP security network, storage is usually one of the last things considered – but can also be one of the biggest investments. Sure, high-definition cameras with WDR and infra red filters can provide extraordinarily sharp images and a multitude of features that will enhance any organisation’s security mission, but for all that clarity and flexibility of vision, there comes the increased need to store much larger amounts of data.

Furthermore, as other components of a security network evolve, there is more and more that can be done with that data. Think of analytics being able to map pedestrian traffic in a loading dock, and establish the optimal paths for employees to travel for speed and safety; or Facial Recognition (FR) recognising individual employees as they enter a secure area at an airport, and instantly flagging anyone who does not have the correct credentials to enter that part of the premises. Again – great features that can provide a wealth of benefits to any security ecosystem, but all that video data needs to be stored somewhere.

Depending on the camera’s resolution, plus the frame-rate to which it is set, any given camera on the network might be running at 5 Mbps and possibly producing the need to store as much as 60 and 400 GB of data in a month. If that security network is at, say, an international airport, that is a whole lot of data to be moved across the network and stored.

So, the last thing you want is an unexplained spike in data storage. However, there are plenty of reasons for a camera to suddenly run at a much higher data rate than it used to. Take a recent example – a network of both indoor and outdoor cameras, from a range of vendors, monitoring a section of an airport in the US. Suspecting that there was a spike in data usage, the administrators used their Boring Toolbox to isolate cameras in each section of the network, and instantly pull up their data use. This allowed them to quickly see that three outdoor cameras in the same area were consuming about five times the storage that they ought to be.

Using the Toolbox’s hardware details view to check the three cameras, it was quickly established that a family of spiders had decided to set up their home in each of the camera lens housings…which of course tricked Milestone VMS into recording a higher level of motion causing the cameras to consume more storage that it should normally.  A technician was dispatch and the issue was resolved.

While it is possible to pull up individual cameras on a VMS and see how much data they’re producing, the sheer scope of checking each camera individually is daunting and rarely gets done.  Using Boring Toolbox and its camera storage tile on the dashboard this was identified within seconds.

To find out how you can visualize your storage, say hi!