Keeping Your Archive Safe

They say, there are two types of people. Those who do backups, and those who will do. Some people learn it the hard way. Why not take some extra care about your precious data?

Everyone knows data redundancy is essential. Speaking of CCTV systems, the first thing you think of is the archive the recorded video, audio, and other data streams. Unlike the configuration backup, there is no way of simply copying and pasting it onto a USB stick; rather, it is a continuous process. Extra portions of data keep on arriving and, at some point, you start thinking of dedicating someone to keep an eye on it. Or, maybe, entrust the business to the automation?

We have an ace up our sleeve. Ladies and gentlemen, we present for your enjoyment, EVO Global archive replication.

Similarly to the database replication a phrase you have probably heard more often  replication in EVO can copy your archive to one or several additional locations. Set up once, the process:

  • is fully automatic
  • does not involve extra license costs already included in your EVO Global license
  • scans up to 30 days from the past
  • detects the target storage availability so that the connection to it may be intermittent
  • can be scheduled and limited to specific hours

Replication can serve different purposes. Whether you simply need an automated backup, or a buffer server, or a cloud storage, - we have got you covered. Learn how you can replicate your data quickly and easily.

A Copy In the Cloud

Thanks to the evolving smart technologies and growing customer demands, we are facing a rapid development of CCTV. The surveillance systems are becoming larger, and, as a result, more complicated. At the same time, this means such systems are more prone to threat as they have more potential points of failure. Fortunately, there are cloud-like solutions to the rescue.

An extra backup in a secure location is your disaster insurance. Storage crashed? A malevolent virus encrypted the data? Hard disks stolen? No worries if there is an extra copy.

With EVO Global, you can create duplicates of the archive or its parts for enhanced reliability and fault tolerance. The total number of replicas is not limited: replication channels are not accounted for by the license. This means, replicas are not included into the total number of channels limited by the license, as these are not real channels but rather copies of the original streams. Feel free to copy the important data several times on multiple nodes, if necessary: it is better to be safe than sorry.

Channels can be replicated to multiple different locations, including the cloud

Channels can be replicated to multiple different locations, including the cloud

EVO Global, with its unlimited recording servers policy, gives you total freedom with the replication scheme. One way to do it is to combine regular recordings with replication channels from other servers. But practice shows that a better idea is to create dedicated replication servers. These servers can then serve as backup servers, or as a local copy for enhanced availability.

Although you will not find such server role in the settings alike the failover node we presume that a "replication server" is a recording server that only has replication devices assigned to it. There is no need for the replication server to access the live streams. Therefore, you can put such servers virtually anywhere, simply providing a connection to the source recording server.

Endless Possibilities

Enough theory. What does it look like when you apply replication in real life? Here are a few examples for you.

Use case #1. Several main recording servers are located in different offices, branches or stores. EVO replicates all channels to a secure centralized location. The backup job only runs during the night time so that the transmission channel is not overloaded during the day.

Use case #2. A fleet. Ambulance, police, or trucks you name it. Each vehicle has a tiny recording server with a limited local storage just enough for a couple of days' recordings of 1-4 cameras. When the vehicle returns to the station, it connects to the central server via WiFi; the recordings are then copied to the main storage, where they can be kept for several months.

Use case #3. The main recording server with all cameras belongs to an isolated environment. Due to security requirements, it is not accessible directly from the client workstations. Yet, there is a need to view the footage. A replication server is then placed on the client side, and then everyone is granted access to this server instead of the main one.

Use case #4. Same kind of an isolated environment. The connection between the sites is expensive and therefore has limited bandwidth. There is a need to review the recordings repeatedly, which poses a problem. A replication server is placed on the client side, and then everyone is granted access to this server over the local network with minimum transmission cost. Only the secondary streams are replicated and kept for a month on the replication server; their lifetime on the original server may be only one or two days to save the recording space.

Streams are replicated and then accessed locally from EVO Monitor workstations

Streams are replicated and then accessed locally from EVO Monitor workstations

Follow the Plan

A bit of preliminary setup and then you are ready to create your replicas with a single click! Let us assume you already have the things listed below ready in your EVO Global system:

  • a recording server with some devices attached to it, their channels set to record continuously or based on alerts,
  • an empty recording server to be used as a replication server,
  • storage configuration (quotas, labels) applied to both servers.

One more preparatory step is to create the required recording profiles and configurations. You can either stick to using the built-in profiles or create your own profiles and configurations. If you need the data to be copied during specific time only (e.g., only copy during the night time when the network load is lower), use schedules and combine continuous recording periods with the "no recording" profile.

Configuration in Console

Once everything is ready, open the Configuration > Channels section of EVO Console. In the list of channels, select one or multiple items and then click the Create replication button from the top panel. Voila! The replica will appear in the list next to its source channel, with its name copied from the source channel and marked as [Replication]. Double-click your newly created replication channel to open it for editing.

The replica is similar to regular cameras. It consists of a device and a channel attached to it. Right after its "birth", the replication device is not attached to any server so this is what you need to do next. Tip: you can quickly switch to the related device edit dialog box by clicking the Related items button in the bottom left corner.

Set the desired recording plan for each replica

Set the desired recording plan for each replica

So, the only thing you need to change in the replication device configuration is the destination server. Then just click OK to close the dialog box and go back to the channel settings: here, set your desired recording configuration for the main and/or secondary stream. If the replica is to be recorded onto a non-default storage, specify the target storage as well. Finally, click OK to save and initiate the replication process.

What Are the Signs?

A logical question is: how do you make sure everything is fine?

EVO Console has the Monitoring section that allows you to track the state of the system components. There are several subsections here that will inform you about the replication process.

  • Under Devices, the item status must be Normal, with the server name displayed in the corresponding column. The status may be different during the first few minutes right after the server start. If the server is down, the status will be Unknown and the server will also have a warning in the Servers subsection.
  • Under Channels, the status will be the same. All replication channels will have a No video mark in the Video loss duration column: this is expected behavior as replicas do not have a live video stream. Respectively, stream properties will be empty, too. What you need here is the Recording column: it must say Activated. If it does not, it means that either the replica does not have recording enabled, or there is no data in the source channel. This can happen when there is no video from the camera or recording is inactive for the source channel.
  • Active recording tasks are displayed under Streams. Each stream (main, secondary, audio, ...) appears as a separate item. This is also where you can track the destination storage.
  • Finally, Archive statistics show what data have been recorded. Double-click any entry to view the more detailed information.

If You Want More

After EVO has started the replication job, you will be able to access the recordings in EVO Monitor just in the same way as for the regular archive. The replicated tracks will show up in playback mode alongside with the regular archive data. Each of them will have the [Replication] mark in its name; the rest of the playback is exactly the same as for the regular footage.

Replicas can be played back just like the original streams

Replicas can be played back just like the original streams

Finally: do you need to be informed when something goes wrong? Luxriot EVO Event & Action Manager has a number of important server events built in. Spend some extra time and set up email notifications for the recordings errors, storage failure, or server disconnection.

Non-Stop Backup

Do not rush to your EVO Console yet... A few important things we want you to know before you begin the setup.

Replication is an enterprise feature developed for EVO Global. Accordingly, the replication server requires connection to the central server to operate. If you feel there is a chance that the Global server may not be available at times, use a mirroring server. It will cover replication, as well as other "global" features, such as failover and video walls.

Less Is More

You can replicate both the main and secondary streams. Hence, although replication does not support changing the stream resolution, you can still choose to get a lower resolution copy. In this way, you gain more storage space for other recordings. By combining this with the frame rate limitation, you get more space for the recordings so you can keep them for longer. Additionally, you can also transfer auxiliary data streams motion, audio, VCA metadata, and textual data delivered by external sources.

Again, if the task is to save the storage space, simply lower the frame rate of the replicated streams: set a frame rate limitation in the recording profile. However, note that the actual FPS of a compressed (h.264, h.265) stream may be lower than expected, as the resulting frame rate depends on the stream keyframe (key interval) setting. Thus, a 10FPS limitation may result in 2-3FPS of actual data. Other modifications of the video streams are not possible, as we copy the streams "as they are". For example, resizing the video stream would require time and hardware resources. Instead, we prioritize the operation speed and use the available bandwidth to transfer the streams faster.

It Matters What You Copy

Replicas are copies of the original streams so they cannot contain more information than the source. For instance, if the original channel has a motion-based recording configuration, and its replication channel is set to continuous recording, the replica will only contain video for the periods when the motion was detected. If you create multiple replicas for a single channel, all of them will use the original footage as a source.

You can use continuous recording and its variations (decreased frame rate, auxiliary streams ON/OFF) for replicas; it is not possible to make replicas based on motion or other types of alerts. Basically, the original (source) data are copied to the specified destination. With the help of schedules, you can limit the hours when the copying is allowed. Thus, schedules define the period when the copying is done (and not the interval of the source archive to be copied).

Once you have activated replication for a specific channel, the replication server "looks back" 30 days into the past and starts copying the data from back then. This means you can start the source channel recording today and take care about the replication server later. And you will still get the same data backed up!

And, if your replication server fails (which we hope not), we have failover to help you :)