A small structure

script2.sh.log (1.6 KB)

I’m new here, but I wanted to share my scenario and who knows how to get ideas to improve, today I set up a small structure that consists of two servers, one is where the bluecherry is installed that is receiving the images from my IP cameras and the other is a on the X86 I built using a 7th gen core i7 with 16gb ram and 4tb raid disk.
the NAS shares a folder with bluecherry to store the recordings, so the bluecherry server only receives and sends to the NAS.
As the days go by the storage fills up, so I had the idea of creating a bash script, it tracks large files and converts them using ffmpeg, at first it works fine. I will share this script here in the post.

the script is run directly on the NAS so it doesn’t interfere with bluecherry’s performance :slight_smile:

any idea how to make this scheme scalable, up to 150 cameras?

I have not looked at your script yet, but thought to share some thoughts to think about with your server and NAS setup.
I can’t remember off the top of my head if it was 32 or 64 cameras per DVR server. Maybe Curtis can enlighten us on what they feel might be the limit or for that matter how many cameras one server can effectively handle. I assume as long as you have the license for them you can keep adding cameras to the DVR server. With the power of multi core CPUs I would assume dual 12 core servers or dual 24 core servers with enough ram could easily do a very high number of cameras on one server.

Network bandwidth and disk I/O I would think would be more critical factor. Linux will let you bond 2 or more Ethernet ports as one so say you could bond four 1 gig Ethernet ports for a 4 gig pipe at the server and then I assume at the 2nd server acting as the NAS / file server. I run Cisco 3750X switches, can be bout very reasonable and I buy the 10 gig uplink modules for them and I run 10 gig network on my key servers as well as for my network backbone between the switch stack in the basement to the switch stack in my office / computer room. All my cameras connect to the same switch in the basement switch stack and then the “camera switch” has a 10 gig uplink to the ESXI VM server, as well as the two stacks have their own 10 gig uplink between them. So additional factors you might want to look at is network bandwidth between the DVR server and the NAS.

Also Disk I/O is something to consider. Now you can if needed build multiple DVR servers and buy camera licenses to put on each server to give you the camera count and the balancing out the CPU load between 2 or more servers, depending on how you built the server hardware. So in the NAS you will have a potential Network bottleneck and or disk I/O bottleneck. Just depends on how many cameras you are using at the time and if set for motion detect or continuous record.

You said you have RAID on your NAS. Best speed / disk I/O response is running RAID 0, striping. But no fault tolerance, loose 1 drive loose everything. So then maybe RAID 5, or 6 or some other combination and maybe even have a online spare drive designated. (I am talking of using hardware RAID controllers, software raid can be done but puts a little more overhead on the main CPU) If you can afford it, if you are not already running Hardware RAID controller, to look at that down the road.

Years ago when I started to learn and work with VMware and looking to have best disk I/O performance, for the VMs with running on a large data store, they say more platters the better as in more hard disks in the array or RAID volume the better. But more disks in the array also increases the chances of more disks to fail. So its a balancing act.

I will have to look at your script because I might do what you are doing using a NAS. My DVR is virtual on ESXi 7. I have a VM DVR with 2TB for disk and I run continuous record on all cameras. Currently running 18 cameras. Assuming your DVR server had the CPU and Memory requirements to run 64 to 124 cameras, and the recording storage is external on a NAS server, I would look at your network connection(s) and see if you want to bond 4 or more 1gig Ethernet ports or look at 10 Gig Ethernet. If you don’t have resources for a small 10 gig network switch, you can create a Ethernet Crossover cable and static set I.P. addresses on the DVR and NAS and you should be able to with just a crossover cable link 2 servers together with the 10 gig NICs.

Next if using software RAID in the NAS, maybe look at hardware RAID disk controller, if not already using one. Your setup sounds very interesting. Also if down the road you have to use multiple DVR servers and they connect to the NAS server, that might be an easier way to scale up camera count. I assume then on the NAS you will have separate directory structures for each DVR server and all DVR servers just map the NAS and their specific mount point or file share folder. I have about 3 days storage retention, before the oldest ones drop off or are overwritten by the DVR system. Long term retention is not needed, so no need to convert or try to shrink my recordings.

I hope this might give you some ideas to think about that maybe you might not have thought of.
Assuming Camera server can handle all your cameras and NAS server has no disk I/O concerns at this time I would look at your Network connection as a possible area to improve on. Bonded ports also help should one port or Ethernet connection go bad, it does not kill your recording. So you might want to Bond a couple Ethernet ports for fault tolerance. DVR and cameras no good if it can’t save the recordings to disk. So if using just one Ethernet connection for the server and the DVR, you might want to think about bonding Ethernet ports on both the DVR server and NAS.

If I remember right the DVR system once it reaches the set limit of recording disk storage if will purge or overwrite the oldest recordings. So I guess depending on how long you want to keep recordings, I can see / understand why you want to track and convert large files.

I hope others will be able to give you the answer you are looking for. Hopefully I have given you some other areas of your configuration to look at for things maybe down the road to maybe implement.