ZoneMinder Wiki - User contributions [en]

Multi Port

2026-03-23T17:18:26Z

Kernelkurtz: Mention iptables compatibility layers

All browsers currently have a limitation where there can only be 6 connections to a server. This can be gotten around by using multi port, or by adjusting a Firefox about:config setting.

==Apache Settings for Multi Port==
This is the optimal approach as it will work on any browser. If you are in a commercial setting, or have other users besides yourself, it is almost required to setup Multi Port through Apache. If on the other hand you are on your own, you may consider simply using Firefox. Multi port, does just what it says: It will redirect multiple server connections through different ports, which is a workaround for the browser security limitation.

Here are some quick configs for 50 cameras. Note: The below config has been confirmed to work with only HTTP. HTTPS may need additional configuration. If you get an error about missing a > bracket on the 000-default.conf, make it so all these _default_:#### are on one line. Then it will work. It's not easy to read it in that format, so it has been justified for viewing here.

====/etc/apache2/sites-available/000-default.conf:====
<pre>
<VirtualHost _default_:80 _default_:30000
_default_:30001 _default_:30002 _default_:30003 _default_:30004
_default_:30005 _default_:30006 _default_:30007 _default_:30008 _default_:30009 _default_:30010
_default_:30011 _default_:30012 _default_:30013 _default_:30014
_default_:30015 _default_:30016 _default_:30017 _default_:30018
_default_:30019 _default_:30020 _default_:30021 _default_:30022
_default_:30023 _default_:30024 _default_:30025 _default_:30026
_default_:30027 _default_:30028 _default_:30029 _default_:30030
_default_:30031 _default_:30032 _default_:30033 _default_:30034
_default_:30035 _default_:30036 _default_:30037 _default_:30038
_default_:30039 _default_:30040 _default_:30041 _default_:30042
_default_:30043 _default_:30044 _default_:30045 _default_:30046
_default_:30047 _default_:30048 _default_:30049 _default_:30050>
</pre>

====/etc/apache2/ports.conf:====
Note:this doesn't include everything in the file. Make sure to insert into the existing ports file where changes are appropriate and not simply clobber the original file with below.
<pre>
Listen 80
Listen 30000
Listen 30001
Listen 30002
Listen 30003
Listen 30004
Listen 30005
Listen 30006
Listen 30007
Listen 30008
Listen 30009
Listen 30010
Listen 30011
Listen 30012
Listen 30013
Listen 30014
Listen 30015
Listen 30016
Listen 30017
Listen 30018
Listen 30019
Listen 30020
Listen 30021
Listen 30022
Listen 30023
Listen 30024
Listen 30025
Listen 30026
Listen 30027
Listen 30028
Listen 30029
Listen 30030
Listen 30031
Listen 30032
Listen 30033
Listen 30034
Listen 30035
Listen 30036
Listen 30037
Listen 30038
Listen 30039
Listen 30040
Listen 30041
Listen 30042
Listen 30043
Listen 30044
Listen 30045
Listen 30046
Listen 30047
Listen 30048
Listen 30049
Listen 30050
</pre>

You will also need to enable multi port in Zoneminder options. Please read the medium guide below for more information.

===Resources===
* https://medium.com/zmninja/multi-port-storage-areas-and-more-d5836a336c93 - A developer of Zoneminder wrote up this helpful guide.

==Firefox About:Config==

In Firefox you can make a change to the configuration to get cameras to display. First go to [https://support.mozilla.org/en-US/kb/about-config-editor-firefox about:config ]. And search for, then adjust [http://kb.mozillazine.org/Network.http.max-persistent-connections-per-server Network.http.max-persistent-connections-per-server]. The max persistent connections per server must be > 6 in order to see > 6 camera streams. It can be set to any number, so perhaps you might set it to 100 or 150.

[[File:Firefox About Config Edit.png|900px|||]]

===Resources===
The forum will have a number of posts regarding this change. It has been discussed extensively. Such as:
* [https://forums.zoneminder.com/viewtopic.php?f=32&t=23417&p=89249 ZM Forums: Problems when two people are watching live]

[[Category:Dummies_Guide]]

==Alternative firewall based method==

If you are unable or prefer not to modify your webserver configuration, you can also use Linux firewall functionality to redirect a range of incoming high ports to the configured webserver listening port. This will work with both Apache and Nginx based Zoneminder installs.

The following rules are are for iptables based firewalls and work on my RHEL and Ubuntu based servers. If you use another firewall or frontend such as nftables, firewalld, ufw, etc., you may have to install a compatibility layer, or otherwise translate them to work with your setup accordingly. AI is very helpful for tasks such as this.

<pre>iptables -t nat -A PREROUTING -p tcp -m multiport --dports 30000:30100 -j REDIRECT --to-ports 443</pre>

If you are running a headless Zoneminder install the above rule is all you will need. Replace 30000:30100 with the range of ports you want to redirect. Of course this has to match the multiport starting port in Zoneminder's network settings. You can also use port 80 as destination if you don't use https, or whatever other port your webserver listens on. You can quickly check it is working by browsing to http(s)://yourzomeminderserver:30099 (or some other redirected port).

If your ZM server has a graphical Linux install and a directly connected display, you will also need some additional configuration to make this work as localhost traffic does not use the same prerouting rules. First you need to enable routing on the localnet network. Only do this if you trust the other devices on your local LAN, don't do this if you connect directly to the internet. Add the following line to /etc/sysctl.conf (or the appropriate location for your distribution).

<pre>net.ipv4.conf.all.route_localnet = 1</pre>

You can apply it immediately with sysctl -p. Then you need to add a second firewall rule to redirect the loopback address ports. Use the same port range and destination port as the previous rule.

<pre>iptables -t nat -I OUTPUT -p tcp -o lo --dport 30000:30100 -j REDIRECT --to-ports 443</pre>

That's it. Be sure to make any rules you add persistent across reboots with whatever firewall management method you are using.

Realtime event backup to cloud storage

2026-02-22T20:27:16Z

Kernelkurtz:

It's possible to use lsync daemon, which leverages the inotify https://en.wikipedia.org/wiki/Inotify kernel subsystem to run triggers based on events in a directory (create, modify, delete). Triggers can be varied (you can run any arbitrary command) but in the default use case, is as a filesystem backup / clone using the rsync command.

You may also want to consider other options. Inotify has command line tools, and there is an incrond, which uses cron syntax to run commands based on inotify.

==About==
After recently migrating from another popular NVR software on Windows to Zoneminder on Linux I started looking for a way to do near-real-time backups of my events to offsite storage, simply as a way to have a copy should the local ZM server be compromised by break-in, fire, etc. Software such as Dropbox, Google Drive, etc. make it relatively easy to do this on Windows but the setup on Linux takes bit more effort.

I wanted to keep it as simple as possible and don't need my backup solution to interface with the ZM database. After experimenting with several other options, I have settled on an application called lsyncd. It runs as a service and leverages inotify and rsync to watch a directory or directories and mirror only new changes to another storage location. Lsyncd should be available as a package for most Linux distributions. I used the installation instructions here for my Rocky Linux system;

https://docs.rockylinux.org/10/guides/backup/mirroring_lsyncd/

Note the version of lsyncd included in EPEL for Rocky 8 (2.2.2-9) has a noticeable memory leak. Building from source solved this issue.

At this point it is worthwhile to at least skim through the docs.

https://lsyncd.github.io/lsyncd/manual/config/file/

https://linux.die.net/man/1/rsync

Both lsyncd and rsync are highly configurable. For many people the use case will be very simple like my own which I will describe here - watch my Zoneminder storage location and copy new files to a remote location, but much more complex configurations are certainly possible. In my case I'll be writing to an Amazon S3 bucket which I have already setup using S3FS-FUSE according to the documentation here;

https://zoneminder.readthedocs.io/en/latest/userguide/options/options_storage.html

You can also use an Rclone mount point as a destination. I've tested this with Google Drive but it should work with any cloud provider supported by Rclone;

https://rclone.org/#providers

Follow the instructions here to set up your cloud storage as a local mountpoint;

https://rclone.org/commands/rclone_mount/

==Setup==

Once lsyncd is installed you will need to create a configuration file in /etc/lsyncd.conf. I've included mine as an example below. Note this file uses Lua syntax, not Bash. Be '''VERY CAREFUL''' if you are testing remote write/sync/copy operations to a destination that already has important data on it (see links below). I highly recommend initial testing with an empty bucket or target filesystem. You have been warned.

<nowiki>settings {

logfile = "/var/log/lsyncd/lsyncd.log",

statusFile = "/var/log/lsyncd/lsyncd-status.log",

statusInterval = 10,

maxProcesses = 1,

insist = true

}

sync {

default.rsync,

source = "/home/Cameras",

target = "/media/aws",

delete = false,

delay = 10,

init = false,

exclude = { '*.jpg' },

rsync = {

archive = true,

ignore_times = true,

inplace = true,

whole_file = true,

prune_empty_dirs = true

}

}</nowiki>

''logfile = '' is pretty self-explanatory. Be sure to set up log rotation after you are done setting lsyncd up, if required. By default the packaged lsyncd service logs to the systemd journal, which also by default echoes to /var/log/messages. Since the application logs are sufficient I've added the 'StandardOutput=null' option to the lsyncd service's unit file to prevent this over-duplication, but I've left StandardError with the existing default logging to the journal.

''maxProcesses = 1'' is the default. If you are syncing multiple sources or targets you may want to increase this.

''insist = true'' allows the service to start even if the target is not ready. According to the docs "In production mode it is recommended to have insist on."

''source = ''The directory where ZM events are stored.

''target = ''The location to copy events to. This will be the mount point for the cloud storage configured previously.

''targetdir = "/somedirectory"'' (not shown, part of sync block) subdirectory to use on the target. I'm just using the root directory in a dedicated bucket. You may not want this and should specify something here.

''delay = ''This is how often rsync will run if there are any filesystem changes. Default is 15 seconds. For many users this will be close enough to real-time for the purpose. This can be combined with (or substituted) for another value in the settings field;

''maxDelay = # '' (not shown, part of settings block) will queue this # of file changes before calling rsync. Between delay and/or maxDelay it is possible to tune the timing of your file copies to your exact preference. inotify waits for write_close to add files to the transfer list so there are no issues with rsync trying to upload uncompleted files. I typically only record short 10 second clips. If you use your cameras to continuously record be aware that files in the process of being written will not be copied until they are closed. It may be further possible to remove this limitation with the inotifyMode directive, though I have not tested this.

''exclude = { '*.jpg' }'' These are generally used by the Zoneminder GUI but are not really needed as standalone files in my case (though some people may save .jpgs on purpose, in which case you will want to remove this line). I'm only interested in having backups of the videos, so not syncing these reduces the number of uploaded files significantly. You can break them out by type '*snapshot*.jpg' , 'alarm.jpg' , '*capture*.jpg' etc., or just exclude them all as shown. Functions like zmNinja's 24 Hour Review may create hundreds of snapshots all at once, which lsyncd will immediately sync, so you can avoid that with these filters. The log snippet below did not include this filter.

''archive = true ''This preserves ownership and permissions on the copied files.

''ignore_times = true'' This sets rsync's --ignore-times directive. For the purpose it is being used here it is safe to assume you will never have a newer copy of the files you are uploading already existing in your destination. Removing this check reduces API calls and is a noticeable optimization for AWS. If your cloud provider does not meter traffic you probably won't notice any difference with this either way.

''inplace = true'' and ''whole_file = true'' Sets these rsync options and are a further optimization for S3 API use efficiency. This makes rsync's functionality less "sync" and more straight "copy", again because we can safely assume only newly created files will ever be transferred. These options used together make this method of backing up events very close in terms of total traffic cost to natively writing to S3 straight from Zoneminder. Once again if your provider does not charge for API calls this will not matter to you.

''prune_empty_dirs = true'' Because they are watched by inotify, rsync will create empty remote directories even for events Zonmeminder deletes locally. If you are not syncing deletes you will want to use this flag, see ''delete'' below.

Two other very important variables in this file are;

''delete = false'' this is also pretty self explanatory, file deletes will not be synced from source to target. In the case of my S3 bucket I have lifecycle rules that handle this. If you prefer for your remote storage location to synchronize the deletions made by Zoneminder you can set this to true. This also means if you accidentally delete events from your local storage they will be deleted from the cloud as well. Use with caution.

''init = false'' causes the lsyncd to not do a complete initial synchronization between source and target on service startup. On S3 this is expensive in terms of API calls and may take a while. I know I'm going to miss some events during system maintenance/OS updates etc anyway so I don't consider this worth the cost, but you can set to true if you want it. Be warned it will make your target an exact mirror of your source.

Having delete and init set to false also should make this config fairly safe to use against an existing target if you just run it on your machine without heeding my previous warning. ''Don't change or remove these unless you are absolutely sure you know what you are doing.'' There are also options besides true and false so read the docs for more info. It is far too much to cover here but the simple config above is all I need for my purposes.

Once the service is configured you can control it with systemctl like any other systemd service. By default it will be disabled so you will need to enable it to run automatically after suitable testing. You can check the logs for errors with journalctl (see note about logging above). If syncs are working correctly you can watch them as uploads are logged very shortly after the events are saved to local disk;

<nowiki>[root@nvr system]# tail -50 /var/log/lsyncd/lsyncd.log
/1/2025-12-11/8707/8707-video.mp4
/1/2025-12-11/8707/snapshot.jpg
/1/2025-12-11/8707/alarm.jpg
/6/2025-12-11/8708/
/6/2025-12-11/
/6/
/6/2025-12-11/8708/8708-video.mp4
/6/2025-12-11/8708/snapshot.jpg
/6/2025-12-11/8708/alarm.jpg
/8/2025-12-11/8706/8706-video.mp4
/8/2025-12-11/8706/
/8/2025-12-11/
/8/
Thu Dec 11 14:30:25 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:31:50 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8709/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8709/8709-video.mp4
/2/2025-12-11/8709/snapshot.jpg
/2/2025-12-11/8709/alarm.jpg
Thu Dec 11 14:32:00 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:32:04 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8710/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8710/8710-video.mp4
/2/2025-12-11/8710/snapshot.jpg
/2/2025-12-11/8710/alarm.jpg
Thu Dec 11 14:32:11 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:32:45 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8711/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8711/8711-video.mp4
/2/2025-12-11/8711/snapshot.jpg
/2/2025-12-11/8711/alarm.jpg
Thu Dec 11 14:32:51 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:37:36 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/3/2025-12-11/8712/
/3/2025-12-11/
/3/
/
/3/2025-12-11/8712/8712-video.mp4
/3/2025-12-11/8712/snapshot.jpg
/3/2025-12-11/8712/alarm.jpg
Thu Dec 11 14:37:41 2025 Normal: Finished a list after exitcode: 0
[root@nvr system]#</nowiki>

Note: If you receive errors similar to "maximum number of watches reached" in the logs you may need to increase the default limits on your system for /proc/sys/fs/inotify/max_user_instances and /proc/sys/fs/inotify/max_user_watches. See here for more details;

https://support.scc.suse.com/s/kb/360054835111?language=en_US

I'm happy to again have offsite copies of all my events now. While they are not tracked in the Zoneminder database, they are still saved in folders by monitor id and date for easy retrieval should the ZM database become unavailable. Props to the ZM devs for their great software, and I hope this writeup proves useful to some other users in the future.

==See Also==
* https://github.com/lsyncd/lsyncd/issues/668 - Beware that lsync will do rsync with deletes on by default. With some casual testing, you might inadvertedly delete your home directory or root filesystem. From the github: "''I was told many times delete by default was a bad idea and was a result of the usual use case in the sense of replicating the target exactly like the source. I suppose the people telling so have a point.''"
* https://docs.rockylinux.org/10/books/learning_rsync/06_rsync_inotify/
* https://linuxvox.com/blog/what-is-the-proper-way-to-use-inotify/ - Using inotify-tools command line interface
* https://www.cyberciti.biz/faq/linux-inotify-examples-to-replicate-directories/ - Probably easier than lsyncd. (Was not available in default Debian Bullseye (have to use backports https://qa.debian.org/madison.php?package=incron&table=archived&a=&c=&s=#) but is in most other Debian releases.).
* https://wiki.alpinelinux.org/wiki/Inotifyd
* https://wiki.archlinux.org/title/Incron

Realtime event backup to cloud storage

2026-02-22T20:26:15Z

Kernelkurtz: Add exclude all jpegs

It's possible to use lsync daemon, which leverages the inotify https://en.wikipedia.org/wiki/Inotify kernel subsystem to run triggers based on events in a directory (create, modify, delete). Triggers can be varied (you can run any arbitrary command) but in the default use case, is as a filesystem backup / clone using the rsync command.

You may also want to consider other options. Inotify has command line tools, and there is an incrond, which uses cron syntax to run commands based on inotify.

==About==
After recently migrating from another popular NVR software on Windows to Zoneminder on Linux I started looking for a way to do near-real-time backups of my events to offsite storage, simply as a way to have a copy should the local ZM server be compromised by break-in, fire, etc. Software such as Dropbox, Google Drive, etc. make it relatively easy to do this on Windows but the setup on Linux takes bit more effort.

I wanted to keep it as simple as possible and don't need my backup solution to interface with the ZM database. After experimenting with several other options, I have settled on an application called lsyncd. It runs as a service and leverages inotify and rsync to watch a directory or directories and mirror only new changes to another storage location. Lsyncd should be available as a package for most Linux distributions. I used the installation instructions here for my Rocky Linux system;

https://docs.rockylinux.org/10/guides/backup/mirroring_lsyncd/

Note the version of lsyncd included in EPEL for Rocky 8 (2.2.2-9) has a noticeable memory leak. Building from source solved this issue.

At this point it is worthwhile to at least skim through the docs.

https://lsyncd.github.io/lsyncd/manual/config/file/

https://linux.die.net/man/1/rsync

Both lsyncd and rsync are highly configurable. For many people the use case will be very simple like my own which I will describe here - watch my Zoneminder storage location and copy new files to a remote location, but much more complex configurations are certainly possible. In my case I'll be writing to an Amazon S3 bucket which I have already setup using S3FS-FUSE according to the documentation here;

https://zoneminder.readthedocs.io/en/latest/userguide/options/options_storage.html

You can also use an Rclone mount point as a destination. I've tested this with Google Drive but it should work with any cloud provider supported by Rclone;

https://rclone.org/#providers

Follow the instructions here to set up your cloud storage as a local mountpoint;

https://rclone.org/commands/rclone_mount/

==Setup==

Once lsyncd is installed you will need to create a configuration file in /etc/lsyncd.conf. I've included mine as an example below. Note this file uses Lua syntax, not Bash. Be '''VERY CAREFUL''' if you are testing remote write/sync/copy operations to a destination that already has important data on it (see links below). I highly recommend initial testing with an empty bucket or target filesystem. You have been warned.

<nowiki>settings {

logfile = "/var/log/lsyncd/lsyncd.log",

statusFile = "/var/log/lsyncd/lsyncd-status.log",

statusInterval = 10,

maxProcesses = 1,

insist = true

}

sync {

default.rsync,

source = "/home/Cameras",

target = "/media/aws",

delete = false,

delay = 10,

init = false,

exclude = { '*.jpg' },

rsync = {

archive = true,

ignore_times = true,

inplace = true,

whole_file = true,

prune_empty_dirs = true

}

}</nowiki>

''logfile = '' is pretty self-explanatory. Be sure to set up log rotation after you are done setting lsyncd up, if required. By default the packaged lsyncd service logs to the systemd journal, which also by default echoes to /var/log/messages. Since the application logs are sufficient I've added the 'StandardOutput=null' option to the lsyncd service's unit file to prevent this over-duplication, but I've left StandardError with the existing default logging to the journal.

''maxProcesses = 1'' is the default. If you are syncing multiple sources or targets you may want to increase this.

''insist = true'' allows the service to start even if the target is not ready. According to the docs "In production mode it is recommended to have insist on."

''source = ''The directory where ZM events are stored.

''target = ''The location to copy events to. This will be the mount point for the cloud storage configured previously.

''targetdir = "/somedirectory"'' (not shown, part of sync block) subdirectory to use on the target. I'm just using the root directory in a dedicated bucket. You may not want this and should specify something here.

''delay = ''This is how often rsync will run if there are any filesystem changes. Default is 15 seconds. For many users this will be close enough to real-time for the purpose. This can be combined with (or substituted) for another value in the settings field;

''maxDelay = # '' (not shown, part of settings block) will queue this # of file changes before calling rsync. Between delay and/or maxDelay it is possible to tune the timing of your file copies to your exact preference. inotify waits for write_close to add files to the transfer list so there are no issues with rsync trying to upload uncompleted files. I typically only record short 10 second clips. If you use your cameras to continuously record be aware that files in the process of being written will not be copied until they are closed. It may be further possible to remove this limitation with the inotifyMode directive, though I have not tested this.

''exclude = { '*.jpg' }'' These are generally used by the Zoneminder GUI but are not really needed as standalone files in my case (though some people may save .jpgs on purpose, in which case you will want to remove this line). I'm only interested in having backups of the videos, so not syncing these reduces the number of uploaded files significantly. You can break them out by type '*snapshot*.jpg' , 'alarm.jpg' , '*capture*.jpg' etc., or just exclude them all as shown. Functions like zmNinja's 24 Hour Review may create hundreds of snapshots all at once, which lsyncd will immediately sync, so you can avoid that with these filters.

''archive = true ''This preserves ownership and permissions on the copied files.

''ignore_times = true'' This sets rsync's --ignore-times directive. For the purpose it is being used here it is safe to assume you will never have a newer copy of the files you are uploading already existing in your destination. Removing this check reduces API calls and is a noticeable optimization for AWS. If your cloud provider does not meter traffic you probably won't notice any difference with this either way.

''inplace = true'' and ''whole_file = true'' Sets these rsync options and are a further optimization for S3 API use efficiency. This makes rsync's functionality less "sync" and more straight "copy", again because we can safely assume only newly created files will ever be transferred. These options used together make this method of backing up events very close in terms of total traffic cost to natively writing to S3 straight from Zoneminder. Once again if your provider does not charge for API calls this will not matter to you.

''prune_empty_dirs = true'' Because they are watched by inotify, rsync will create empty remote directories even for events Zonmeminder deletes locally. If you are not syncing deletes you will want to use this flag, see ''delete'' below.

Two other very important variables in this file are;

''delete = false'' this is also pretty self explanatory, file deletes will not be synced from source to target. In the case of my S3 bucket I have lifecycle rules that handle this. If you prefer for your remote storage location to synchronize the deletions made by Zoneminder you can set this to true. This also means if you accidentally delete events from your local storage they will be deleted from the cloud as well. Use with caution.

''init = false'' causes the lsyncd to not do a complete initial synchronization between source and target on service startup. On S3 this is expensive in terms of API calls and may take a while. I know I'm going to miss some events during system maintenance/OS updates etc anyway so I don't consider this worth the cost, but you can set to true if you want it. Be warned it will make your target an exact mirror of your source.

Having delete and init set to false also should make this config fairly safe to use against an existing target if you just run it on your machine without heeding my previous warning. ''Don't change or remove these unless you are absolutely sure you know what you are doing.'' There are also options besides true and false so read the docs for more info. It is far too much to cover here but the simple config above is all I need for my purposes.

Once the service is configured you can control it with systemctl like any other systemd service. By default it will be disabled so you will need to enable it to run automatically after suitable testing. You can check the logs for errors with journalctl (see note about logging above). If syncs are working correctly you can watch them as uploads are logged very shortly after the events are saved to local disk;

<nowiki>[root@nvr system]# tail -50 /var/log/lsyncd/lsyncd.log
/1/2025-12-11/8707/8707-video.mp4
/1/2025-12-11/8707/snapshot.jpg
/1/2025-12-11/8707/alarm.jpg
/6/2025-12-11/8708/
/6/2025-12-11/
/6/
/6/2025-12-11/8708/8708-video.mp4
/6/2025-12-11/8708/snapshot.jpg
/6/2025-12-11/8708/alarm.jpg
/8/2025-12-11/8706/8706-video.mp4
/8/2025-12-11/8706/
/8/2025-12-11/
/8/
Thu Dec 11 14:30:25 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:31:50 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8709/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8709/8709-video.mp4
/2/2025-12-11/8709/snapshot.jpg
/2/2025-12-11/8709/alarm.jpg
Thu Dec 11 14:32:00 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:32:04 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8710/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8710/8710-video.mp4
/2/2025-12-11/8710/snapshot.jpg
/2/2025-12-11/8710/alarm.jpg
Thu Dec 11 14:32:11 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:32:45 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8711/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8711/8711-video.mp4
/2/2025-12-11/8711/snapshot.jpg
/2/2025-12-11/8711/alarm.jpg
Thu Dec 11 14:32:51 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:37:36 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/3/2025-12-11/8712/
/3/2025-12-11/
/3/
/
/3/2025-12-11/8712/8712-video.mp4
/3/2025-12-11/8712/snapshot.jpg
/3/2025-12-11/8712/alarm.jpg
Thu Dec 11 14:37:41 2025 Normal: Finished a list after exitcode: 0
[root@nvr system]#</nowiki>

Note: If you receive errors similar to "maximum number of watches reached" in the logs you may need to increase the default limits on your system for /proc/sys/fs/inotify/max_user_instances and /proc/sys/fs/inotify/max_user_watches. See here for more details;

https://support.scc.suse.com/s/kb/360054835111?language=en_US

I'm happy to again have offsite copies of all my events now. While they are not tracked in the Zoneminder database, they are still saved in folders by monitor id and date for easy retrieval should the ZM database become unavailable. Props to the ZM devs for their great software, and I hope this writeup proves useful to some other users in the future.

==See Also==
* https://github.com/lsyncd/lsyncd/issues/668 - Beware that lsync will do rsync with deletes on by default. With some casual testing, you might inadvertedly delete your home directory or root filesystem. From the github: "''I was told many times delete by default was a bad idea and was a result of the usual use case in the sense of replicating the target exactly like the source. I suppose the people telling so have a point.''"
* https://docs.rockylinux.org/10/books/learning_rsync/06_rsync_inotify/
* https://linuxvox.com/blog/what-is-the-proper-way-to-use-inotify/ - Using inotify-tools command line interface
* https://www.cyberciti.biz/faq/linux-inotify-examples-to-replicate-directories/ - Probably easier than lsyncd. (Was not available in default Debian Bullseye (have to use backports https://qa.debian.org/madison.php?package=incron&table=archived&a=&c=&s=#) but is in most other Debian releases.).
* https://wiki.alpinelinux.org/wiki/Inotifyd
* https://wiki.archlinux.org/title/Incron

Realtime event backup to cloud storage

2026-02-20T17:05:20Z

Kernelkurtz:

It's possible to use lsync daemon, which leverages the inotify https://en.wikipedia.org/wiki/Inotify kernel subsystem to run triggers based on events in a directory (create, modify, delete). Triggers can be varied (you can run any arbitrary command) but in the default use case, is as a filesystem backup / clone using the rsync command.

You may also want to consider other options. Inotify has command line tools, and there is an incrond, which uses cron syntax to run commands based on inotify.

==About==
After recently migrating from another popular NVR software on Windows to Zoneminder on Linux I started looking for a way to do near-real-time backups of my events to offsite storage, simply as a way to have a copy should the local ZM server be compromised by break-in, fire, etc. Software such as Dropbox, Google Drive, etc. make it relatively easy to do this on Windows but the setup on Linux takes bit more effort.

I wanted to keep it as simple as possible and don't need my backup solution to interface with the ZM database. After experimenting with several other options, I have settled on an application called lsyncd. It runs as a service and leverages inotify and rsync to watch a directory or directories and mirror only new changes to another storage location. Lsyncd should be available as a package for most Linux distributions. I used the installation instructions here for my Rocky Linux system;

https://docs.rockylinux.org/10/guides/backup/mirroring_lsyncd/

Note the version of lsyncd included in EPEL for Rocky 8 (2.2.2-9) has a noticeable memory leak. Building from source solved this issue.

At this point it is worthwhile to at least skim through the docs.

https://lsyncd.github.io/lsyncd/manual/config/file/

https://linux.die.net/man/1/rsync

Both lsyncd and rsync are highly configurable. For many people the use case will be very simple like my own which I will describe here - watch my Zoneminder storage location and copy new files to a remote location, but much more complex configurations are certainly possible. In my case I'll be writing to an Amazon S3 bucket which I have already setup using S3FS-FUSE according to the documentation here;

https://zoneminder.readthedocs.io/en/latest/userguide/options/options_storage.html

You can also use an Rclone mount point as a destination. I've tested this with Google Drive but it should work with any cloud provider supported by Rclone;

https://rclone.org/#providers

Follow the instructions here to set up your cloud storage as a local mountpoint;

https://rclone.org/commands/rclone_mount/

==Setup==

Once lsyncd is installed you will need to create a configuration file in /etc/lsyncd.conf. I've included mine as an example below. Note this file uses Lua syntax, not Bash. Be '''VERY CAREFUL''' if you are testing remote write/sync/copy operations to a destination that already has important data on it (see links below). I highly recommend initial testing with an empty bucket or target filesystem. You have been warned.

<nowiki>settings {

logfile = "/var/log/lsyncd/lsyncd.log",

statusFile = "/var/log/lsyncd/lsyncd-status.log",

statusInterval = 10,

maxProcesses = 1,

insist = true

}

sync {

default.rsync,

source = "/home/Cameras",

target = "/media/aws",

delete = false,

delay = 10,

init = false,

exclude = { 'snapshot*.jpg' , 'alarm.jpg' },

rsync = {

archive = true,

ignore_times = true,

inplace = true,

whole_file = true,

prune_empty_dirs = true

}

}</nowiki>

''logfile = '' is pretty self-explanatory. Be sure to set up log rotation after you are done setting lsyncd up, if required. By default the packaged lsyncd service logs to the systemd journal, which also by default echoes to /var/log/messages. Since the application logs are sufficient I've added the 'StandardOutput=null' option to the lsyncd service's unit file to prevent this over-duplication, but I've left StandardError with the existing default logging to the journal.

''maxProcesses = 1'' is the default. If you are syncing multiple sources or targets you may want to increase this.

''insist = true'' allows the service to start even if the target is not ready. According to the docs "In production mode it is recommended to have insist on."

''source = ''The directory where ZM events are stored.

''target = ''The location to copy events to. This will be the mount point for the cloud storage configured previously.

''targetdir = "/somedirectory"'' (not shown, part of sync block) subdirectory to use on the target. I'm just using the root directory in a dedicated bucket. You may not want this and should specify something here.

''delay = ''This is how often rsync will run if there are any filesystem changes. Default is 15 seconds. For many users this will be close enough to real-time for the purpose. This can be combined with (or substituted) for another value in the settings field;

''maxDelay = # '' (not shown, part of settings block) will queue this # of file changes before calling rsync. Between delay and/or maxDelay it is possible to tune the timing of your file copies to your exact preference. inotify waits for write_close to add files to the transfer list so there are no issues with rsync trying to upload uncompleted files. I typically only record short 10 second clips. If you use your cameras to continuously record be aware that files in the process of being written will not be copied until they are closed. It may be further possible to remove this limitation with the inotifyMode directive, though I have not tested this.

''exclude = { 'snapshot*.jpg' , 'alarm.jpg' }'' These are used by the Zoneminder GUI but are less useful as standalone files. I'm only interested in having backups of the videos, so not syncing these means uploading a single file per event rather than three, but this directive is of course optional. Functions like zmNinja's 24 Hour Review may create hundreds of snapshots all at once, which lsyncd will immediately sync. If you just want to exclude these dynamically generated files, use 'snapshot-*.jpg' instead of 'snapshot*.jpg' which will only catch the ones with dimensions in the filename eg.'snapshot-712x400.jpg'. The log snippet below did not include this option.

''archive = true ''This preserves ownership and permissions on the copied files.

''ignore_times = true'' This sets rsync's --ignore-times directive. For the purpose it is being used here it is safe to assume you will never have a newer copy of the files you are uploading already existing in your destination. Removing this check reduces API calls and is a noticeable optimization for AWS. If your cloud provider does not meter traffic you probably won't notice any difference with this either way.

''inplace = true'' and ''whole_file = true'' Sets these rsync options and are a further optimization for S3 API use efficiency. This makes rsync's functionality less "sync" and more straight "copy", again because we can safely assume only newly created files will ever be transferred. These options used together make this method of backing up events very close in terms of total traffic cost to natively writing to S3 straight from Zoneminder. Once again if your provider does not charge for API calls this will not matter to you.

''prune_empty_dirs = true'' Because they are watched by inotify, rsync will create empty remote directories even for events Zonmeminder deletes locally. If you are not syncing deletes you will want to use this flag, see ''delete'' below.

Two other very important variables in this file are;

''delete = false'' this is also pretty self explanatory, file deletes will not be synced from source to target. In the case of my S3 bucket I have lifecycle rules that handle this. If you prefer for your remote storage location to synchronize the deletions made by Zoneminder you can set this to true. This also means if you accidentally delete events from your local storage they will be deleted from the cloud as well. Use with caution.

''init = false'' causes the lsyncd to not do a complete initial synchronization between source and target on service startup. On S3 this is expensive in terms of API calls and may take a while. I know I'm going to miss some events during system maintenance/OS updates etc anyway so I don't consider this worth the cost, but you can set to true if you want it. Be warned it will make your target an exact mirror of your source.

Having delete and init set to false also should make this config fairly safe to use against an existing target if you just run it on your machine without heeding my previous warning. ''Don't change or remove these unless you are absolutely sure you know what you are doing.'' There are also options besides true and false so read the docs for more info. It is far too much to cover here but the simple config above is all I need for my purposes.

Once the service is configured you can control it with systemctl like any other systemd service. By default it will be disabled so you will need to enable it to run automatically after suitable testing. You can check the logs for errors with journalctl (see note about logging above). If syncs are working correctly you can watch them as uploads are logged very shortly after the events are saved to local disk;

<nowiki>[root@nvr system]# tail -50 /var/log/lsyncd/lsyncd.log
/1/2025-12-11/8707/8707-video.mp4
/1/2025-12-11/8707/snapshot.jpg
/1/2025-12-11/8707/alarm.jpg
/6/2025-12-11/8708/
/6/2025-12-11/
/6/
/6/2025-12-11/8708/8708-video.mp4
/6/2025-12-11/8708/snapshot.jpg
/6/2025-12-11/8708/alarm.jpg
/8/2025-12-11/8706/8706-video.mp4
/8/2025-12-11/8706/
/8/2025-12-11/
/8/
Thu Dec 11 14:30:25 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:31:50 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8709/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8709/8709-video.mp4
/2/2025-12-11/8709/snapshot.jpg
/2/2025-12-11/8709/alarm.jpg
Thu Dec 11 14:32:00 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:32:04 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8710/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8710/8710-video.mp4
/2/2025-12-11/8710/snapshot.jpg
/2/2025-12-11/8710/alarm.jpg
Thu Dec 11 14:32:11 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:32:45 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8711/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8711/8711-video.mp4
/2/2025-12-11/8711/snapshot.jpg
/2/2025-12-11/8711/alarm.jpg
Thu Dec 11 14:32:51 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:37:36 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/3/2025-12-11/8712/
/3/2025-12-11/
/3/
/
/3/2025-12-11/8712/8712-video.mp4
/3/2025-12-11/8712/snapshot.jpg
/3/2025-12-11/8712/alarm.jpg
Thu Dec 11 14:37:41 2025 Normal: Finished a list after exitcode: 0
[root@nvr system]#</nowiki>

Note: If you receive errors similar to "maximum number of watches reached" in the logs you may need to increase the default limits on your system for /proc/sys/fs/inotify/max_user_instances and /proc/sys/fs/inotify/max_user_watches. See here for more details;

https://support.scc.suse.com/s/kb/360054835111?language=en_US

I'm happy to again have offsite copies of all my events now. While they are not tracked in the Zoneminder database, they are still saved in folders by monitor id and date for easy retrieval should the ZM database become unavailable. Props to the ZM devs for their great software, and I hope this writeup proves useful to some other users in the future.

==See Also==
* https://github.com/lsyncd/lsyncd/issues/668 - Beware that lsync will do rsync with deletes on by default. With some casual testing, you might inadvertedly delete your home directory or root filesystem. From the github: "''I was told many times delete by default was a bad idea and was a result of the usual use case in the sense of replicating the target exactly like the source. I suppose the people telling so have a point.''"
* https://docs.rockylinux.org/10/books/learning_rsync/06_rsync_inotify/
* https://linuxvox.com/blog/what-is-the-proper-way-to-use-inotify/ - Using inotify-tools command line interface
* https://www.cyberciti.biz/faq/linux-inotify-examples-to-replicate-directories/ - Probably easier than lsyncd. (Was not available in default Debian Bullseye (have to use backports https://qa.debian.org/madison.php?package=incron&table=archived&a=&c=&s=#) but is in most other Debian releases.).
* https://wiki.alpinelinux.org/wiki/Inotifyd
* https://wiki.archlinux.org/title/Incron

Realtime event backup to cloud storage

2026-02-19T19:54:57Z

Kernelkurtz: Reduce systemd logging

It's possible to use lsync daemon, which leverages the inotify https://en.wikipedia.org/wiki/Inotify kernel subsystem to run triggers based on events in a directory (create, modify, delete). Triggers can be varied (you can run any arbitrary command) but in the default use case, is as a filesystem backup / clone using the rsync command.

You may also want to consider other options. Inotify has command line tools, and there is an incrond, which uses cron syntax to run commands based on inotify.

==About==
After recently migrating from another popular NVR software on Windows to Zoneminder on Linux I started looking for a way to do near-real-time backups of my events to offsite storage, simply as a way to have a copy should the local ZM server be compromised by break-in, fire, etc. Software such as Dropbox, Google Drive, etc. make it relatively easy to do this on Windows but the setup on Linux takes bit more effort.

I wanted to keep it as simple as possible and don't need my backup solution to interface with the ZM database. After experimenting with several other options, I have settled on an application called lsyncd. It runs as a service and leverages inotify and rsync to watch a directory or directories and mirror only new changes to another storage location. Lsyncd should be available as a package for most Linux distributions. I used the installation instructions here for my Rocky Linux system;

https://docs.rockylinux.org/10/guides/backup/mirroring_lsyncd/

Note the version of lsyncd included in EPEL for Rocky 8 (2.2.2-9) has a noticeable memory leak. Building from source solved this issue.

At this point it is worthwhile to at least skim through the docs.

https://lsyncd.github.io/lsyncd/manual/config/file/

https://linux.die.net/man/1/rsync

Both lsyncd and rsync are highly configurable. For many people the use case will be very simple like my own which I will describe here - watch my Zoneminder storage location and copy new files to a remote location, but much more complex configurations are certainly possible. In my case I'll be writing to an Amazon S3 bucket which I have already setup using S3FS-FUSE according to the documentation here;

https://zoneminder.readthedocs.io/en/latest/userguide/options/options_storage.html

You can also use an Rclone mount point as a destination. I've tested this with Google Drive but it should work with any cloud provider supported by Rclone;

https://rclone.org/#providers

Follow the instructions here to set up your cloud storage as a local mountpoint;

https://rclone.org/commands/rclone_mount/

==Setup==

Once lsyncd is installed you will need to create a configuration file in /etc/lsyncd.conf. I've included mine as an example below. Note this file uses Lua syntax, not Bash. Be '''VERY CAREFUL''' if you are testing remote write/sync/copy operations to a destination that already has important data on it (see links below). I highly recommend initial testing with an empty bucket or target filesystem. You have been warned.

<nowiki>settings {

logfile = "/var/log/lsyncd/lsyncd.log",

statusFile = "/var/log/lsyncd/lsyncd-status.log",

statusInterval = 10,

maxProcesses = 1,

insist = true

}

sync {

default.rsync,

source = "/home/Cameras",

target = "/media/aws",

delete = false,

delay = 10,

init = false,

exclude = { 'snapshot*.jpg' , 'alarm.jpg' },

rsync = {

archive = true,

ignore_times = true,

inplace = true,

whole_file = true,

prune_empty_dirs = true

}

}</nowiki>

''logfile = '' is pretty self-explanatory. Be sure to set up log rotation after you are done setting lsyncd up, if required. By default the packaged lsyncd service logs to the systemd journal, which also by default echoes to /var/log/messages. Since the application logs are sufficient I've added the 'StandardOutput=null' option to the lsyncd service's unit file to prevent this over-duplication, but I've left StandardError with the existing default logging to the journal.

''maxProcesses = 1'' is the default. If you are syncing multiple sources or targets you may want to increase this.

''insist = true'' allows the service to start even if the target is not ready. I got errors without this which went away when I added it. YMMV.

''source = ''The directory where ZM events are stored.

''target = ''The location to copy events to. This will be the mount point for the cloud storage configured previously.

''targetdir = "/somedirectory"'' (not shown, part of sync block) subdirectory to use on the target. I'm just using the root directory in a dedicated bucket. You may not want this and should specify something here.

''delay = ''This is how often rsync will run if there are any filesystem changes. Default is 15 seconds. For many users this will be close enough to real-time for the purpose. This can be combined with (or substituted) for another value in the settings field;

''maxDelay = # '' (not shown, part of settings block) will queue this # of file changes before calling rsync. Between delay and/or maxDelay it is possible to tune the timing of your file copies to your exact preference. inotify waits for write_close to add files to the transfer list so there are no issues with rsync trying to upload uncompleted files. I typically only record short 10 second clips. If you use your cameras to continuously record be aware that files in the process of being written will not be copied until they are closed. It may be further possible to remove this limitation with the inotifyMode directive, though I have not tested this.

''exclude = { 'snapshot*.jpg' , 'alarm.jpg' }'' These are used by the Zoneminder GUI but are less useful as standalone files. I'm only interested in having backups of the videos, so not syncing these means uploading a single file per event rather than three, but this directive is of course optional. Functions like zmNinja's 24 Hour Review may create hundreds of snapshots all at once, which lsyncd will immediately sync. If you just want to exclude these dynamically generated files, use 'snapshot-*.jpg' instead of 'snapshot*.jpg' which will only catch the ones with dimensions in the filename eg.'snapshot-712x400.jpg'. The log snippet below did not include this option.

''archive = true ''This preserves ownership and permissions on the copied files.

''ignore_times = true'' This sets rsync's --ignore-times directive. For the purpose it is being used here it is safe to assume you will never have a newer copy of the files you are uploading already existing in your destination. Removing this check reduces API calls and is a noticeable optimization for AWS. If your cloud provider does not meter traffic you probably won't notice any difference with this either way.

''inplace = true'' and ''whole_file = true'' Sets these rsync options and are a further optimization for S3 API use efficiency. This makes rsync's functionality less "sync" and more straight "copy", again because we can safely assume only newly created files will ever be transferred. These options used together make this method of backing up events very close in terms of total traffic cost to natively writing to S3 straight from Zoneminder. Once again if your provider does not charge for API calls this will not matter to you.

''prune_empty_dirs = true'' Because they are watched by inotify, rsync will create empty remote directories even for events Zonmeminder deletes locally. If you are not syncing deletes you will want to use this flag, see ''delete'' below.

Two other very important variables in this file are;

''delete = false'' this is also pretty self explanatory, file deletes will not be synced from source to target. In the case of my S3 bucket I have lifecycle rules that handle this. If you prefer for your remote storage location to synchronize the deletions made by Zoneminder you can set this to true. This also means if you accidentally delete events from your local storage they will be deleted from the cloud as well. Use with caution.

''init = false'' causes the lsyncd to not do a complete initial synchronization between source and target on service startup. On S3 this is expensive in terms of API calls and may take a while. I know I'm going to miss some events during system maintenance/OS updates etc anyway so I don't consider this worth the cost, but you can set to true if you want it. Be warned it will make your target an exact mirror of your source.

Having delete and init set to false also should make this config fairly safe to use against an existing target if you just run it on your machine without heeding my previous warning. ''Don't change or remove these unless you are absolutely sure you know what you are doing.'' There are also options besides true and false so read the docs for more info. It is far too much to cover here but the simple config above is all I need for my purposes.

Once the service is configured you can control it with systemctl like any other systemd service. By default it will be disabled so you will need to enable it to run automatically after suitable testing. You can check the logs for errors with journalctl (see note about logging above). If syncs are working correctly you can watch them as uploads are logged very shortly after the events are saved to local disk;

<nowiki>[root@nvr system]# tail -50 /var/log/lsyncd/lsyncd.log
/1/2025-12-11/8707/8707-video.mp4
/1/2025-12-11/8707/snapshot.jpg
/1/2025-12-11/8707/alarm.jpg
/6/2025-12-11/8708/
/6/2025-12-11/
/6/
/6/2025-12-11/8708/8708-video.mp4
/6/2025-12-11/8708/snapshot.jpg
/6/2025-12-11/8708/alarm.jpg
/8/2025-12-11/8706/8706-video.mp4
/8/2025-12-11/8706/
/8/2025-12-11/
/8/
Thu Dec 11 14:30:25 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:31:50 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8709/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8709/8709-video.mp4
/2/2025-12-11/8709/snapshot.jpg
/2/2025-12-11/8709/alarm.jpg
Thu Dec 11 14:32:00 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:32:04 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8710/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8710/8710-video.mp4
/2/2025-12-11/8710/snapshot.jpg
/2/2025-12-11/8710/alarm.jpg
Thu Dec 11 14:32:11 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:32:45 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8711/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8711/8711-video.mp4
/2/2025-12-11/8711/snapshot.jpg
/2/2025-12-11/8711/alarm.jpg
Thu Dec 11 14:32:51 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:37:36 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/3/2025-12-11/8712/
/3/2025-12-11/
/3/
/
/3/2025-12-11/8712/8712-video.mp4
/3/2025-12-11/8712/snapshot.jpg
/3/2025-12-11/8712/alarm.jpg
Thu Dec 11 14:37:41 2025 Normal: Finished a list after exitcode: 0
[root@nvr system]#</nowiki>

Note: If you receive errors similar to "maximum number of watches reached" in the logs you may need to increase the default limits on your system for /proc/sys/fs/inotify/max_user_instances and /proc/sys/fs/inotify/max_user_watches. See here for more details;

https://support.scc.suse.com/s/kb/360054835111?language=en_US

I'm happy to again have offsite copies of all my events now. While they are not tracked in the Zoneminder database, they are still saved in folders by monitor id and date for easy retrieval should the ZM database become unavailable. Props to the ZM devs for their great software, and I hope this writeup proves useful to some other users in the future.

==See Also==
* https://github.com/lsyncd/lsyncd/issues/668 - Beware that lsync will do rsync with deletes on by default. With some casual testing, you might inadvertedly delete your home directory or root filesystem. From the github: "''I was told many times delete by default was a bad idea and was a result of the usual use case in the sense of replicating the target exactly like the source. I suppose the people telling so have a point.''"
* https://docs.rockylinux.org/10/books/learning_rsync/06_rsync_inotify/
* https://linuxvox.com/blog/what-is-the-proper-way-to-use-inotify/ - Using inotify-tools command line interface
* https://www.cyberciti.biz/faq/linux-inotify-examples-to-replicate-directories/ - Probably easier than lsyncd. (Was not available in default Debian Bullseye (have to use backports https://qa.debian.org/madison.php?package=incron&table=archived&a=&c=&s=#) but is in most other Debian releases.).
* https://wiki.alpinelinux.org/wiki/Inotifyd
* https://wiki.archlinux.org/title/Incron

Realtime event backup to cloud storage

2026-02-18T05:11:28Z

Kernelkurtz:

It's possible to use lsync daemon, which leverages the inotify https://en.wikipedia.org/wiki/Inotify kernel subsystem to run triggers based on events in a directory (create, modify, delete). Triggers can be varied (you can run any arbitrary command) but in the default use case, is as a filesystem backup / clone using the rsync command.

You may also want to consider other options. Inotify has command line tools, and there is an incrond, which uses cron syntax to run commands based on inotify.

==About==
After recently migrating from another popular NVR software on Windows to Zoneminder on Linux I started looking for a way to do near-real-time backups of my events to offsite storage, simply as a way to have a copy should the local ZM server be compromised by break-in, fire, etc. Software such as Dropbox, Google Drive, etc. make it relatively easy to do this on Windows but the setup on Linux takes bit more effort.

I wanted to keep it as simple as possible and don't need my backup solution to interface with the ZM database. After experimenting with several other options, I have settled on an application called lsyncd. It runs as a service and leverages inotify and rsync to watch a directory or directories and mirror only new changes to another storage location. Lsyncd should be available as a package for most Linux distributions. I used the installation instructions here for my Rocky Linux system;

https://docs.rockylinux.org/10/guides/backup/mirroring_lsyncd/

Note the version of lsyncd included in EPEL for Rocky 8 (2.2.2-9) has a noticeable memory leak. Building from source solved this issue.

At this point it is worthwhile to at least skim through the docs.

https://lsyncd.github.io/lsyncd/manual/config/file/

https://linux.die.net/man/1/rsync

Both lsyncd and rsync are highly configurable. For many people the use case will be very simple like my own which I will describe here - watch my Zoneminder storage location and copy new files to a remote location, but much more complex configurations are certainly possible. In my case I'll be writing to an Amazon S3 bucket which I have already setup using S3FS-FUSE according to the documentation here;

https://zoneminder.readthedocs.io/en/latest/userguide/options/options_storage.html

You can also use an Rclone mount point as a destination. I've tested this with Google Drive but it should work with any cloud provider supported by Rclone;

https://rclone.org/#providers

Follow the instructions here to set up your cloud storage as a local mountpoint;

https://rclone.org/commands/rclone_mount/

==Setup==

Once lsyncd is installed you will need to create a configuration file in /etc/lsyncd.conf. I've included mine as an example below. Note this file uses Lua syntax, not Bash. Be '''VERY CAREFUL''' if you are testing remote write/sync/copy operations to a destination that already has important data on it (see links below). I highly recommend initial testing with an empty bucket or target filesystem. You have been warned.

<nowiki>settings {

logfile = "/var/log/lsyncd/lsyncd.log",

statusFile = "/var/log/lsyncd/lsyncd-status.log",

statusInterval = 10,

maxProcesses = 1,

insist = true

}

sync {

default.rsync,

source = "/home/Cameras",

target = "/media/aws",

delete = false,

delay = 10,

init = false,

exclude = { 'snapshot*.jpg' , 'alarm.jpg' },

rsync = {

archive = true,

ignore_times = true,

inplace = true,

whole_file = true,

prune_empty_dirs = true

}

}</nowiki>

''logfile = '' is pretty self-explanatory. Be sure to set up log rotation after you are done setting lsyncd up, if required.

''maxProcesses = 1'' is the default. If you are syncing multiple sources or targets you may want to increase this.

''insist = true'' allows the service to start even if the target is not ready. I got errors without this which went away when I added it. YMMV.

''source = ''The directory where ZM events are stored.

''target = ''The location to copy events to. This will be the mount point for the cloud storage configured previously.

''targetdir = "/somedirectory"'' (not shown, part of sync block) subdirectory to use on the target. I'm just using the root directory in a dedicated bucket. You may not want this and should specify something here.

''delay = ''This is how often rsync will run if there are any filesystem changes. Default is 15 seconds. For many users this will be close enough to real-time for the purpose. This can be combined with (or substituted) for another value in the settings field;

''maxDelay = # '' (not shown, part of settings block) will queue this # of file changes before calling rsync. Between delay and/or maxDelay it is possible to tune the timing of your file copies to your exact preference. inotify waits for write_close to add files to the transfer list so there are no issues with rsync trying to upload uncompleted files. I typically only record short 10 second clips. If you use your cameras to continuously record be aware that files in the process of being written will not be copied until they are closed. It may be further possible to remove this limitation with the inotifyMode directive, though I have not tested this.

''exclude = { 'snapshot*.jpg' , 'alarm.jpg' }'' These are used by the Zoneminder GUI but are less useful as standalone files. I'm only interested in having backups of the videos, so not syncing these means uploading a single file per event rather than three, but this directive is of course optional. Functions like zmNinja's 24 Hour Review may create hundreds of snapshots all at once, which lsyncd will immediately sync. If you just want to exclude these dynamically generated files, use 'snapshot-*.jpg' instead of 'snapshot*.jpg' which will only catch the ones with dimensions in the filename eg.'snapshot-712x400.jpg'. The log snippet below did not include this option.

''archive = true ''This preserves ownership and permissions on the copied files.

''ignore_times = true'' This sets rsync's --ignore-times directive. For the purpose it is being used here it is safe to assume you will never have a newer copy of the files you are uploading already existing in your destination. Removing this check reduces API calls and is a noticeable optimization for AWS. If your cloud provider does not meter traffic you probably won't notice any difference with this either way.

''inplace = true'' and ''whole_file = true'' Sets these rsync options and are a further optimization for S3 API use efficiency. This makes rsync's functionality less "sync" and more straight "copy", again because we can safely assume only newly created files will ever be transferred. These options used together make this method of backing up events very close in terms of total traffic cost to natively writing to S3 straight from Zoneminder. Once again if your provider does not charge for API calls this will not matter to you.

''prune_empty_dirs = true'' Because they are watched by inotify, rsync will create empty remote directories even for events Zonmeminder deletes locally. If you are not syncing deletes you will want to use this flag, see ''delete'' below.

Two other very important variables in this file are;

''delete = false'' this is also pretty self explanatory, file deletes will not be synced from source to target. In the case of my S3 bucket I have lifecycle rules that handle this. If you prefer for your remote storage location to synchronize the deletions made by Zoneminder you can set this to true. This also means if you accidentally delete events from your local storage they will be deleted from the cloud as well. Use with caution.

''init = false'' causes the lsyncd to not do a complete initial synchronization between source and target on service startup. On S3 this is expensive in terms of API calls and may take a while. I know I'm going to miss some events during system maintenance/OS updates etc anyway so I don't consider this worth the cost, but you can set to true if you want it. Be warned it will make your target an exact mirror of your source.

Having delete and init set to false also should make this config fairly safe to use against an existing target if you just run it on your machine without heeding my previous warning. Don't change or remove these unless you are absolutely sure you know what you are doing. There are also options besides true and false so read the docs for more info. It is far too much to cover here but the simple config above is all I need for my purposes.

Once the service is configured you can control it with systemctl like any other systemd service. By default it will be disabled so you will need to enable it to run automatically after suitable testing. You can check the logs for startup or running errors with journalctl. If syncs are working correctly you can watch them as uploads are logged very shortly after the events are saved to local disk;

<nowiki>[root@nvr system]# tail -50 /var/log/lsyncd/lsyncd.log
/1/2025-12-11/8707/8707-video.mp4
/1/2025-12-11/8707/snapshot.jpg
/1/2025-12-11/8707/alarm.jpg
/6/2025-12-11/8708/
/6/2025-12-11/
/6/
/6/2025-12-11/8708/8708-video.mp4
/6/2025-12-11/8708/snapshot.jpg
/6/2025-12-11/8708/alarm.jpg
/8/2025-12-11/8706/8706-video.mp4
/8/2025-12-11/8706/
/8/2025-12-11/
/8/
Thu Dec 11 14:30:25 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:31:50 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8709/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8709/8709-video.mp4
/2/2025-12-11/8709/snapshot.jpg
/2/2025-12-11/8709/alarm.jpg
Thu Dec 11 14:32:00 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:32:04 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8710/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8710/8710-video.mp4
/2/2025-12-11/8710/snapshot.jpg
/2/2025-12-11/8710/alarm.jpg
Thu Dec 11 14:32:11 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:32:45 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8711/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8711/8711-video.mp4
/2/2025-12-11/8711/snapshot.jpg
/2/2025-12-11/8711/alarm.jpg
Thu Dec 11 14:32:51 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:37:36 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/3/2025-12-11/8712/
/3/2025-12-11/
/3/
/
/3/2025-12-11/8712/8712-video.mp4
/3/2025-12-11/8712/snapshot.jpg
/3/2025-12-11/8712/alarm.jpg
Thu Dec 11 14:37:41 2025 Normal: Finished a list after exitcode: 0
[root@nvr system]#</nowiki>

Note: If you receive errors similar to "maximum number of watches reached" in the logs you may need to increase the default limits on your system for /proc/sys/fs/inotify/max_user_instances and /proc/sys/fs/inotify/max_user_watches. See here for more details;

https://support.scc.suse.com/s/kb/360054835111?language=en_US

I'm happy to again have offsite copies of all my events now. While they are not tracked in the Zoneminder database, they are still saved in folders by monitor id and date for easy retrieval should the ZM database become unavailable. Props to the ZM devs for their great software, and I hope this writeup proves useful to some other users in the future.

==See Also==
* https://github.com/lsyncd/lsyncd/issues/668 - Beware that lsync will do rsync with deletes on by default. With some casual testing, you might inadvertedly delete your home directory or root filesystem. From the github: "''I was told many times delete by default was a bad idea and was a result of the usual use case in the sense of replicating the target exactly like the source. I suppose the people telling so have a point.''"
* https://docs.rockylinux.org/10/books/learning_rsync/06_rsync_inotify/
* https://linuxvox.com/blog/what-is-the-proper-way-to-use-inotify/ - Using inotify-tools command line interface
* https://www.cyberciti.biz/faq/linux-inotify-examples-to-replicate-directories/ - Probably easier than lsyncd. (Was not available in default Debian Bullseye (have to use backports https://qa.debian.org/madison.php?package=incron&table=archived&a=&c=&s=#) but is in most other Debian releases.).
* https://wiki.alpinelinux.org/wiki/Inotifyd
* https://wiki.archlinux.org/title/Incron

Realtime event backup to cloud storage

2026-02-18T05:05:33Z

Kernelkurtz:

It's possible to use lsync daemon, which leverages the inotify https://en.wikipedia.org/wiki/Inotify kernel subsystem to run triggers based on events in a directory (create, modify, delete). Triggers can be varied (you can run any arbitrary command) but in the default use case, is as a filesystem backup / clone using the rsync command.

You may also want to consider other options. Inotify has command line tools, and there is an incrond, which uses cron syntax to run commands based on inotify.

==About==
After recently migrating from another popular NVR software on Windows to Zoneminder on Linux I started looking for a way to do near-real-time backups of my events to offsite storage, simply as a way to have a copy should the local ZM server be compromised by break-in, fire, etc. Software such as Dropbox, Google Drive, etc. make it relatively easy to do this on Windows but the setup on Linux takes bit more effort.

I wanted to keep it as simple as possible and don't need my backup solution to interface with the ZM database. After experimenting with several other options, I have settled on an application called lsyncd. It runs as a service and leverages inotify and rsync to watch a directory or directories and mirror only new changes to another storage location. Lsyncd should be available as a package for most Linux distributions. I used the installation instructions here for my Rocky Linux system;

https://docs.rockylinux.org/10/guides/backup/mirroring_lsyncd/

Note the version of lsyncd included in EPEL for Rocky 8 (2.2.2-9) has a noticeable memory leak. Building from source solved this issue.

At this point it is worthwhile to at least skim through the docs.

https://lsyncd.github.io/lsyncd/manual/config/file/

https://linux.die.net/man/1/rsync

Both lsyncd and rsync are highly configurable. For many people the use case will be very simple like my own which I will describe here - watch my Zoneminder storage location and copy new files to a remote location, but much more complex configurations are certainly possible. In my case I'll be writing to an Amazon S3 bucket which I have already setup using S3FS-FUSE according to the documentation here;

https://zoneminder.readthedocs.io/en/latest/userguide/options/options_storage.html

You can also use an Rclone mount point as a destination. I've tested this with Google Drive but it should work with any cloud provider supported by Rclone;

https://rclone.org/#providers

Follow the instructions here to set up your cloud storage as a local mountpoint;

https://rclone.org/commands/rclone_mount/

==Setup==

Once lsyncd is installed you will need to create a configuration file in /etc/lsyncd.conf. I've included mine as an example below. Note this file uses Lua syntax, not Bash. Be '''VERY CAREFUL''' if you are testing remote write/sync/copy operations to a destination that already has important data on it (see links below). I highly recommend initial testing with an empty bucket or target filesystem. You have been warned.

<nowiki>settings {

logfile = "/var/log/lsyncd/lsyncd.log",

statusFile = "/var/log/lsyncd/lsyncd-status.log",

statusInterval = 10,

maxProcesses = 1,

insist = true

}

sync {

default.rsync,

source = "/home/Cameras",

target = "/media/aws",

delete = false,

delay = 10,

init = false,

exclude = { 'snapshot*.jpg' , 'alarm.jpg' },

rsync = {

archive = true,

ignore_times = true,

inplace = true,

whole_file = true,

prune_empty_dirs = true

}

}</nowiki>

''logfile = '' is pretty self-explanatory. Be sure to set up log rotation after you are done setting lsyncd up, if required.

''maxProcesses = 1'' is the default. If you are syncing multiple sources or targets you may want to increase this.

''insist = true'' allows the service to start even if the target is not ready. I got errors without this which went away when I added it. YMMV.

''source = ''The directory where ZM events are stored.

''target = ''The location to copy events to. This will be the mount point for the cloud storage configured previously.

''targetdir = "/somedirectory"'' (not shown, part of sync block) subdirectory to use on the target. I'm just using the root directory in a dedicated bucket. You may not want this and should specify something here.

''delay = ''This is how often rsync will run if there are any filesystem changes. Default is 15 seconds. For many users this will be close enough to real-time for the purpose. This can be combined with (or substituted) for another value in the settings field;

''maxDelay = # '' (not shown, part of settings block) will queue this # of file changes before calling rsync. Between delay and/or maxDelay it is possible to tune the timing of your file copies to your exact preference. inotify waits for write_close to add files to the transfer list so there are no issues with rsync trying to upload uncompleted files. I typically only record short 10 second clips. If you use your cameras to continuously record be aware that files in the process of being written will not be copied until they are closed. It may be further possible to remove this limitation with the inotifyMode directive, though I have not tested this.

''exclude = { 'snapshot*.jpg' , 'alarm.jpg' }'' These are used by the Zoneminder GUI but are less useful as standalone files. I'm only interested in having backups of the videos, so not syncing these means uploading a single file per event rather than three, but this directive is of course optional. Functions like zmNinja's 24 Hour Review may create hundreds of snapshots all at once, which lsyncd will immediately sync. If you just want to exclude these dynamically generated files, use 'snapshot-*.jpg' instead of 'snapshot*.jpg' which will only catch the ones with dimensions in the filename eg.'snapshot-712x400.jpg'.

''archive = true ''This preserves ownership and permissions on the copied files.

''ignore_times = true'' This sets rsync's --ignore-times directive. For the purpose it is being used here it is safe to assume you will never have a newer copy of the files you are uploading already existing in your destination. Removing this check reduces API calls and is a noticeable optimization for AWS. If your cloud provider does not meter traffic you probably won't notice any difference with this either way.

''inplace = true'' and ''whole_file = true'' Sets these rsync options and are a further optimization for S3 API use efficiency. This makes rsync's functionality less "sync" and more straight "copy", again because we can safely assume only newly created files will ever be transferred. These options used together make this method of backing up events very close in terms of total traffic cost to natively writing to S3 straight from Zoneminder. Once again if your provider does not charge for API calls this will not matter to you.

''prune_empty_dirs = true'' Because they are watched by inotify, rsync will create empty remote directories even for events Zonmeminder deletes locally. If you are not syncing deletes you will want to use this flag, see ''delete'' below.

Two other very important variables in this file are;

''delete = false'' this is also pretty self explanatory, file deletes will not be synced from source to target. In the case of my S3 bucket I have lifecycle rules that handle this. If you prefer for your remote storage location to synchronize the deletions made by Zoneminder you can set this to true. This also means if you accidentally delete events from your local storage they will be deleted from the cloud as well. Use with caution.

''init = false'' causes the lsyncd to not do a complete initial synchronization between source and target on service startup. On S3 this is expensive in terms of API calls and may take a while. I know I'm going to miss some events during system maintenance/OS updates etc anyway so I don't consider this worth the cost, but you can set to true if you want it. Be warned it will make your target an exact mirror of your source.

Having delete and init set to false also should make this config fairly safe to use against an existing target if you just run it on your machine without heeding my previous warning. Don't change or remove these unless you are absolutely sure you know what you are doing. There are also options besides true and false so read the docs for more info. It is far too much to cover here but the simple config above is all I need for my purposes.

Once the service is configured you can control it with systemctl like any other systemd service. By default it will be disabled so you will need to enable it to run automatically after suitable testing. You can check the logs for startup or running errors with journalctl. If syncs are working correctly you can watch them as uploads are logged very shortly after the events are saved to local disk;

<nowiki>[root@nvr system]# tail -50 /var/log/lsyncd/lsyncd.log
/1/2025-12-11/8707/8707-video.mp4
/1/2025-12-11/8707/snapshot.jpg
/1/2025-12-11/8707/alarm.jpg
/6/2025-12-11/8708/
/6/2025-12-11/
/6/
/6/2025-12-11/8708/8708-video.mp4
/6/2025-12-11/8708/snapshot.jpg
/6/2025-12-11/8708/alarm.jpg
/8/2025-12-11/8706/8706-video.mp4
/8/2025-12-11/8706/
/8/2025-12-11/
/8/
Thu Dec 11 14:30:25 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:31:50 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8709/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8709/8709-video.mp4
/2/2025-12-11/8709/snapshot.jpg
/2/2025-12-11/8709/alarm.jpg
Thu Dec 11 14:32:00 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:32:04 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8710/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8710/8710-video.mp4
/2/2025-12-11/8710/snapshot.jpg
/2/2025-12-11/8710/alarm.jpg
Thu Dec 11 14:32:11 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:32:45 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8711/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8711/8711-video.mp4
/2/2025-12-11/8711/snapshot.jpg
/2/2025-12-11/8711/alarm.jpg
Thu Dec 11 14:32:51 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:37:36 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/3/2025-12-11/8712/
/3/2025-12-11/
/3/
/
/3/2025-12-11/8712/8712-video.mp4
/3/2025-12-11/8712/snapshot.jpg
/3/2025-12-11/8712/alarm.jpg
Thu Dec 11 14:37:41 2025 Normal: Finished a list after exitcode: 0
[root@nvr system]#</nowiki>

Note: If you receive errors similar to "maximum number of watches reached" in the logs you may need to increase the default limits on your system for /proc/sys/fs/inotify/max_user_instances and /proc/sys/fs/inotify/max_user_watches. See here for more details;

https://support.scc.suse.com/s/kb/360054835111?language=en_US

I'm happy to again have offsite copies of all my events now. While they are not tracked in the Zoneminder database, they are still saved in folders by monitor id and date for easy retrieval should the ZM database become unavailable. Props to the ZM devs for their great software, and I hope this writeup proves useful to some other users in the future.

==See Also==
* https://github.com/lsyncd/lsyncd/issues/668 - Beware that lsync will do rsync with deletes on by default. With some casual testing, you might inadvertedly delete your home directory or root filesystem. From the github: "''I was told many times delete by default was a bad idea and was a result of the usual use case in the sense of replicating the target exactly like the source. I suppose the people telling so have a point.''"
* https://docs.rockylinux.org/10/books/learning_rsync/06_rsync_inotify/
* https://linuxvox.com/blog/what-is-the-proper-way-to-use-inotify/ - Using inotify-tools command line interface
* https://www.cyberciti.biz/faq/linux-inotify-examples-to-replicate-directories/ - Probably easier than lsyncd. (Was not available in default Debian Bullseye (have to use backports https://qa.debian.org/madison.php?package=incron&table=archived&a=&c=&s=#) but is in most other Debian releases.).
* https://wiki.alpinelinux.org/wiki/Inotifyd
* https://wiki.archlinux.org/title/Incron

Realtime event backup to cloud storage

2026-02-18T05:04:46Z

Kernelkurtz:

It's possible to use lsync daemon, which leverages the inotify https://en.wikipedia.org/wiki/Inotify kernel subsystem to run triggers based on events in a directory (create, modify, delete). Triggers can be varied (you can run any arbitrary command) but in the default use case, is as a filesystem backup / clone using the rsync command.

You may also want to consider other options. Inotify has command line tools, and there is an incrond, which uses cron syntax to run commands based on inotify.

==About==
After recently migrating from another popular NVR software on Windows to Zoneminder on Linux I started looking for a way to do near-real-time backups of my events to offsite storage, simply as a way to have a copy should the local ZM server be compromised by break-in, fire, etc. Software such as Dropbox, Google Drive, etc. make it relatively easy to do this on Windows but the setup on Linux takes bit more effort.

I wanted to keep it as simple as possible and don't need my backup solution to interface with the ZM database. After experimenting with several other options, I have settled on an application called lsyncd. It runs as a service and leverages inotify and rsync to watch a directory or directories and mirror only new changes to another storage location. Lsyncd should be available as a package for most Linux distributions. I used the installation instructions here for my Rocky Linux system;

https://docs.rockylinux.org/10/guides/backup/mirroring_lsyncd/

Note the version of lsyncd included in EPEL for Rocky 8 (2.2.2-9) has a noticeable memory leak. Building from source solved this issue.

At this point it is worthwhile to at least skim through the docs.

https://lsyncd.github.io/lsyncd/manual/config/file/

https://linux.die.net/man/1/rsync

Both lsyncd and rsync are highly configurable. For many people the use case will be very simple like my own which I will describe here - watch my Zoneminder storage location and copy new files to a remote location, but much more complex configurations are certainly possible. In my case I'll be writing to an Amazon S3 bucket which I have already setup using S3FS-FUSE according to the documentation here;

https://zoneminder.readthedocs.io/en/latest/userguide/options/options_storage.html

You can also use an Rclone mount point as a destination. I've tested this with Google Drive but it should work with any cloud provider supported by Rclone;

https://rclone.org/#providers

Follow the instructions here to set up your cloud storage as a local mountpoint;

https://rclone.org/commands/rclone_mount/

==Setup==

Once lsyncd is installed you will need to create a configuration file in /etc/lsyncd.conf. I've included mine as an example below. Note this file uses Lua syntax, not Bash. Be '''VERY CAREFUL''' if you are testing remote write/sync/copy operations to a destination that already has important data on it (see links below). I highly recommend initial testing with an empty bucket or target filesystem. You have been warned.

<nowiki>settings {

logfile = "/var/log/lsyncd/lsyncd.log",

statusFile = "/var/log/lsyncd/lsyncd-status.log",

statusInterval = 10,

maxProcesses = 1,

insist = true

}

sync {

default.rsync,

source = "/home/Cameras",

target = "/media/aws",

delete = false,

delay = 10,

init = false,

exclude = { 'snapshot*.jpg' , 'alarm.jpg' },

rsync = {

archive = true,

ignore_times = true,

inplace = true,

whole_file = true,

prune_empty_dirs = true

}

}</nowiki>

''logfile = '' is pretty self-explanatory. Be sure to set up log rotation after you are done setting lsyncd up, if required.

''maxProcesses = 1'' is the default. If you are syncing multiple sources or targets you may want to increase this.

''insist = true'' allows the service to start even if the target is not ready. I got errors without this which went away when I added it. YMMV.

''source = ''The directory where ZM events are stored.

''target = ''The location to copy events to. This will be the mount point for the cloud storage configured previously.

''targetdir = "/somedirectory"'' (not shown, part of sync block) subdirectory to use on the target. I'm just using the root directory in a dedicated bucket. You may not want this and should specify something here.

''delay = ''This is how often rsync will run if there are any filesystem changes. Default is 15 seconds. For many users this will be close enough to real-time for the purpose. This can be combined with (or substituted) for another value in the settings field;

''maxDelay = # '' (not shown, part of settings block) will queue this # of file changes before calling rsync. Between delay and/or maxDelay it is possible to tune the timing of your file copies to your exact preference. inotify waits for write_close to add files to the transfer list so there are no issues with rsync trying to upload uncompleted files. I typically only record short 10 second clips. If you use your cameras to continuously record be aware that files in the process of being written will not be copied until they are closed. It may be further possible to remove this limitation with the inotifyMode directive, though I have not tested this.

''exclude = { 'snapshot*.jpg' , 'alarm.jpg'}'' These are used by the Zoneminder GUI but are less useful as standalone files. I'm only interested in having backups of the videos, so not syncing these means uploading a single file per event rather than three, but this directive is of course optional. Functions like zmNinja's 24 Hour Review may create hundreds of snapshots all at once, which lsyncd will immediately sync. If you just want to exclude these dynamically generated files, use 'snapshot-*.jpg' instead of 'snapshot*.jpg' which will only catch the ones with dimensions in the filename eg.'snapshot-712x400.jpg'.

''archive = true ''This preserves ownership and permissions on the copied files.

''ignore_times = true'' This sets rsync's --ignore-times directive. For the purpose it is being used here it is safe to assume you will never have a newer copy of the files you are uploading already existing in your destination. Removing this check reduces API calls and is a noticeable optimization for AWS. If your cloud provider does not meter traffic you probably won't notice any difference with this either way.

''inplace = true'' and ''whole_file = true'' Sets these rsync options and are a further optimization for S3 API use efficiency. This makes rsync's functionality less "sync" and more straight "copy", again because we can safely assume only newly created files will ever be transferred. These options used together make this method of backing up events very close in terms of total traffic cost to natively writing to S3 straight from Zoneminder. Once again if your provider does not charge for API calls this will not matter to you.

''prune_empty_dirs = true'' Because they are watched by inotify, rsync will create empty remote directories even for events Zonmeminder deletes locally. If you are not syncing deletes you will want to use this flag, see ''delete'' below.

Two other very important variables in this file are;

''delete = false'' this is also pretty self explanatory, file deletes will not be synced from source to target. In the case of my S3 bucket I have lifecycle rules that handle this. If you prefer for your remote storage location to synchronize the deletions made by Zoneminder you can set this to true. This also means if you accidentally delete events from your local storage they will be deleted from the cloud as well. Use with caution.

''init = false'' causes the lsyncd to not do a complete initial synchronization between source and target on service startup. On S3 this is expensive in terms of API calls and may take a while. I know I'm going to miss some events during system maintenance/OS updates etc anyway so I don't consider this worth the cost, but you can set to true if you want it. Be warned it will make your target an exact mirror of your source.

Having delete and init set to false also should make this config fairly safe to use against an existing target if you just run it on your machine without heeding my previous warning. Don't change or remove these unless you are absolutely sure you know what you are doing. There are also options besides true and false so read the docs for more info. It is far too much to cover here but the simple config above is all I need for my purposes.

Once the service is configured you can control it with systemctl like any other systemd service. By default it will be disabled so you will need to enable it to run automatically after suitable testing. You can check the logs for startup or running errors with journalctl. If syncs are working correctly you can watch them as uploads are logged very shortly after the events are saved to local disk;

<nowiki>[root@nvr system]# tail -50 /var/log/lsyncd/lsyncd.log
/1/2025-12-11/8707/8707-video.mp4
/1/2025-12-11/8707/snapshot.jpg
/1/2025-12-11/8707/alarm.jpg
/6/2025-12-11/8708/
/6/2025-12-11/
/6/
/6/2025-12-11/8708/8708-video.mp4
/6/2025-12-11/8708/snapshot.jpg
/6/2025-12-11/8708/alarm.jpg
/8/2025-12-11/8706/8706-video.mp4
/8/2025-12-11/8706/
/8/2025-12-11/
/8/
Thu Dec 11 14:30:25 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:31:50 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8709/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8709/8709-video.mp4
/2/2025-12-11/8709/snapshot.jpg
/2/2025-12-11/8709/alarm.jpg
Thu Dec 11 14:32:00 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:32:04 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8710/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8710/8710-video.mp4
/2/2025-12-11/8710/snapshot.jpg
/2/2025-12-11/8710/alarm.jpg
Thu Dec 11 14:32:11 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:32:45 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8711/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8711/8711-video.mp4
/2/2025-12-11/8711/snapshot.jpg
/2/2025-12-11/8711/alarm.jpg
Thu Dec 11 14:32:51 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:37:36 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/3/2025-12-11/8712/
/3/2025-12-11/
/3/
/
/3/2025-12-11/8712/8712-video.mp4
/3/2025-12-11/8712/snapshot.jpg
/3/2025-12-11/8712/alarm.jpg
Thu Dec 11 14:37:41 2025 Normal: Finished a list after exitcode: 0
[root@nvr system]#</nowiki>

Note: If you receive errors similar to "maximum number of watches reached" in the logs you may need to increase the default limits on your system for /proc/sys/fs/inotify/max_user_instances and /proc/sys/fs/inotify/max_user_watches. See here for more details;

https://support.scc.suse.com/s/kb/360054835111?language=en_US

I'm happy to again have offsite copies of all my events now. While they are not tracked in the Zoneminder database, they are still saved in folders by monitor id and date for easy retrieval should the ZM database become unavailable. Props to the ZM devs for their great software, and I hope this writeup proves useful to some other users in the future.

==See Also==
* https://github.com/lsyncd/lsyncd/issues/668 - Beware that lsync will do rsync with deletes on by default. With some casual testing, you might inadvertedly delete your home directory or root filesystem. From the github: "''I was told many times delete by default was a bad idea and was a result of the usual use case in the sense of replicating the target exactly like the source. I suppose the people telling so have a point.''"
* https://docs.rockylinux.org/10/books/learning_rsync/06_rsync_inotify/
* https://linuxvox.com/blog/what-is-the-proper-way-to-use-inotify/ - Using inotify-tools command line interface
* https://www.cyberciti.biz/faq/linux-inotify-examples-to-replicate-directories/ - Probably easier than lsyncd. (Was not available in default Debian Bullseye (have to use backports https://qa.debian.org/madison.php?package=incron&table=archived&a=&c=&s=#) but is in most other Debian releases.).
* https://wiki.alpinelinux.org/wiki/Inotifyd
* https://wiki.archlinux.org/title/Incron

Realtime event backup to cloud storage

2026-02-18T05:04:11Z

Kernelkurtz: Added exclude snapshots

It's possible to use lsync daemon, which leverages the inotify https://en.wikipedia.org/wiki/Inotify kernel subsystem to run triggers based on events in a directory (create, modify, delete). Triggers can be varied (you can run any arbitrary command) but in the default use case, is as a filesystem backup / clone using the rsync command.

You may also want to consider other options. Inotify has command line tools, and there is an incrond, which uses cron syntax to run commands based on inotify.

==About==
After recently migrating from another popular NVR software on Windows to Zoneminder on Linux I started looking for a way to do near-real-time backups of my events to offsite storage, simply as a way to have a copy should the local ZM server be compromised by break-in, fire, etc. Software such as Dropbox, Google Drive, etc. make it relatively easy to do this on Windows but the setup on Linux takes bit more effort.

I wanted to keep it as simple as possible and don't need my backup solution to interface with the ZM database. After experimenting with several other options, I have settled on an application called lsyncd. It runs as a service and leverages inotify and rsync to watch a directory or directories and mirror only new changes to another storage location. Lsyncd should be available as a package for most Linux distributions. I used the installation instructions here for my Rocky Linux system;

https://docs.rockylinux.org/10/guides/backup/mirroring_lsyncd/

Note the version of lsyncd included in EPEL for Rocky 8 (2.2.2-9) has a noticeable memory leak. Building from source solved this issue.

At this point it is worthwhile to at least skim through the docs.

https://lsyncd.github.io/lsyncd/manual/config/file/

https://linux.die.net/man/1/rsync

Both lsyncd and rsync are highly configurable. For many people the use case will be very simple like my own which I will describe here - watch my Zoneminder storage location and copy new files to a remote location, but much more complex configurations are certainly possible. In my case I'll be writing to an Amazon S3 bucket which I have already setup using S3FS-FUSE according to the documentation here;

https://zoneminder.readthedocs.io/en/latest/userguide/options/options_storage.html

You can also use an Rclone mount point as a destination. I've tested this with Google Drive but it should work with any cloud provider supported by Rclone;

https://rclone.org/#providers

Follow the instructions here to set up your cloud storage as a local mountpoint;

https://rclone.org/commands/rclone_mount/

==Setup==

Once lsyncd is installed you will need to create a configuration file in /etc/lsyncd.conf. I've included mine as an example below. Note this file uses Lua syntax, not Bash. Be '''VERY CAREFUL''' if you are testing remote write/sync/copy operations to a destination that already has important data on it (see links below). I highly recommend initial testing with an empty bucket or target filesystem. You have been warned.

<nowiki>settings {

logfile = "/var/log/lsyncd/lsyncd.log",

statusFile = "/var/log/lsyncd/lsyncd-status.log",

statusInterval = 10,

maxProcesses = 1,

insist = true

}

sync {

default.rsync,

source = "/home/Cameras",

target = "/media/aws",

delete = false,

delay = 10,

init = false,

exclude = { 'snapshot*.jpg' , 'alarm.jpg'},

rsync = {

archive = true,

ignore_times = true,

inplace = true,

whole_file = true,

prune_empty_dirs = true

}

}</nowiki>

''logfile = '' is pretty self-explanatory. Be sure to set up log rotation after you are done setting lsyncd up, if required.

''maxProcesses = 1'' is the default. If you are syncing multiple sources or targets you may want to increase this.

''insist = true'' allows the service to start even if the target is not ready. I got errors without this which went away when I added it. YMMV.

''source = ''The directory where ZM events are stored.

''target = ''The location to copy events to. This will be the mount point for the cloud storage configured previously.

''targetdir = "/somedirectory"'' (not shown, part of sync block) subdirectory to use on the target. I'm just using the root directory in a dedicated bucket. You may not want this and should specify something here.

''delay = ''This is how often rsync will run if there are any filesystem changes. Default is 15 seconds. For many users this will be close enough to real-time for the purpose. This can be combined with (or substituted) for another value in the settings field;

''maxDelay = # '' (not shown, part of settings block) will queue this # of file changes before calling rsync. Between delay and/or maxDelay it is possible to tune the timing of your file copies to your exact preference. inotify waits for write_close to add files to the transfer list so there are no issues with rsync trying to upload uncompleted files. I typically only record short 10 second clips. If you use your cameras to continuously record be aware that files in the process of being written will not be copied until they are closed. It may be further possible to remove this limitation with the inotifyMode directive, though I have not tested this.

''exclude = { 'snapshot*.jpg' , 'alarm.jpg'}'' These are used by the Zoneminder GUI but are less useful as standalone files. I'm only interested in having backups of the videos, so not syncing these means uploading a single file per event rather than three, but this directive is of course optional. Functions like zmNinja's 24 Hour Review may create hundreds of snapshots all at once, which lsyncd will immediately sync. If you just want to exclude these dynamically generated files, use 'snapshot-*.jpg' instead of 'snapshot*.jpg' which will only catch the ones with dimensions in the filename eg.'snapshot-712x400.jpg'.

''archive = true ''This preserves ownership and permissions on the copied files.

''ignore_times = true'' This sets rsync's --ignore-times directive. For the purpose it is being used here it is safe to assume you will never have a newer copy of the files you are uploading already existing in your destination. Removing this check reduces API calls and is a noticeable optimization for AWS. If your cloud provider does not meter traffic you probably won't notice any difference with this either way.

''inplace = true'' and ''whole_file = true'' Sets these rsync options and are a further optimization for S3 API use efficiency. This makes rsync's functionality less "sync" and more straight "copy", again because we can safely assume only newly created files will ever be transferred. These options used together make this method of backing up events very close in terms of total traffic cost to natively writing to S3 straight from Zoneminder. Once again if your provider does not charge for API calls this will not matter to you.

''prune_empty_dirs = true'' Because they are watched by inotify, rsync will create empty remote directories even for events Zonmeminder deletes locally. If you are not syncing deletes you will want to use this flag, see ''delete'' below.

Two other very important variables in this file are;

''delete = false'' this is also pretty self explanatory, file deletes will not be synced from source to target. In the case of my S3 bucket I have lifecycle rules that handle this. If you prefer for your remote storage location to synchronize the deletions made by Zoneminder you can set this to true. This also means if you accidentally delete events from your local storage they will be deleted from the cloud as well. Use with caution.

''init = false'' causes the lsyncd to not do a complete initial synchronization between source and target on service startup. On S3 this is expensive in terms of API calls and may take a while. I know I'm going to miss some events during system maintenance/OS updates etc anyway so I don't consider this worth the cost, but you can set to true if you want it. Be warned it will make your target an exact mirror of your source.

Having delete and init set to false also should make this config fairly safe to use against an existing target if you just run it on your machine without heeding my previous warning. Don't change or remove these unless you are absolutely sure you know what you are doing. There are also options besides true and false so read the docs for more info. It is far too much to cover here but the simple config above is all I need for my purposes.

Once the service is configured you can control it with systemctl like any other systemd service. By default it will be disabled so you will need to enable it to run automatically after suitable testing. You can check the logs for startup or running errors with journalctl. If syncs are working correctly you can watch them as uploads are logged very shortly after the events are saved to local disk;

<nowiki>[root@nvr system]# tail -50 /var/log/lsyncd/lsyncd.log
/1/2025-12-11/8707/8707-video.mp4
/1/2025-12-11/8707/snapshot.jpg
/1/2025-12-11/8707/alarm.jpg
/6/2025-12-11/8708/
/6/2025-12-11/
/6/
/6/2025-12-11/8708/8708-video.mp4
/6/2025-12-11/8708/snapshot.jpg
/6/2025-12-11/8708/alarm.jpg
/8/2025-12-11/8706/8706-video.mp4
/8/2025-12-11/8706/
/8/2025-12-11/
/8/
Thu Dec 11 14:30:25 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:31:50 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8709/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8709/8709-video.mp4
/2/2025-12-11/8709/snapshot.jpg
/2/2025-12-11/8709/alarm.jpg
Thu Dec 11 14:32:00 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:32:04 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8710/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8710/8710-video.mp4
/2/2025-12-11/8710/snapshot.jpg
/2/2025-12-11/8710/alarm.jpg
Thu Dec 11 14:32:11 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:32:45 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8711/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8711/8711-video.mp4
/2/2025-12-11/8711/snapshot.jpg
/2/2025-12-11/8711/alarm.jpg
Thu Dec 11 14:32:51 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:37:36 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/3/2025-12-11/8712/
/3/2025-12-11/
/3/
/
/3/2025-12-11/8712/8712-video.mp4
/3/2025-12-11/8712/snapshot.jpg
/3/2025-12-11/8712/alarm.jpg
Thu Dec 11 14:37:41 2025 Normal: Finished a list after exitcode: 0
[root@nvr system]#</nowiki>

Note: If you receive errors similar to "maximum number of watches reached" in the logs you may need to increase the default limits on your system for /proc/sys/fs/inotify/max_user_instances and /proc/sys/fs/inotify/max_user_watches. See here for more details;

https://support.scc.suse.com/s/kb/360054835111?language=en_US

I'm happy to again have offsite copies of all my events now. While they are not tracked in the Zoneminder database, they are still saved in folders by monitor id and date for easy retrieval should the ZM database become unavailable. Props to the ZM devs for their great software, and I hope this writeup proves useful to some other users in the future.

==See Also==
* https://github.com/lsyncd/lsyncd/issues/668 - Beware that lsync will do rsync with deletes on by default. With some casual testing, you might inadvertedly delete your home directory or root filesystem. From the github: "''I was told many times delete by default was a bad idea and was a result of the usual use case in the sense of replicating the target exactly like the source. I suppose the people telling so have a point.''"
* https://docs.rockylinux.org/10/books/learning_rsync/06_rsync_inotify/
* https://linuxvox.com/blog/what-is-the-proper-way-to-use-inotify/ - Using inotify-tools command line interface
* https://www.cyberciti.biz/faq/linux-inotify-examples-to-replicate-directories/ - Probably easier than lsyncd. (Was not available in default Debian Bullseye (have to use backports https://qa.debian.org/madison.php?package=incron&table=archived&a=&c=&s=#) but is in most other Debian releases.).
* https://wiki.alpinelinux.org/wiki/Inotifyd
* https://wiki.archlinux.org/title/Incron

Realtime event backup to cloud storage

2026-01-15T03:25:29Z

Kernelkurtz: Remove unnecessary option compress

It's possible to use lsync daemon, which leverages the inotify https://en.wikipedia.org/wiki/Inotify kernel subsystem to run triggers based on events in a directory (create, modify, delete). Triggers can be varied (you can run any arbitrary command) but in the default use case, is as a filesystem backup / clone using the rsync command.

You may also want to consider other options. Inotify has command line tools, and there is an incrond, which uses cron syntax to run commands based on inotify.

==About==
After recently migrating from another popular NVR software on Windows to Zoneminder on Linux I started looking for a way to do near-real-time backups of my events to offsite storage, simply as a way to have a copy should the local ZM server be compromised by break-in, fire, etc. Software such as Dropbox, Google Drive, etc. make it relatively easy to do this on Windows but the setup on Linux takes bit more effort.

I wanted to keep it as simple as possible and don't need my backup solution to interface with the ZM database. After experimenting with several other options, I have settled on an application called lsyncd. It runs as a service and leverages inotify and rsync to watch a directory or directories and mirror only new changes to another storage location. Lsyncd should be available as a package for most Linux distributions. I used the installation instructions here for my Rocky Linux system;

https://docs.rockylinux.org/10/guides/backup/mirroring_lsyncd/

Note the version of lsyncd included in EPEL for Rocky 8 (2.2.2-9) has a noticeable memory leak. Building from source solved this issue.

At this point it is worthwhile to at least skim through the docs.

https://lsyncd.github.io/lsyncd/manual/config/file/

https://linux.die.net/man/1/rsync

Both lsyncd and rsync are highly configurable. For many people the use case will be very simple like my own which I will describe here - watch my Zoneminder storage location and copy new files to a remote location, but much more complex configurations are certainly possible. In my case I'll be writing to an Amazon S3 bucket which I have already setup using S3FS-FUSE according to the documentation here;

https://zoneminder.readthedocs.io/en/latest/userguide/options/options_storage.html

You can also use an Rclone mount point as a destination. I've tested this with Google Drive but it should work with any cloud provider supported by Rclone;

https://rclone.org/#providers

Follow the instructions here to set up your cloud storage as a local mountpoint;

https://rclone.org/commands/rclone_mount/

==Setup==

Once lsyncd is installed you will need to create a configuration file in /etc/lsyncd.conf. I've included mine as an example below. Note this file uses Lua syntax, not Bash. Be '''VERY CAREFUL''' if you are testing remote write/sync/copy operations to a destination that already has important data on it (see links below). I highly recommend initial testing with an empty bucket or target filesystem. You have been warned.

<nowiki>settings {

logfile = "/var/log/lsyncd/lsyncd.log",

statusFile = "/var/log/lsyncd/lsyncd-status.log",

statusInterval = 10,

maxProcesses = 1,

insist = true

}

sync {

default.rsync,

source = "/home/Cameras",

target = "/media/aws",

delete = false,

delay = 10,

init = false,

rsync = {

archive = true,

ignore_times = true,

inplace = true,

whole_file = true,

prune_empty_dirs = true

}

}</nowiki>

''logfile = '' is pretty self-explanatory. Be sure to set up log rotation after you are done setting lsyncd up, if required.

''maxProcesses = 1'' is the default. If you are syncing multiple sources or targets you may want to increase this.

''insist = true'' allows the service to start even if the target is not ready. I got errors without this which went away when I added it. YMMV.

''source = ''The directory where ZM events are stored.

''target = ''The location to copy events to. This will be the mount point for the cloud storage configured previously.

''targetdir = "/somedirectory"'' (not shown, part of sync block) subdirectory to use on the target. I'm just using the root directory in a dedicated bucket. You may not want this and should specify something here.

''delay = ''This is how often rsync will run if there are any filesystem changes. Default is 15 seconds. For many users this will be close enough to real-time for the purpose. This can be combined with (or substituted) for another value in the settings field;

''maxDelay = # '' (not shown, part of settings block) will queue this # of file changes before calling rsync. Between delay and/or maxDelay it is possible to tune the timing of your file copies to your exact preference. inotify waits for write_close to add files to the transfer list so there are no issues with rsync trying to upload uncompleted files. I typically only record short 10 second clips. If you use your cameras to continuously record be aware that files in the process of being written will not be copied until they are closed. It may be further possible to remove this limitation with the inotifyMode directive, though I have not tested this.

''archive = true ''This preserves ownership and permissions on the copied files.

''ignore_times = true'' This sets rsync's --ignore-times directive. For the purpose it is being used here it is safe to assume you will never have a newer copy of the files you are uploading already existing in your destination. Removing this check reduces API calls and is a noticeable optimization for AWS. If your cloud provider does not meter traffic you probably won't notice any difference with this either way.

''inplace = true'' and ''whole_file = true'' Sets these rsync options and are a further optimization for S3 API use efficiency. This makes rsync's functionality less "sync" and more straight "copy", again because we can safely assume only newly created files will ever be transferred. These options used together make this method of backing up events very close in terms of total traffic cost to natively writing to S3 straight from Zoneminder. Once again if your provider does not charge for API calls this will not matter to you.

''prune_empty_dirs = true'' Because they are watched by inotify, rsync will create empty remote directories even for events Zonmeminder deletes locally. If you are not syncing deletes you will want to use this flag, see ''delete'' below.

Two other very important variables in this file are;

''delete = false'' this is also pretty self explanatory, file deletes will not be synced from source to target. In the case of my S3 bucket I have lifecycle rules that handle this. If you prefer for your remote storage location to synchronize the deletions made by Zoneminder you can set this to true. This also means if you accidentally delete events from your local storage they will be deleted from the cloud as well. Use with caution.

''init = false'' causes the lsyncd to not do a complete initial synchronization between source and target on service startup. On S3 this is expensive in terms of API calls and may take a while. I know I'm going to miss some events during system maintenance/OS updates etc anyway so I don't consider this worth the cost, but you can set to true if you want it. Be warned it will make your target an exact mirror of your source.

Having delete and init set to false also should make this config fairly safe to use against an existing target if you just run it on your machine without heeding my previous warning. Don't change or remove these unless you are absolutely sure you know what you are doing. There are also options besides true and false so read the docs for more info. You can also add options to be added directly to the rsync calls. You can sync multiple directories to multiple targets with multiple options. There are exclude options which you may find useful. It is far too much to cover here but the simple config above is all I need for my purposes.

Once the service is configured you can control it with systemctl like any other systemd service. By default it will be disabled so you will need to enable it to run automatically after suitable testing. You can check the logs for startup or running errors with journalctl. If syncs are working correctly you can watch them as uploads are logged very shortly after the events are saved to local disk;

<nowiki>[root@nvr system]# tail -50 /var/log/lsyncd/lsyncd.log
/1/2025-12-11/8707/8707-video.mp4
/1/2025-12-11/8707/snapshot.jpg
/1/2025-12-11/8707/alarm.jpg
/6/2025-12-11/8708/
/6/2025-12-11/
/6/
/6/2025-12-11/8708/8708-video.mp4
/6/2025-12-11/8708/snapshot.jpg
/6/2025-12-11/8708/alarm.jpg
/8/2025-12-11/8706/8706-video.mp4
/8/2025-12-11/8706/
/8/2025-12-11/
/8/
Thu Dec 11 14:30:25 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:31:50 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8709/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8709/8709-video.mp4
/2/2025-12-11/8709/snapshot.jpg
/2/2025-12-11/8709/alarm.jpg
Thu Dec 11 14:32:00 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:32:04 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8710/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8710/8710-video.mp4
/2/2025-12-11/8710/snapshot.jpg
/2/2025-12-11/8710/alarm.jpg
Thu Dec 11 14:32:11 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:32:45 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8711/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8711/8711-video.mp4
/2/2025-12-11/8711/snapshot.jpg
/2/2025-12-11/8711/alarm.jpg
Thu Dec 11 14:32:51 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:37:36 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/3/2025-12-11/8712/
/3/2025-12-11/
/3/
/
/3/2025-12-11/8712/8712-video.mp4
/3/2025-12-11/8712/snapshot.jpg
/3/2025-12-11/8712/alarm.jpg
Thu Dec 11 14:37:41 2025 Normal: Finished a list after exitcode: 0
[root@nvr system]#</nowiki>

Note: If you receive errors similar to "maximum number of watches reached" in the logs you may need to increase the default limits on your system for /proc/sys/fs/inotify/max_user_instances and /proc/sys/fs/inotify/max_user_watches. See here for more details;

https://support.scc.suse.com/s/kb/360054835111?language=en_US

I'm happy to again have offsite copies of all my events now. While they are not tracked in the Zoneminder database, they are still saved in folders by monitor id and date for easy retrieval should the ZM database become unavailable. Props to the ZM devs for their great software, and I hope this writeup proves useful to some other users in the future.

==See Also==
* https://github.com/lsyncd/lsyncd/issues/668 - Beware that lsync will do rsync with deletes on by default. With some casual testing, you might inadvertedly delete your home directory or root filesystem. From the github: "''I was told many times delete by default was a bad idea and was a result of the usual use case in the sense of replicating the target exactly like the source. I suppose the people telling so have a point.''"
* https://docs.rockylinux.org/10/books/learning_rsync/06_rsync_inotify/
* https://linuxvox.com/blog/what-is-the-proper-way-to-use-inotify/ - Using inotify-tools command line interface
* https://www.cyberciti.biz/faq/linux-inotify-examples-to-replicate-directories/ - Probably easier than lsyncd. (Was not available in default Debian Bullseye (have to use backports https://qa.debian.org/madison.php?package=incron&table=archived&a=&c=&s=#) but is in most other Debian releases.).
* https://wiki.alpinelinux.org/wiki/Inotifyd
* https://wiki.archlinux.org/title/Incron

Multi Port

2026-01-14T17:29:01Z

Kernelkurtz:

All browsers currently have a limitation where there can only be 6 connections to a server. This can be gotten around by using multi port, or by adjusting a Firefox about:config setting.

==Apache Settings for Multi Port==
This is the optimal approach as it will work on any browser. If you are in a commercial setting, or have other users besides yourself, it is almost required to setup Multi Port through Apache. If on the other hand you are on your own, you may consider simply using Firefox. Multi port, does just what it says: It will redirect multiple server connections through different ports, which is a workaround for the browser security limitation.

Here are some quick configs for 50 cameras. Note: The below config has been confirmed to work with only HTTP. HTTPS may need additional configuration. If you get an error about missing a > bracket on the 000-default.conf, make it so all these _default_:#### are on one line. Then it will work. It's not easy to read it in that format, so it has been justified for viewing here.

====/etc/apache2/sites-available/000-default.conf:====
<pre>
<VirtualHost _default_:80 _default_:30000
_default_:30001 _default_:30002 _default_:30003 _default_:30004
_default_:30005 _default_:30006 _default_:30007 _default_:30008 _default_:30009 _default_:30010
_default_:30011 _default_:30012 _default_:30013 _default_:30014
_default_:30015 _default_:30016 _default_:30017 _default_:30018
_default_:30019 _default_:30020 _default_:30021 _default_:30022
_default_:30023 _default_:30024 _default_:30025 _default_:30026
_default_:30027 _default_:30028 _default_:30029 _default_:30030
_default_:30031 _default_:30032 _default_:30033 _default_:30034
_default_:30035 _default_:30036 _default_:30037 _default_:30038
_default_:30039 _default_:30040 _default_:30041 _default_:30042
_default_:30043 _default_:30044 _default_:30045 _default_:30046
_default_:30047 _default_:30048 _default_:30049 _default_:30050>
</pre>

====/etc/apache2/ports.conf:====
Note:this doesn't include everything in the file. Make sure to insert into the existing ports file where changes are appropriate and not simply clobber the original file with below.
<pre>
Listen 80
Listen 30000
Listen 30001
Listen 30002
Listen 30003
Listen 30004
Listen 30005
Listen 30006
Listen 30007
Listen 30008
Listen 30009
Listen 30010
Listen 30011
Listen 30012
Listen 30013
Listen 30014
Listen 30015
Listen 30016
Listen 30017
Listen 30018
Listen 30019
Listen 30020
Listen 30021
Listen 30022
Listen 30023
Listen 30024
Listen 30025
Listen 30026
Listen 30027
Listen 30028
Listen 30029
Listen 30030
Listen 30031
Listen 30032
Listen 30033
Listen 30034
Listen 30035
Listen 30036
Listen 30037
Listen 30038
Listen 30039
Listen 30040
Listen 30041
Listen 30042
Listen 30043
Listen 30044
Listen 30045
Listen 30046
Listen 30047
Listen 30048
Listen 30049
Listen 30050
</pre>

You will also need to enable multi port in Zoneminder options. Please read the medium guide below for more information.

===Resources===
* https://medium.com/zmninja/multi-port-storage-areas-and-more-d5836a336c93 - A developer of Zoneminder wrote up this helpful guide.

==Firefox About:Config==

In Firefox you can make a change to the configuration to get cameras to display. First go to [https://support.mozilla.org/en-US/kb/about-config-editor-firefox about:config ]. And search for, then adjust [http://kb.mozillazine.org/Network.http.max-persistent-connections-per-server Network.http.max-persistent-connections-per-server]. The max persistent connections per server must be > 6 in order to see > 6 camera streams. It can be set to any number, so perhaps you might set it to 100 or 150.

[[File:Firefox About Config Edit.png|900px|||]]

===Resources===
The forum will have a number of posts regarding this change. It has been discussed extensively. Such as:
* [https://forums.zoneminder.com/viewtopic.php?f=32&t=23417&p=89249 ZM Forums: Problems when two people are watching live]

[[Category:Dummies_Guide]]

==Alternative firewall based method==

If you are unable or prefer not to modify your webserver configuration, you can also use Linux firewall functionality to redirect a range of incoming high ports to the configured webserver listening port. This will work with both Apache and Nginx based Zoneminder installs.

The following rules are are for iptables firewalls and are working on my RHEL based server. If you use another firewall or frontend such as nftables, firewalld, ufw, etc., you will have to translate them accordingly. AI is very helpful for tasks such as this.

<pre>iptables -t nat -A PREROUTING -p tcp -m multiport --dports 30000:30100 -j REDIRECT --to-ports 443</pre>

If you are running a headless Zoneminder install the above rule is all you will need. Replace 30000:30100 with the range of ports you want to redirect. Of course this has to match the multiport starting port in Zoneminder's network settings. You can also use port 80 as destination if you don't use https, or whatever other port your webserver listens on. You can quickly check it is working by browsing to http(s)://yourzomeminderserver:30099 (or some other redirected port).

If your ZM server has a graphical Linux install and a directly connected display, you will also need some additional configuration to make this work as localhost traffic does not use the same prerouting rules. First you need to enable routing on the localnet network. Only do this if you trust the other devices on your local LAN, don't do this if you connect directly to the internet. Add the following line to /etc/sysctl.conf (or the appropriate location for your distribution).

<pre>net.ipv4.conf.all.route_localnet = 1</pre>

You can apply it immediately with sysctl -p. Then you need to add a second firewall rule to redirect the loopback address ports. Use the same port range and destination port as the previous rule.

<pre>iptables -t nat -I OUTPUT -p tcp -o lo --dport 30000:30100 -j REDIRECT --to-ports 443</pre>

That's it. Be sure to make any rules you add persistent across reboots with whatever firewall management method you are using.

Realtime event backup to cloud storage

2026-01-14T04:57:45Z

Kernelkurtz:

It's possible to use lsync daemon, which leverages the inotify https://en.wikipedia.org/wiki/Inotify kernel subsystem to run triggers based on events in a directory (create, modify, delete). Triggers can be varied (you can run any arbitrary command) but in the default use case, is as a filesystem backup / clone using the rsync command.

You may also want to consider other options. Inotify has command line tools, and there is an incrond, which uses cron syntax to run commands based on inotify.

==About==
After recently migrating from another popular NVR software on Windows to Zoneminder on Linux I started looking for a way to do near-real-time backups of my events to offsite storage, simply as a way to have a copy should the local ZM server be compromised by break-in, fire, etc. Software such as Dropbox, Google Drive, etc. make it relatively easy to do this on Windows but the setup on Linux takes bit more effort.

I wanted to keep it as simple as possible and don't need my backup solution to interface with the ZM database. After experimenting with several other options, I have settled on an application called lsyncd. It runs as a service and leverages inotify and rsync to watch a directory or directories and mirror only new changes to another storage location. Lsyncd should be available as a package for most Linux distributions. I used the installation instructions here for my Rocky Linux system;

https://docs.rockylinux.org/10/guides/backup/mirroring_lsyncd/

Note the version of lsyncd included in EPEL for Rocky 8 (2.2.2-9) has a noticeable memory leak. Building from source solved this issue.

At this point it is worthwhile to at least skim through the docs.

https://lsyncd.github.io/lsyncd/manual/config/file/

https://linux.die.net/man/1/rsync

Both lsyncd and rsync are highly configurable. For many people the use case will be very simple like my own which I will describe here - watch my Zoneminder storage location and copy new files to a remote location, but much more complex configurations are certainly possible. In my case I'll be writing to an Amazon S3 bucket which I have already setup using S3FS-FUSE according to the documentation here;

https://zoneminder.readthedocs.io/en/latest/userguide/options/options_storage.html

You can also use an Rclone mount point as a destination. I've tested this with Google Drive but it should work with any cloud provider supported by Rclone;

https://rclone.org/#providers

Follow the instructions here to set up your cloud storage as a local mountpoint;

https://rclone.org/commands/rclone_mount/

==Setup==

Once lsyncd is installed you will need to create a configuration file in /etc/lsyncd.conf. I've included mine as an example below. Note this file uses Lua syntax, not Bash. Be '''VERY CAREFUL''' if you are testing remote write/sync/copy operations to a destination that already has important data on it (see links below). I highly recommend initial testing with an empty bucket or target filesystem. You have been warned.

<nowiki>settings {

logfile = "/var/log/lsyncd/lsyncd.log",

statusFile = "/var/log/lsyncd/lsyncd-status.log",

statusInterval = 10,

maxProcesses = 1,

insist = true,

}

sync {

default.rsync,

source = "/home/Cameras",

target = "/media/aws",

delete = false,

delay = 10,

init = false,

rsync = {

archive = true,

ignore_times = true,

inplace = true,

whole_file = true,

prune_empty_dirs = true,

compress = false

}

}</nowiki>

''logfile = '' is pretty self-explanatory. Be sure to set up log rotation after you are done setting lsyncd up, if required.

''maxProcesses = 1'' is the default. If you are syncing multiple sources or targets you may want to increase this.

''insist = true'' allows the service to start even if the target is not ready. I got errors without this which went away when I added it. YMMV.

''source = ''The directory where ZM events are stored.

''target = ''The location to copy events to. This will be the mount point for the cloud storage configured previously.

''targetdir = "/somedirectory"'' (not shown, part of sync block) subdirectory to use on the target. I'm just using the root directory in a dedicated bucket. You may not want this and should specify something here.

''delay = ''This is how often rsync will run if there are any filesystem changes. Default is 15 seconds. For many users this will be close enough to real-time for the purpose. This can be combined with (or substituted) for another value in the settings field;

''maxDelay = # '' (not shown, part of settings block) will queue this # of file changes before calling rsync. Between delay and/or maxDelay it is possible to tune the timing of your file copies to your exact preference. inotify waits for write_close to add files to the transfer list so there are no issues with rsync trying to upload uncompleted files. I typically only record short 10 second clips. If you use your cameras to continuously record be aware that files in the process of being written will not be copied until they are closed. It may be further possible to remove this limitation with the inotifyMode directive, though I have not tested this.

''archive = true ''This preserves ownership and permissions on the copied files.

''ignore_times = true'' This sets rsync's --ignore-times directive. For the purpose it is being used here it is safe to assume you will never have a newer copy of the files you are uploading already existing in your destination. Removing this check reduces API calls and is a noticeable optimization for AWS. If your cloud provider does not meter traffic you probably won't notice any difference with this either way.

''inplace = true'' and ''whole_file = true'' Sets these rsync options and are a further optimization for S3 API use efficiency. This makes rsync's functionality less "sync" and more straight "copy", again because we can safely assume only newly created files will ever be transferred. These options used together make this method of backing up events very close in terms of total traffic cost to natively writing to S3 straight from Zoneminder. Once again if your provider does not charge for API calls this will not matter to you.

''prune_empty_dirs = true'' Because they are watched by inotify, rsync will create empty remote directories even for events Zonmeminder deletes locally. If you are not syncing deletes you will want to use this flag, see ''delete'' below.

Two other very important variables in this file are;

''delete = false'' this is also pretty self explanatory, file deletes will not be synced from source to target. In the case of my S3 bucket I have lifecycle rules that handle this. If you prefer for your remote storage location to synchronize the deletions made by Zoneminder you can set this to true. This also means if you accidentally delete events from your local storage they will be deleted from the cloud as well. Use with caution.

''init = false'' causes the lsyncd to not do a complete initial synchronization between source and target on service startup. On S3 this is expensive in terms of API calls and may take a while. I know I'm going to miss some events during system maintenance/OS updates etc anyway so I don't consider this worth the cost, but you can set to true if you want it. Be warned it will make your target an exact mirror of your source.

Having delete and init set to false also should make this config fairly safe to use against an existing target if you just run it on your machine without heeding my previous warning. Don't change or remove these unless you are absolutely sure you know what you are doing. There are also options besides true and false so read the docs for more info. You can also add options to be added directly to the rsync calls. You can sync multiple directories to multiple targets with multiple options. There are exclude options which you may find useful. It is far too much to cover here but the simple config above is all I need for my purposes.

Once the service is configured you can control it with systemctl like any other systemd service. By default it will be disabled so you will need to enable it to run automatically after suitable testing. You can check the logs for startup or running errors with journalctl. If syncs are working correctly you can watch them as uploads are logged very shortly after the events are saved to local disk;

<nowiki>[root@nvr system]# tail -50 /var/log/lsyncd/lsyncd.log
/1/2025-12-11/8707/8707-video.mp4
/1/2025-12-11/8707/snapshot.jpg
/1/2025-12-11/8707/alarm.jpg
/6/2025-12-11/8708/
/6/2025-12-11/
/6/
/6/2025-12-11/8708/8708-video.mp4
/6/2025-12-11/8708/snapshot.jpg
/6/2025-12-11/8708/alarm.jpg
/8/2025-12-11/8706/8706-video.mp4
/8/2025-12-11/8706/
/8/2025-12-11/
/8/
Thu Dec 11 14:30:25 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:31:50 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8709/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8709/8709-video.mp4
/2/2025-12-11/8709/snapshot.jpg
/2/2025-12-11/8709/alarm.jpg
Thu Dec 11 14:32:00 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:32:04 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8710/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8710/8710-video.mp4
/2/2025-12-11/8710/snapshot.jpg
/2/2025-12-11/8710/alarm.jpg
Thu Dec 11 14:32:11 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:32:45 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8711/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8711/8711-video.mp4
/2/2025-12-11/8711/snapshot.jpg
/2/2025-12-11/8711/alarm.jpg
Thu Dec 11 14:32:51 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:37:36 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/3/2025-12-11/8712/
/3/2025-12-11/
/3/
/
/3/2025-12-11/8712/8712-video.mp4
/3/2025-12-11/8712/snapshot.jpg
/3/2025-12-11/8712/alarm.jpg
Thu Dec 11 14:37:41 2025 Normal: Finished a list after exitcode: 0
[root@nvr system]#</nowiki>

Note: If you receive errors similar to "maximum number of watches reached" in the logs you may need to increase the default limits on your system for /proc/sys/fs/inotify/max_user_instances and /proc/sys/fs/inotify/max_user_watches. See here for more details;

https://support.scc.suse.com/s/kb/360054835111?language=en_US

I'm happy to again have offsite copies of all my events now. While they are not tracked in the Zoneminder database, they are still saved in folders by monitor id and date for easy retrieval should the ZM database become unavailable. Props to the ZM devs for their great software, and I hope this writeup proves useful to some other users in the future.

==See Also==
* https://github.com/lsyncd/lsyncd/issues/668 - Beware that lsync will do rsync with deletes on by default. With some casual testing, you might inadvertedly delete your home directory or root filesystem. From the github: "''I was told many times delete by default was a bad idea and was a result of the usual use case in the sense of replicating the target exactly like the source. I suppose the people telling so have a point.''"
* https://docs.rockylinux.org/10/books/learning_rsync/06_rsync_inotify/
* https://linuxvox.com/blog/what-is-the-proper-way-to-use-inotify/ - Using inotify-tools command line interface
* https://www.cyberciti.biz/faq/linux-inotify-examples-to-replicate-directories/ - Probably easier than lsyncd. (Was not available in default Debian Bullseye (have to use backports https://qa.debian.org/madison.php?package=incron&table=archived&a=&c=&s=#) but is in most other Debian releases.).
* https://wiki.alpinelinux.org/wiki/Inotifyd
* https://wiki.archlinux.org/title/Incron

Realtime event backup to cloud storage

2026-01-14T04:55:18Z

Kernelkurtz: Added prune empty dirs flag

It's possible to use lsync daemon, which leverages the inotify https://en.wikipedia.org/wiki/Inotify kernel subsystem to run triggers based on events in a directory (create, modify, delete). Triggers can be varied (you can run any arbitrary command) but in the default use case, is as a filesystem backup / clone using the rsync command.

You may also want to consider other options. Inotify has command line tools, and there is an incrond, which uses cron syntax to run commands based on inotify.

==About==
After recently migrating from another popular NVR software on Windows to Zoneminder on Linux I started looking for a way to do near-real-time backups of my events to offsite storage, simply as a way to have a copy should the local ZM server be compromised by break-in, fire, etc. Software such as Dropbox, Google Drive, etc. make it relatively easy to do this on Windows but the setup on Linux takes bit more effort.

I wanted to keep it as simple as possible and don't need my backup solution to interface with the ZM database. After experimenting with several other options, I have settled on an application called lsyncd. It runs as a service and leverages inotify and rsync to watch a directory or directories and mirror only new changes to another storage location. Lsyncd should be available as a package for most Linux distributions. I used the installation instructions here for my Rocky Linux system;

https://docs.rockylinux.org/10/guides/backup/mirroring_lsyncd/

Note the version of lsyncd included in EPEL for Rocky 8 (2.2.2-9) has a noticeable memory leak. Building from source solved this issue.

At this point it is worthwhile to at least skim through the docs.

https://lsyncd.github.io/lsyncd/manual/config/file/

https://linux.die.net/man/1/rsync

Both lsyncd and rsync are highly configurable. For many people the use case will be very simple like my own which I will describe here - watch my Zoneminder storage location and copy new files to a remote location, but much more complex configurations are certainly possible. In my case I'll be writing to an Amazon S3 bucket which I have already setup using S3FS-FUSE according to the documentation here;

https://zoneminder.readthedocs.io/en/latest/userguide/options/options_storage.html

You can also use an Rclone mount point as a destination. I've tested this with Google Drive but it should work with any cloud provider supported by Rclone;

https://rclone.org/#providers

Follow the instructions here to set up your cloud storage as a local mountpoint;

https://rclone.org/commands/rclone_mount/

==Setup==

Once lsyncd is installed you will need to create a configuration file in /etc/lsyncd.conf. I've included mine as an example below. Note this file uses Lua syntax, not Bash. Be '''VERY CAREFUL''' if you are testing remote write/sync/copy operations to a destination that already has important data on it (see links below). I highly recommend initial testing with an empty bucket or target filesystem. You have been warned.

<nowiki>settings {

logfile = "/var/log/lsyncd/lsyncd.log",

statusFile = "/var/log/lsyncd/lsyncd-status.log",

statusInterval = 10,

maxProcesses = 1,

insist = true,

}

sync {

default.rsync,

source = "/home/Cameras",

target = "/media/aws",

delete = false,

delay = 10,

init = false,

rsync = {

archive = true,

ignore_times = true,

inplace = true,

whole_file = true,

prune_empty_dirs = true,

compress = false

}

}</nowiki>

''logfile = '' is pretty self-explanatory. Be sure to set up log rotation after you are done setting lsyncd up, if required.

''maxProcesses = 1'' is the default. If you are syncing multiple sources or targets you may want to increase this.

''insist = true'' allows the service to start even if the target is not ready. I got errors without this which went away when I added it. YMMV.

''source = ''The directory where ZM events are stored.

''target = ''The location to copy events to. This will be the mount point for the cloud storage configured previously.

''targetdir = "/somedirectory"'' (not shown, part of sync block) subdirectory to use on the target. I'm just using the root directory in a dedicated bucket. You may not want this and should specify something here.

''delay = ''This is how often rsync will run if there are any filesystem changes. Default is 15 seconds. For many users this will be close enough to real-time for the purpose. This can be combined with (or substituted) for another value in the settings field;

''maxDelay = # '' (not shown, part of settings block) will queue this # of file changes before calling rsync. Between delay and/or maxDelay it is possible to tune the timing of your file copies to your exact preference. inotify waits for write_close to add files to the transfer list so there are no issues with rsync trying to upload uncompleted files. I typically only record short 10 second clips. If you use your cameras to continuously record be aware that files in the process of being written will not be copied until they are closed. It may be further possible to remove this limitation with the inotifyMode directive, though I have not tested this.

''archive = true ''This preserves ownership and permissions on the copied files.

''ignore_times = true'' This sets rsync's --ignore-times directive. For the purpose it is being used here it is safe to assume you will never have a newer copy of the files you are uploading already existing in your destination. Removing this check reduces API calls and is a noticeable optimization for AWS. If your cloud provider does not meter traffic you probably won't notice any difference with this either way.

''inplace = true'' and ''whole_file = true'' Sets these rsync options and are a further optimization for S3 API use efficiency. This makes rsync's functionality less "sync" and more straight "copy", again because we can safely assume only newly created files will ever be transferred. These options used together make this method of backing up events very close in terms of total traffic cost to natively writing to S3 straight from Zoneminder. Once again if your provider does not charge for API calls this will not matter to you.

''prune_empty_dirs = true'' Because they are watched by inotify, rsync will create empty remote directories even for events Zonmeminder deletes locally. If you are not syncing deletes you will want to use this flag, see below.

Two other very important variables in this file are;

''delete = false'' this is also pretty self explanatory, file deletes will not be synced from source to target. In the case of my S3 bucket I have lifecycle rules that handle this. If you prefer for your remote storage location to synchronize the deletions made by Zoneminder you can set this to true. This also means if you accidentally delete events from your local storage they will be deleted from the cloud as well. Use with caution.

''init = false'' causes the lsyncd to not do a complete initial synchronization between source and target on service startup. On S3 this is expensive in terms of API calls and may take a while. I know I'm going to miss some events during system maintenance/OS updates etc anyway so I don't consider this worth the cost, but you can set to true if you want it. Be warned it will make your target an exact mirror of your source.

Having delete and init set to false also should make this config fairly safe to use against an existing target if you just run it on your machine without heeding my previous warning. Don't change or remove these unless you are absolutely sure you know what you are doing. There are also options besides true and false so read the docs for more info. You can also add options to be added directly to the rsync calls. You can sync multiple directories to multiple targets with multiple options. There are exclude options which you may find useful. It is far too much to cover here but the simple config above is all I need for my purposes.

Once the service is configured you can control it with systemctl like any other systemd service. By default it will be disabled so you will need to enable it to run automatically after suitable testing. You can check the logs for startup or running errors with journalctl. If syncs are working correctly you can watch them as uploads are logged very shortly after the events are saved to local disk;

<nowiki>[root@nvr system]# tail -50 /var/log/lsyncd/lsyncd.log
/1/2025-12-11/8707/8707-video.mp4
/1/2025-12-11/8707/snapshot.jpg
/1/2025-12-11/8707/alarm.jpg
/6/2025-12-11/8708/
/6/2025-12-11/
/6/
/6/2025-12-11/8708/8708-video.mp4
/6/2025-12-11/8708/snapshot.jpg
/6/2025-12-11/8708/alarm.jpg
/8/2025-12-11/8706/8706-video.mp4
/8/2025-12-11/8706/
/8/2025-12-11/
/8/
Thu Dec 11 14:30:25 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:31:50 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8709/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8709/8709-video.mp4
/2/2025-12-11/8709/snapshot.jpg
/2/2025-12-11/8709/alarm.jpg
Thu Dec 11 14:32:00 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:32:04 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8710/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8710/8710-video.mp4
/2/2025-12-11/8710/snapshot.jpg
/2/2025-12-11/8710/alarm.jpg
Thu Dec 11 14:32:11 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:32:45 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8711/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8711/8711-video.mp4
/2/2025-12-11/8711/snapshot.jpg
/2/2025-12-11/8711/alarm.jpg
Thu Dec 11 14:32:51 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:37:36 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/3/2025-12-11/8712/
/3/2025-12-11/
/3/
/
/3/2025-12-11/8712/8712-video.mp4
/3/2025-12-11/8712/snapshot.jpg
/3/2025-12-11/8712/alarm.jpg
Thu Dec 11 14:37:41 2025 Normal: Finished a list after exitcode: 0
[root@nvr system]#</nowiki>

Note: If you receive errors similar to "maximum number of watches reached" in the logs you may need to increase the default limits on your system for /proc/sys/fs/inotify/max_user_instances and /proc/sys/fs/inotify/max_user_watches. See here for more details;

https://support.scc.suse.com/s/kb/360054835111?language=en_US

I'm happy to again have offsite copies of all my events now. While they are not tracked in the Zoneminder database, they are still saved in folders by monitor id and date for easy retrieval should the ZM database become unavailable. Props to the ZM devs for their great software, and I hope this writeup proves useful to some other users in the future.

==See Also==
* https://github.com/lsyncd/lsyncd/issues/668 - Beware that lsync will do rsync with deletes on by default. With some casual testing, you might inadvertedly delete your home directory or root filesystem. From the github: "''I was told many times delete by default was a bad idea and was a result of the usual use case in the sense of replicating the target exactly like the source. I suppose the people telling so have a point.''"
* https://docs.rockylinux.org/10/books/learning_rsync/06_rsync_inotify/
* https://linuxvox.com/blog/what-is-the-proper-way-to-use-inotify/ - Using inotify-tools command line interface
* https://www.cyberciti.biz/faq/linux-inotify-examples-to-replicate-directories/ - Probably easier than lsyncd. (Was not available in default Debian Bullseye (have to use backports https://qa.debian.org/madison.php?package=incron&table=archived&a=&c=&s=#) but is in most other Debian releases.).
* https://wiki.alpinelinux.org/wiki/Inotifyd
* https://wiki.archlinux.org/title/Incron

Multi Port

2026-01-09T22:45:23Z

Kernelkurtz:

All browsers currently have a limitation where there can only be 6 connections to a server. This can be gotten around by using multi port, or by adjusting a Firefox about:config setting.

==Apache Settings for Multi Port==
This is the optimal approach as it will work on any browser. If you are in a commercial setting, or have other users besides yourself, it is almost required to setup Multi Port through Apache. If on the other hand you are on your own, you may consider simply using Firefox. Multi port, does just what it says: It will redirect multiple server connections through different ports, which is a workaround for the browser security limitation.

Here are some quick configs for 50 cameras. Note: The below config has been confirmed to work with only HTTP. HTTPS may need additional configuration. If you get an error about missing a > bracket on the 000-default.conf, make it so all these _default_:#### are on one line. Then it will work. It's not easy to read it in that format, so it has been justified for viewing here.

====/etc/apache2/sites-available/000-default.conf:====
<pre>
<VirtualHost _default_:80 _default_:30000
_default_:30001 _default_:30002 _default_:30003 _default_:30004
_default_:30005 _default_:30006 _default_:30007 _default_:30008 _default_:30009 _default_:30010
_default_:30011 _default_:30012 _default_:30013 _default_:30014
_default_:30015 _default_:30016 _default_:30017 _default_:30018
_default_:30019 _default_:30020 _default_:30021 _default_:30022
_default_:30023 _default_:30024 _default_:30025 _default_:30026
_default_:30027 _default_:30028 _default_:30029 _default_:30030
_default_:30031 _default_:30032 _default_:30033 _default_:30034
_default_:30035 _default_:30036 _default_:30037 _default_:30038
_default_:30039 _default_:30040 _default_:30041 _default_:30042
_default_:30043 _default_:30044 _default_:30045 _default_:30046
_default_:30047 _default_:30048 _default_:30049 _default_:30050>
</pre>

====/etc/apache2/ports.conf:====
Note:this doesn't include everything in the file. Make sure to insert into the existing ports file where changes are appropriate and not simply clobber the original file with below.
<pre>
Listen 80
Listen 30000
Listen 30001
Listen 30002
Listen 30003
Listen 30004
Listen 30005
Listen 30006
Listen 30007
Listen 30008
Listen 30009
Listen 30010
Listen 30011
Listen 30012
Listen 30013
Listen 30014
Listen 30015
Listen 30016
Listen 30017
Listen 30018
Listen 30019
Listen 30020
Listen 30021
Listen 30022
Listen 30023
Listen 30024
Listen 30025
Listen 30026
Listen 30027
Listen 30028
Listen 30029
Listen 30030
Listen 30031
Listen 30032
Listen 30033
Listen 30034
Listen 30035
Listen 30036
Listen 30037
Listen 30038
Listen 30039
Listen 30040
Listen 30041
Listen 30042
Listen 30043
Listen 30044
Listen 30045
Listen 30046
Listen 30047
Listen 30048
Listen 30049
Listen 30050
</pre>

You will also need to enable multi port in Zoneminder options. Please read the medium guide below for more information.

===Resources===
* https://medium.com/zmninja/multi-port-storage-areas-and-more-d5836a336c93 - A developer of Zoneminder wrote up this helpful guide.

==Firefox About:Config==

In Firefox you can make a change to the configuration to get cameras to display. First go to [https://support.mozilla.org/en-US/kb/about-config-editor-firefox about:config ]. And search for, then adjust [http://kb.mozillazine.org/Network.http.max-persistent-connections-per-server Network.http.max-persistent-connections-per-server]. The max persistent connections per server must be > 6 in order to see > 6 camera streams. It can be set to any number, so perhaps you might set it to 100 or 150.

[[File:Firefox About Config Edit.png|900px|||]]

===Resources===
The forum will have a number of posts regarding this change. It has been discussed extensively. Such as:
* [https://forums.zoneminder.com/viewtopic.php?f=32&t=23417&p=89249 ZM Forums: Problems when two people are watching live]

[[Category:Dummies_Guide]]

==Alternative firewall based method==

If you are unable or prefer not to modify your webserver configuration, you can also use Linux firewall functionality to redirect a range of incoming high ports to the configured webserver listening port. This will work with both Apache and Nginx based Zoneminder installs.

The following rules are are for iptables firewalls and are working on my RHEL based server. If you use another firewall such as nftables, firewalld, ufw, etc., you will have to translate them accordingly. AI is very helpful for tasks such as this.

<pre>iptables -t nat -A PREROUTING -p tcp -m multiport --dports 30000:30100 -j REDIRECT --to-ports 443</pre>

If you are running a headless Zoneminder install the above rule is all you will need. Replace 30000:30100 with the range of ports you want to redirect. Of course this has to match the multiport starting port in Zoneminder's network settings. You can also use port 80 as destination if you don't use https, or whatever other port your webserver listens on. You can quickly check it is working by browsing to http(s)://yourzomeminderserver:30099 (or some other redirected port).

If your ZM server has a graphical Linux install and a directly connected display, you will also need some additional configuration to make this work as localhost traffic does not use the same prerouting rules. First you need to enable routing on the localnet network. Only do this if you trust the other devices on your local LAN, don't do this if you connect directly to the internet. Add the following line to /etc/sysctl.conf (or the appropriate location for your distribution).

<pre>net.ipv4.conf.all.route_localnet = 1</pre>

You can apply it immediately with sysctl -p. Then you need to add a second firewall rule to redirect the loopback address ports. Use the same port range and destination port as the previous rule.

<pre>iptables -t nat -I OUTPUT -p tcp -o lo --dport 30000:30100 -j REDIRECT --to-ports 443</pre>

That's it. Be sure to make any rules you add persistent across reboots with whatever firewall management method you are using.

Multi Port

2026-01-09T16:46:27Z

Kernelkurtz: Added test

All browsers currently have a limitation where there can only be 6 connections to a server. This can be gotten around by using multi port, or by adjusting a Firefox about:config setting.

==Apache Settings for Multi Port==
This is the optimal approach as it will work on any browser. If you are in a commercial setting, or have other users besides yourself, it is almost required to setup Multi Port through Apache. If on the other hand you are on your own, you may consider simply using Firefox. Multi port, does just what it says: It will redirect multiple server connections through different ports, which is a workaround for the browser security limitation.

Here are some quick configs for 50 cameras. Note: The below config has been confirmed to work with only HTTP. HTTPS may need additional configuration. If you get an error about missing a > bracket on the 000-default.conf, make it so all these _default_:#### are on one line. Then it will work. It's not easy to read it in that format, so it has been justified for viewing here.

====/etc/apache2/sites-available/000-default.conf:====
<pre>
<VirtualHost _default_:80 _default_:30000
_default_:30001 _default_:30002 _default_:30003 _default_:30004
_default_:30005 _default_:30006 _default_:30007 _default_:30008 _default_:30009 _default_:30010
_default_:30011 _default_:30012 _default_:30013 _default_:30014
_default_:30015 _default_:30016 _default_:30017 _default_:30018
_default_:30019 _default_:30020 _default_:30021 _default_:30022
_default_:30023 _default_:30024 _default_:30025 _default_:30026
_default_:30027 _default_:30028 _default_:30029 _default_:30030
_default_:30031 _default_:30032 _default_:30033 _default_:30034
_default_:30035 _default_:30036 _default_:30037 _default_:30038
_default_:30039 _default_:30040 _default_:30041 _default_:30042
_default_:30043 _default_:30044 _default_:30045 _default_:30046
_default_:30047 _default_:30048 _default_:30049 _default_:30050>
</pre>

====/etc/apache2/ports.conf:====
Note:this doesn't include everything in the file. Make sure to insert into the existing ports file where changes are appropriate and not simply clobber the original file with below.
<pre>
Listen 80
Listen 30000
Listen 30001
Listen 30002
Listen 30003
Listen 30004
Listen 30005
Listen 30006
Listen 30007
Listen 30008
Listen 30009
Listen 30010
Listen 30011
Listen 30012
Listen 30013
Listen 30014
Listen 30015
Listen 30016
Listen 30017
Listen 30018
Listen 30019
Listen 30020
Listen 30021
Listen 30022
Listen 30023
Listen 30024
Listen 30025
Listen 30026
Listen 30027
Listen 30028
Listen 30029
Listen 30030
Listen 30031
Listen 30032
Listen 30033
Listen 30034
Listen 30035
Listen 30036
Listen 30037
Listen 30038
Listen 30039
Listen 30040
Listen 30041
Listen 30042
Listen 30043
Listen 30044
Listen 30045
Listen 30046
Listen 30047
Listen 30048
Listen 30049
Listen 30050
</pre>

You will also need to enable multi port in Zoneminder options. Please read the medium guide below for more information.

===Resources===
* https://medium.com/zmninja/multi-port-storage-areas-and-more-d5836a336c93 - A developer of Zoneminder wrote up this helpful guide.

==Firefox About:Config==

In Firefox you can make a change to the configuration to get cameras to display. First go to [https://support.mozilla.org/en-US/kb/about-config-editor-firefox about:config ]. And search for, then adjust [http://kb.mozillazine.org/Network.http.max-persistent-connections-per-server Network.http.max-persistent-connections-per-server]. The max persistent connections per server must be > 6 in order to see > 6 camera streams. It can be set to any number, so perhaps you might set it to 100 or 150.

[[File:Firefox About Config Edit.png|900px|||]]

===Resources===
The forum will have a number of posts regarding this change. It has been discussed extensively. Such as:
* [https://forums.zoneminder.com/viewtopic.php?f=32&t=23417&p=89249 ZM Forums: Problems when two people are watching live]

[[Category:Dummies_Guide]]

==Alternative firewall based method==

If you are unable or prefer not to modify your webserver configuration, you can also use Linux firewall functionality to redirect a range of incoming high ports to the configured webserver listening port. This will work with both Apache and Nginx based Zoneminder installs.

The following rules are are for iptables firewalls and are working on my RHEL based server. If you use another firewall such as nftables, firewalld, ufw, etc., you will have to translate them accordingly. AI is very helpful for tasks such as this.

<pre>iptables -t nat -A PREROUTING -p tcp -m multiport --dports 30000:30100 -j REDIRECT --to-ports 443</pre>

If you are running a headless Zoneminder install this one rule is all you will need. Replace 30000:30100 with the range of ports you want to redirect. Of course this has to match the multiport starting port in Zoneminder's network settings. You can also use port 80 as destination if you don't use https, or whatever other port your webserver listens on.

If your ZM server has a graphical Linux install and a directly connected display, you will also need some additional configuration to make this work on the local desktop as internal traffic does not use the same prerouting rules. First you need to enable routing on the localnet network. Only do this if you trust the other devices on your local LAN, don't do this if you connect directly to the internet. Add the following line to /etc/sysctl.conf (or the appropriate location for your distribution).

<pre>net.ipv4.conf.all.route_localnet = 1</pre>

You can apply it immediately with sysctl -p. Then you need to add a second firewall rule to redirect the loopback address ports. Use the same port range and destination port as the previous rule.

<pre>iptables -t nat -I OUTPUT -p tcp -o lo --dport 30000:30100 -j REDIRECT --to-ports 443</pre>

That's it! You can quickly check it is working by browsing to http(s)://yourzomeminderserver:30099 (or some other redirected port). Be sure to make any rules you add persistent across reboots with whatever firewall management method you are using.

Multi Port

2026-01-09T05:44:37Z

Kernelkurtz:

All browsers currently have a limitation where there can only be 6 connections to a server. This can be gotten around by using multi port, or by adjusting a Firefox about:config setting.

==Apache Settings for Multi Port==
This is the optimal approach as it will work on any browser. If you are in a commercial setting, or have other users besides yourself, it is almost required to setup Multi Port through Apache. If on the other hand you are on your own, you may consider simply using Firefox. Multi port, does just what it says: It will redirect multiple server connections through different ports, which is a workaround for the browser security limitation.

Here are some quick configs for 50 cameras. Note: The below config has been confirmed to work with only HTTP. HTTPS may need additional configuration. If you get an error about missing a > bracket on the 000-default.conf, make it so all these _default_:#### are on one line. Then it will work. It's not easy to read it in that format, so it has been justified for viewing here.

====/etc/apache2/sites-available/000-default.conf:====
<pre>
<VirtualHost _default_:80 _default_:30000
_default_:30001 _default_:30002 _default_:30003 _default_:30004
_default_:30005 _default_:30006 _default_:30007 _default_:30008 _default_:30009 _default_:30010
_default_:30011 _default_:30012 _default_:30013 _default_:30014
_default_:30015 _default_:30016 _default_:30017 _default_:30018
_default_:30019 _default_:30020 _default_:30021 _default_:30022
_default_:30023 _default_:30024 _default_:30025 _default_:30026
_default_:30027 _default_:30028 _default_:30029 _default_:30030
_default_:30031 _default_:30032 _default_:30033 _default_:30034
_default_:30035 _default_:30036 _default_:30037 _default_:30038
_default_:30039 _default_:30040 _default_:30041 _default_:30042
_default_:30043 _default_:30044 _default_:30045 _default_:30046
_default_:30047 _default_:30048 _default_:30049 _default_:30050>
</pre>

====/etc/apache2/ports.conf:====
Note:this doesn't include everything in the file. Make sure to insert into the existing ports file where changes are appropriate and not simply clobber the original file with below.
<pre>
Listen 80
Listen 30000
Listen 30001
Listen 30002
Listen 30003
Listen 30004
Listen 30005
Listen 30006
Listen 30007
Listen 30008
Listen 30009
Listen 30010
Listen 30011
Listen 30012
Listen 30013
Listen 30014
Listen 30015
Listen 30016
Listen 30017
Listen 30018
Listen 30019
Listen 30020
Listen 30021
Listen 30022
Listen 30023
Listen 30024
Listen 30025
Listen 30026
Listen 30027
Listen 30028
Listen 30029
Listen 30030
Listen 30031
Listen 30032
Listen 30033
Listen 30034
Listen 30035
Listen 30036
Listen 30037
Listen 30038
Listen 30039
Listen 30040
Listen 30041
Listen 30042
Listen 30043
Listen 30044
Listen 30045
Listen 30046
Listen 30047
Listen 30048
Listen 30049
Listen 30050
</pre>

You will also need to enable multi port in Zoneminder options. Please read the medium guide below for more information.

===Resources===
* https://medium.com/zmninja/multi-port-storage-areas-and-more-d5836a336c93 - A developer of Zoneminder wrote up this helpful guide.

==Firefox About:Config==

In Firefox you can make a change to the configuration to get cameras to display. First go to [https://support.mozilla.org/en-US/kb/about-config-editor-firefox about:config ]. And search for, then adjust [http://kb.mozillazine.org/Network.http.max-persistent-connections-per-server Network.http.max-persistent-connections-per-server]. The max persistent connections per server must be > 6 in order to see > 6 camera streams. It can be set to any number, so perhaps you might set it to 100 or 150.

[[File:Firefox About Config Edit.png|900px|||]]

===Resources===
The forum will have a number of posts regarding this change. It has been discussed extensively. Such as:
* [https://forums.zoneminder.com/viewtopic.php?f=32&t=23417&p=89249 ZM Forums: Problems when two people are watching live]

[[Category:Dummies_Guide]]

==Alternative firewall based method==

If you are unable or prefer not to modify your webserver configuration, you can also use Linux firewall functionality to redirect a range of incoming high ports to the configured webserver listening port. This will work with both Apache and Nginx based Zoneminder installs.

The following rules are are for iptables firewalls and are working on my RHEL based server. If you use another firewall such as nftables, firewalld, ufw, etc., you will have to translate them accordingly. AI is very helpful for tasks such as this.

<pre>iptables -t nat -A PREROUTING -p tcp -m multiport --dports 30000:30100 -j REDIRECT --to-ports 443</pre>

If you are running a headless Zoneminder install this one rule is all you will need. Replace 30000:30100 with the range of ports you want to redirect. Of course this has to match the multiport starting port in Zoneminder's network settings. You can also use port 80 as destination if you don't use https, or whatever other port your webserver listens on.

If your ZM server has a graphical Linux install and a directly connected display, you will also need some additional configuration to make this work on the local desktop as internal traffic does not use the same prerouting rules. First you need to enable routing on the localnet network. Only do this if you trust the other devices on your local LAN, don't do this if you connect directly to the internet. Add the following line to /etc/sysctl.conf (or the appropriate location for your distribution).

<pre>net.ipv4.conf.all.route_localnet = 1</pre>

You can apply it immediately with sysctl -p. Then you need to add a second firewall rule to redirect the loopback address ports. Use the same port range and destination port as the previous rule.

<pre>iptables -t nat -I OUTPUT -p tcp -o lo --dport 30000:30100 -j REDIRECT --to-ports 443</pre>

That's it! Be sure to make any rules you add persistent across reboots with whatever firewall management method you are using.

Multi Port

2026-01-08T23:06:47Z

Kernelkurtz: Added firewall redirect method

All browsers currently have a limitation where there can only be 6 connections to a server. This can be gotten around by using multi port, or by adjusting a Firefox about:config setting.

==Apache Settings for Multi Port==
This is the optimal approach as it will work on any browser. If you are in a commercial setting, or have other users besides yourself, it is almost required to setup Multi Port through Apache. If on the other hand you are on your own, you may consider simply using Firefox. Multi port, does just what it says: It will redirect multiple server connections through different ports, which is a workaround for the browser security limitation.

Here are some quick configs for 50 cameras. Note: The below config has been confirmed to work with only HTTP. HTTPS may need additional configuration. If you get an error about missing a > bracket on the 000-default.conf, make it so all these _default_:#### are on one line. Then it will work. It's not easy to read it in that format, so it has been justified for viewing here.

====/etc/apache2/sites-available/000-default.conf:====
<pre>
<VirtualHost _default_:80 _default_:30000
_default_:30001 _default_:30002 _default_:30003 _default_:30004
_default_:30005 _default_:30006 _default_:30007 _default_:30008 _default_:30009 _default_:30010
_default_:30011 _default_:30012 _default_:30013 _default_:30014
_default_:30015 _default_:30016 _default_:30017 _default_:30018
_default_:30019 _default_:30020 _default_:30021 _default_:30022
_default_:30023 _default_:30024 _default_:30025 _default_:30026
_default_:30027 _default_:30028 _default_:30029 _default_:30030
_default_:30031 _default_:30032 _default_:30033 _default_:30034
_default_:30035 _default_:30036 _default_:30037 _default_:30038
_default_:30039 _default_:30040 _default_:30041 _default_:30042
_default_:30043 _default_:30044 _default_:30045 _default_:30046
_default_:30047 _default_:30048 _default_:30049 _default_:30050>
</pre>

====/etc/apache2/ports.conf:====
Note:this doesn't include everything in the file. Make sure to insert into the existing ports file where changes are appropriate and not simply clobber the original file with below.
<pre>
Listen 80
Listen 30000
Listen 30001
Listen 30002
Listen 30003
Listen 30004
Listen 30005
Listen 30006
Listen 30007
Listen 30008
Listen 30009
Listen 30010
Listen 30011
Listen 30012
Listen 30013
Listen 30014
Listen 30015
Listen 30016
Listen 30017
Listen 30018
Listen 30019
Listen 30020
Listen 30021
Listen 30022
Listen 30023
Listen 30024
Listen 30025
Listen 30026
Listen 30027
Listen 30028
Listen 30029
Listen 30030
Listen 30031
Listen 30032
Listen 30033
Listen 30034
Listen 30035
Listen 30036
Listen 30037
Listen 30038
Listen 30039
Listen 30040
Listen 30041
Listen 30042
Listen 30043
Listen 30044
Listen 30045
Listen 30046
Listen 30047
Listen 30048
Listen 30049
Listen 30050
</pre>

You will also need to enable multi port in Zoneminder options. Please read the medium guide below for more information.

===Resources===
* https://medium.com/zmninja/multi-port-storage-areas-and-more-d5836a336c93 - A developer of Zoneminder wrote up this helpful guide.

==Firefox About:Config==

In Firefox you can make a change to the configuration to get cameras to display. First go to [https://support.mozilla.org/en-US/kb/about-config-editor-firefox about:config ]. And search for, then adjust [http://kb.mozillazine.org/Network.http.max-persistent-connections-per-server Network.http.max-persistent-connections-per-server]. The max persistent connections per server must be > 6 in order to see > 6 camera streams. It can be set to any number, so perhaps you might set it to 100 or 150.

[[File:Firefox About Config Edit.png|900px|||]]

===Resources===
The forum will have a number of posts regarding this change. It has been discussed extensively. Such as:
* [https://forums.zoneminder.com/viewtopic.php?f=32&t=23417&p=89249 ZM Forums: Problems when two people are watching live]

[[Category:Dummies_Guide]]

==Alternative firewall based method==

If you are unable or prefer not to modify your webserver configuration, you can also use Linux firewall functionality to redirect a range of incoming high ports to the configured webserver listening port. This will work with both Apache and Nginx based Zoneminder installs.

The following rules are are for iptables firewalls and are working on my RHEL based server. If you use another firewall such as nftables, firewalld, ufw, etc., you will have to translate them accordingly. AI is very helpful for tasks such as this.

<pre>iptables -t nat -A PREROUTING -p tcp -m multiport --dports 30000:30100 -j REDIRECT --to-ports 443</pre>

If you are running a headless Zoneminder install that is all you will need. Replace 30000:30100 with the range of ports you want to redirect. Of course this has to match the multiport starting port in Zoneminder's network settings. You can also use port 80 as destination if you don't use https, or whatever other port your webserver listens on.

If your ZM server has a graphical Linux install and a directly connected display, you will also need some additional configuration to make this work on the local desktop as internal traffic does not use the same prerouting rules. First you need to enable routing on the localnet network. Only do this if you trust the other devices on your local LAN. Add the following line to /etc/sysctl.conf (or the appropriate location for your distribution).

<pre>net.ipv4.conf.all.route_localnet = 1</pre>

You can apply it immediately with sysctl -p. Then you need to add a second firewall rule to redirect the loopback address. Use the same port range and destination port as the previous rule.

<pre>iptables -t nat -I OUTPUT -p tcp -o lo --dport 30000:30100 -j REDIRECT --to-ports 443</pre>

That's it! Be sure to make any rules you add persistent across reboots with whatever firewall management method you are using.

Realtime event backup to cloud storage

2025-12-29T17:39:21Z

Kernelkurtz:

It's possible to use lsync daemon, which leverages the inotify https://en.wikipedia.org/wiki/Inotify kernel subsystem to run triggers based on events in a directory (create, modify, delete). Triggers can be varied (you can run any arbitrary command) but in the default use case, is as a filesystem backup / clone using the rsync command.

You may also want to consider other options. Inotify has command line tools, and there is an incrond, which uses cron syntax to run commands based on inotify.

==About==
After recently migrating from another popular NVR software on Windows to Zoneminder on Linux I started looking for a way to do near-real-time backups of my events to offsite storage, simply as a way to have a copy should the local ZM server be compromised by break-in, fire, etc. Software such as Dropbox, Google Drive, etc. make it relatively easy to do this on Windows but the setup on Linux takes bit more effort.

I wanted to keep it as simple as possible and don't need my backup solution to interface with the ZM database. After experimenting with several other options, I have settled on an application called lsyncd. It runs as a service and leverages inotify and rsync to watch a directory or directories and mirror only new changes to another storage location. Lsyncd should be available as a package for most Linux distributions. I used the installation instructions here for my Rocky Linux system;

https://docs.rockylinux.org/10/guides/backup/mirroring_lsyncd/

Note the version of lsyncd included in EPEL for Rocky 8 (2.2.2-9) has a noticeable memory leak. Building from source solved this issue.

At this point it is worthwhile to at least skim through the docs.

https://lsyncd.github.io/lsyncd/manual/config/file/

https://linux.die.net/man/1/rsync

Both lsyncd and rsync are highly configurable. For many people the use case will be very simple like my own which I will describe here - watch my Zoneminder storage location and copy new files to a remote location, but much more complex configurations are certainly possible. In my case I'll be writing to an Amazon S3 bucket which I have already setup using S3FS-FUSE according to the documentation here;

https://zoneminder.readthedocs.io/en/latest/userguide/options/options_storage.html

You can also use an Rclone mount point as a destination. I've tested this with Google Drive but it should work with any cloud provider supported by Rclone;

https://rclone.org/#providers

Follow the instructions here to set up your cloud storage as a local mountpoint;

https://rclone.org/commands/rclone_mount/

==Setup==

Once lsyncd is installed you will need to create a configuration file in /etc/lsyncd.conf. I've included mine as an example below. Note this file uses Lua syntax, not Bash. Be '''VERY CAREFUL''' if you are testing remote write/sync/copy operations to a destination that already has important data on it (see links below). I highly recommend initial testing with an empty bucket or target filesystem. You have been warned.

<nowiki>settings {

logfile = "/var/log/lsyncd/lsyncd.log",

statusFile = "/var/log/lsyncd/lsyncd-status.log",

statusInterval = 10,

maxProcesses = 1,

insist = true,

}

sync {

default.rsync,

source = "/home/Cameras",

target = "/media/aws",

delete = false,

delay = 10,

init = false,

rsync = {

archive = true,

ignore_times = true,

inplace = true,

whole_file = true,

compress = false

}

}</nowiki>

''logfile = '' is pretty self-explanatory. Be sure to set up log rotation after you are done setting lsyncd up, if required.

''maxProcesses = 1'' is the default. If you are syncing multiple sources or targets you may want to increase this.

''insist = true'' allows the service to start even if the target is not ready. I got errors without this which went away when I added it. YMMV.

''source = ''The directory where ZM events are stored.

''target = ''The location to copy events to. This will be the mount point for the cloud storage configured previously.

''targetdir = "/somedirectory"'' (not shown, part of sync block) subdirectory to use on the target. I'm just using the root directory in a dedicated bucket. You may not want this and should specify something here.

''delay = ''This is how often rsync will run if there are any filesystem changes. Default is 15 seconds. For many users this will be close enough to real-time for the purpose. This can be combined with (or substituted) for another value in the settings field;

''maxDelay = # '' (not shown, part of settings block) will queue this # of file changes before calling rsync. Between delay and/or maxDelay it is possible to tune the timing of your file copies to your exact preference. inotify waits for write_close to add files to the transfer list so there are no issues with rsync trying to upload uncompleted files. I typically only record short 10 second clips. If you use your cameras to continuously record be aware that files in the process of being written will not be copied until they are closed. It may be further possible to remove this limitation with the inotifyMode directive, though I have not tested this.

''archive = true ''This preserves ownership and permissions on the copied files.

''ignore_times = true'' This sets rsync's --ignore-times directive. For the purpose it is being used here it is safe to assume you will never have a newer copy of the files you are uploading already existing in your destination. Removing this check reduces API calls and is a noticeable optimization for AWS. If your cloud provider does not meter traffic you probably won't notice any difference with this either way.

''inplace = true'' and ''whole_file = true'' Sets these rsync options and are a further optimization for S3 API use efficiency. This makes rsync's functionality less "sync" and more straight "copy", again because we can safely assume only newly created files will ever be transferred. These options used together make this method of backing up events very close in terms of total traffic cost to natively writing to S3 straight from Zoneminder. Once again if your provider does not charge for API calls this will not matter to you.

Two other very important variables in this file are;

''delete = false'' this is also pretty self explanatory, file deletes will not be synced from source to target. In the case of my S3 bucket I have lifecycle rules that handle this. If you prefer for your remote storage location to synchronize the deletions made by Zoneminder you can set this to true. This also means if you accidentally delete events from your local storage they will be deleted from the cloud as well. Use with caution.

''init = false'' causes the lsyncd to not do a complete initial synchronization between source and target on service startup. On S3 this is expensive in terms of API calls and may take a while. I know I'm going to miss some events during system maintenance/OS updates etc anyway so I don't consider this worth the cost, but you can set to true if you want it. Be warned it will make your target an exact mirror of your source.

Having delete and init set to false also should make this config fairly safe to use against an existing target if you just run it on your machine without heeding my previous warning. Don't change or remove these unless you are absolutely sure you know what you are doing. There are also options besides true and false so read the docs for more info. You can also add options to be added directly to the rsync calls. You can sync multiple directories to multiple targets with multiple options. There are exclude options which you may find useful. It is far too much to cover here but the simple config above is all I need for my purposes.

Once the service is configured you can control it with systemctl like any other systemd service. By default it will be disabled so you will need to enable it to run automatically after suitable testing. You can check the logs for startup or running errors with journalctl. If syncs are working correctly you can watch them as uploads are logged very shortly after the events are saved to local disk;

<nowiki>[root@nvr system]# tail -50 /var/log/lsyncd/lsyncd.log
/1/2025-12-11/8707/8707-video.mp4
/1/2025-12-11/8707/snapshot.jpg
/1/2025-12-11/8707/alarm.jpg
/6/2025-12-11/8708/
/6/2025-12-11/
/6/
/6/2025-12-11/8708/8708-video.mp4
/6/2025-12-11/8708/snapshot.jpg
/6/2025-12-11/8708/alarm.jpg
/8/2025-12-11/8706/8706-video.mp4
/8/2025-12-11/8706/
/8/2025-12-11/
/8/
Thu Dec 11 14:30:25 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:31:50 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8709/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8709/8709-video.mp4
/2/2025-12-11/8709/snapshot.jpg
/2/2025-12-11/8709/alarm.jpg
Thu Dec 11 14:32:00 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:32:04 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8710/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8710/8710-video.mp4
/2/2025-12-11/8710/snapshot.jpg
/2/2025-12-11/8710/alarm.jpg
Thu Dec 11 14:32:11 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:32:45 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8711/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8711/8711-video.mp4
/2/2025-12-11/8711/snapshot.jpg
/2/2025-12-11/8711/alarm.jpg
Thu Dec 11 14:32:51 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:37:36 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/3/2025-12-11/8712/
/3/2025-12-11/
/3/
/
/3/2025-12-11/8712/8712-video.mp4
/3/2025-12-11/8712/snapshot.jpg
/3/2025-12-11/8712/alarm.jpg
Thu Dec 11 14:37:41 2025 Normal: Finished a list after exitcode: 0
[root@nvr system]#</nowiki>

Note: If you receive errors similar to "maximum number of watches reached" in the logs you may need to increase the default limits on your system for /proc/sys/fs/inotify/max_user_instances and /proc/sys/fs/inotify/max_user_watches. See here for more details;

https://support.scc.suse.com/s/kb/360054835111?language=en_US

I'm happy to again have offsite copies of all my events now. While they are not tracked in the Zoneminder database, they are still saved in folders by monitor id and date for easy retrieval should the ZM database become unavailable. Props to the ZM devs for their great software, and I hope this writeup proves useful to some other users in the future.

==See Also==
* https://github.com/lsyncd/lsyncd/issues/668 - Beware that lsync will do rsync with deletes on by default. With some casual testing, you might inadvertedly delete your home directory or root filesystem. From the github: "''I was told many times delete by default was a bad idea and was a result of the usual use case in the sense of replicating the target exactly like the source. I suppose the people telling so have a point.''"
* https://docs.rockylinux.org/10/books/learning_rsync/06_rsync_inotify/
* https://linuxvox.com/blog/what-is-the-proper-way-to-use-inotify/ - Using inotify-tools command line interface
* https://www.cyberciti.biz/faq/linux-inotify-examples-to-replicate-directories/ - Probably easier than lsyncd. (Was not available in default Debian Bullseye (have to use backports https://qa.debian.org/madison.php?package=incron&table=archived&a=&c=&s=#) but is in most other Debian releases.).
* https://wiki.alpinelinux.org/wiki/Inotifyd
* https://wiki.archlinux.org/title/Incron

Realtime event backup to cloud storage

2025-12-29T17:36:30Z

Kernelkurtz:

It's possible to use lsync daemon, which leverages the inotify https://en.wikipedia.org/wiki/Inotify kernel subsystem to run triggers based on events in a directory (create, modify, delete). Triggers can be varied (you can run any arbitrary command) but in the default use case, is as a filesystem backup / clone using the rsync command.

You may also want to consider other options. Inotify has command line tools, and there is an incrond, which uses cron syntax to run commands based on inotify.

==About==
After recently migrating from another popular NVR software on Windows to Zoneminder on Linux I started looking for a way to do near-real-time backups of my events to offsite storage, simply as a way to have a copy should the local ZM server be compromised by break-in, fire, etc. Software such as Dropbox, Google Drive, etc. make it relatively easy to do this on Windows but the setup on Linux takes bit more effort.

I wanted to keep it as simple as possible and don't need my backup solution to interface with the ZM database. After experimenting with several other options, I have settled on an application called lsyncd. It runs as a service and leverages inotify and rsync to watch a directory or directories and mirror only new changes to another storage location. Lsyncd should be available as a package for most Linux distributions. I used the installation instructions here for my Rocky Linux system;

https://docs.rockylinux.org/10/guides/backup/mirroring_lsyncd/

Note the version of lsyncd included in EPEL for Rocky 8 (2.2.2-9) has a noticeable memory leak. Building from source solved this issue.

At this point it is worthwhile to at least skim through the docs.

https://lsyncd.github.io/lsyncd/manual/config/file/

https://linux.die.net/man/1/rsync

Both lsyncd and rsync are highly configurable. For many people the use case will be very simple like my own which I will describe here - watch my Zoneminder storage location and copy new files to a remote location, but much more complex configurations are certainly possible. In my case I'll be writing to an Amazon S3 bucket which I have already setup using S3FS-FUSE according to the documentation here;

https://zoneminder.readthedocs.io/en/latest/userguide/options/options_storage.html

You can also use an Rclone mount point as a target. I've tested this with Google Drive but it should work with any cloud provider supported by Rclone;

https://rclone.org/#providers

Follow the instructions here to set up your cloud storage as a local mountpoint;

https://rclone.org/commands/rclone_mount/

==Setup==

Once lsyncd is installed you will need to create a configuration file in /etc/lsyncd.conf. I've included mine as an example below. Note this file uses Lua syntax, not Bash. Be '''VERY CAREFUL''' if you are testing remote write/sync/copy operations to a destination that already has important data on it (see links below). I highly recommend initial testing with an empty bucket or target filesystem. You have been warned.

<nowiki>settings {

logfile = "/var/log/lsyncd/lsyncd.log",

statusFile = "/var/log/lsyncd/lsyncd-status.log",

statusInterval = 10,

maxProcesses = 1,

insist = true,

}

sync {

default.rsync,

source = "/home/Cameras",

target = "/media/aws",

delete = false,

delay = 10,

init = false,

rsync = {

archive = true,

ignore_times = true,

inplace = true,

whole_file = true,

compress = false

}

}</nowiki>

''logfile = '' is pretty self-explanatory. Be sure to set up log rotation after you are done setting lsyncd up, if required.

''maxProcesses = 1'' is the default. If you are syncing multiple sources or targets you may want to increase this.

''insist = true'' allows the service to start even if the target is not ready. I got errors without this which went away when I added it. YMMV.

''source = ''The directory where ZM events are stored.

''target = ''The location to copy events to. This will be the mount point for the cloud storage configured previously.

''targetdir = "/somedirectory"'' (not shown, part of sync block) subdirectory to use on the target. I'm just using the root directory in a dedicated bucket. You may not want this and should specify something here.

''delay = ''This is how often rsync will run if there are any filesystem changes. Default is 15 seconds. For many users this will be close enough to real-time for the purpose. This can be combined with (or substituted) for another value in the settings field;

''maxDelay = # '' (not shown, part of settings block) will queue this # of file changes before calling rsync. Between delay and/or maxDelay it is possible to tune the timing of your file copies to your exact preference. inotify waits for write_close to add files to the transfer list so there are no issues with rsync trying to upload uncompleted files. I typically only record short 10 second clips. If you use your cameras to continuously record be aware that files in the process of being written will not be copied until they are closed. It may be further possible to remove this limitation with the inotifyMode directive, though I have not tested this.

''archive = true ''This preserves ownership and permissions on the copied files.

''ignore_times = true'' This sets rsync's --ignore-times directive. For the purpose it is being used here it is safe to assume you will never have a newer copy of the files you are uploading already existing in your destination. Removing this check reduces API calls and is a noticeable optimization for AWS. If your cloud provider does not meter traffic you probably won't notice any difference with this either way.

''inplace = true'' and ''whole_file = true'' Sets these rsync options and are a further optimization for S3 API use efficiency. This makes rsync's functionality less "sync" and more straight "copy", again because we can safely assume only newly created files will ever be transferred. These options used together make this method of backing up events very close in terms of total traffic cost to natively writing to S3 straight from Zoneminder. Once again if your provider does not charge for API calls this will not matter to you.

Two other very important variables in this file are;

''delete = false'' this is also pretty self explanatory, file deletes will not be synced from source to target. In the case of my S3 bucket I have lifecycle rules that handle this. If you prefer for your remote storage location to synchronize the deletions made by Zoneminder you can set this to true. This also means if you accidentally delete events from your local storage they will be deleted from the cloud as well. Use with caution.

''init = false'' causes the lsyncd to not do a complete initial synchronization between source and target on service startup. On S3 this is expensive in terms of API calls and may take a while. I know I'm going to miss some events during system maintenance/OS updates etc anyway so I don't consider this worth the cost, but you can set to true if you want it. Be warned it will make your target an exact mirror of your source.

Having delete and init set to false also should make this config fairly safe to use against an existing target if you just run it on your machine without heeding my previous warning. Don't change or remove these unless you are absolutely sure you know what you are doing. There are also options besides true and false so read the docs for more info. You can also add options to be added directly to the rsync calls. You can sync multiple directories to multiple targets with multiple options. There are exclude options which you may find useful. It is far too much to cover here but the simple config above is all I need for my purposes.

Once the service is configured you can control it with systemctl like any other systemd service. By default it will be disabled so you will need to enable it to run automatically after suitable testing. You can check the logs for startup or running errors with journalctl. If syncs are working correctly you can watch them as uploads are logged very shortly after the events are saved to local disk;

<nowiki>[root@nvr system]# tail -50 /var/log/lsyncd/lsyncd.log
/1/2025-12-11/8707/8707-video.mp4
/1/2025-12-11/8707/snapshot.jpg
/1/2025-12-11/8707/alarm.jpg
/6/2025-12-11/8708/
/6/2025-12-11/
/6/
/6/2025-12-11/8708/8708-video.mp4
/6/2025-12-11/8708/snapshot.jpg
/6/2025-12-11/8708/alarm.jpg
/8/2025-12-11/8706/8706-video.mp4
/8/2025-12-11/8706/
/8/2025-12-11/
/8/
Thu Dec 11 14:30:25 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:31:50 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8709/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8709/8709-video.mp4
/2/2025-12-11/8709/snapshot.jpg
/2/2025-12-11/8709/alarm.jpg
Thu Dec 11 14:32:00 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:32:04 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8710/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8710/8710-video.mp4
/2/2025-12-11/8710/snapshot.jpg
/2/2025-12-11/8710/alarm.jpg
Thu Dec 11 14:32:11 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:32:45 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8711/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8711/8711-video.mp4
/2/2025-12-11/8711/snapshot.jpg
/2/2025-12-11/8711/alarm.jpg
Thu Dec 11 14:32:51 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:37:36 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/3/2025-12-11/8712/
/3/2025-12-11/
/3/
/
/3/2025-12-11/8712/8712-video.mp4
/3/2025-12-11/8712/snapshot.jpg
/3/2025-12-11/8712/alarm.jpg
Thu Dec 11 14:37:41 2025 Normal: Finished a list after exitcode: 0
[root@nvr system]#</nowiki>

Note: If you receive errors similar to "maximum number of watches reached" in the logs you may need to increase the default limits on your system for /proc/sys/fs/inotify/max_user_instances and /proc/sys/fs/inotify/max_user_watches. See here for more details;

https://support.scc.suse.com/s/kb/360054835111?language=en_US

I'm happy to again have offsite copies of all my events now. While they are not tracked in the Zoneminder database, they are still saved in folders by monitor id and date for easy retrieval should the ZM database become unavailable. Props to the ZM devs for their great software, and I hope this writeup proves useful to some other users in the future.

==See Also==
* https://github.com/lsyncd/lsyncd/issues/668 - Beware that lsync will do rsync with deletes on by default. With some casual testing, you might inadvertedly delete your home directory or root filesystem. From the github: "''I was told many times delete by default was a bad idea and was a result of the usual use case in the sense of replicating the target exactly like the source. I suppose the people telling so have a point.''"
* https://docs.rockylinux.org/10/books/learning_rsync/06_rsync_inotify/
* https://linuxvox.com/blog/what-is-the-proper-way-to-use-inotify/ - Using inotify-tools command line interface
* https://www.cyberciti.biz/faq/linux-inotify-examples-to-replicate-directories/ - Probably easier than lsyncd. (Was not available in default Debian Bullseye (have to use backports https://qa.debian.org/madison.php?package=incron&table=archived&a=&c=&s=#) but is in most other Debian releases.).
* https://wiki.alpinelinux.org/wiki/Inotifyd
* https://wiki.archlinux.org/title/Incron

Realtime event backup to cloud storage

2025-12-29T06:23:44Z

Kernelkurtz: Fixed default logfile paths, added link to Rclone mount page, cleanup

It's possible to use lsync daemon, which leverages the inotify https://en.wikipedia.org/wiki/Inotify kernel subsystem to run triggers based on events in a directory (create, modify, delete). Triggers can be varied (you can run any arbitrary command) but in the default use case, is as a filesystem backup / clone using the rsync command.

You may also want to consider other options. Inotify has command line tools, and there is an incrond, which uses cron syntax to run commands based on inotify.

==About==
After recently migrating from another popular NVR software on Windows to Zoneminder on Linux I started looking for a way to do near-real-time backups of my events to offsite storage, simply as a way to have a copy should the local ZM server be compromised by break-in, fire, etc. Software such as Dropbox, Google Drive, etc. make it relatively easy to do this on Windows but the setup on Linux takes bit more effort.

I wanted to keep it as simple as possible and don't need my backup solution to interface with the ZM database. After experimenting with several other options, I have settled on an application called lsyncd. It runs as a service and leverages inotify and rsync to watch a directory or directories and mirror only new changes to another storage location. Lsyncd should be available as a package for most Linux distributions. I used the installation instructions here for my Rocky Linux system;

https://docs.rockylinux.org/10/guides/backup/mirroring_lsyncd/

Note the version of lsyncd included in EPEL for Rocky 8 (2.2.2-9) has a noticeable memory leak. Building from source solved this issue.

At this point it is worthwhile to at least skim through the docs.

https://lsyncd.github.io/lsyncd/manual/config/file/

https://linux.die.net/man/1/rsync

Both lsyncd and rsync are highly configurable. For many people the use case will be very simple like my own which I will describe here - watch my Zoneminder storage location and copy new files to a remote location, but much more complex configurations are certainly possible. In my case I'll be writing to an Amazon S3 bucket which I have already setup using S3FS-FUSE according to the documentation here;

https://zoneminder.readthedocs.io/en/latest/userguide/options/options_storage.html

You can also use an Rclone mount point as a target. I've tested this with Google Drive but it should work with any cloud provider supported by Rclone;

https://rclone.org/#providers

Follow the instructions here to set up your cloud storage as a local mountpoint.

https://rclone.org/commands/rclone_mount/

==Setup==

Once lsyncd is installed you will need to create a configuration file in /etc/lsyncd.conf. I've included mine as an example below. Note this file uses Lua syntax, not Bash. Be '''VERY CAREFUL''' if you are testing remote write/sync/copy operations to a destination that already has important data on it (see links below). I highly recommend initial testing with an empty bucket or target filesystem. You have been warned.

<nowiki>settings {

logfile = "/var/log/lsyncd/lsyncd.log",

statusFile = "/var/log/lsyncd/lsyncd-status.log",

statusInterval = 10,

maxProcesses = 1,

insist = true,

}

sync {

default.rsync,

source = "/home/Cameras",

target = "/media/aws",

delete = false,

delay = 10,

init = false,

rsync = {

archive = true,

ignore_times = true,

inplace = true,

whole_file = true,

compress = false

}

}</nowiki>

''logfile = '' is pretty self-explanatory. Be sure to set up log rotation after you are done setting lsyncd up, if required.

''maxProcesses = 1'' is the default. If you are syncing multiple sources or targets you may want to increase this.

''insist = true'' allows the service to start even if the target is not ready. I got errors without this which went away when I added it. YMMV.

''source = ''The directory where ZM events are stored.

''target = ''The location to copy events to. This will be the mount point for the cloud storage configured previously.

''targetdir = "/somedirectory"'' (not shown, part of sync block) subdirectory to use on the target. I'm just using the root directory in a dedicated bucket. You may not want this and should specify something here.

''delay = ''This is how often rsync will run if there are any filesystem changes. Default is 15 seconds. For many users this will be close enough to real-time for the purpose. This can be combined with (or substituted) for another value in the settings field;

''maxDelay = # '' (not shown, part of settings block) will queue this # of file changes before calling rsync. Between delay and/or maxDelay it is possible to tune the timing of your file copies to your exact preference. inotify waits for write_close to add files to the transfer list so there are no issues with rsync trying to upload uncompleted files. I typically only record short 10 second clips. If you use your cameras to continuously record be aware that files in the process of being written will not be copied until they are closed. It may be further possible to remove this limitation with the inotifyMode directive, though I have not tested this.

''archive = true ''This preserves ownership and permissions on the copied files.

''ignore_times = true'' This sets rsync's --ignore-times directive. For the purpose it is being used here it is safe to assume you will never have a newer copy of the files you are uploading already existing in your destination. Removing this check reduces API calls and is a noticeable optimization for AWS. If your cloud provider does not meter traffic you probably won't notice any difference with this either way.

''inplace = true'' and ''whole_file = true'' Sets these rsync options and are a further optimization for S3 API use efficiency. This makes rsync's functionality less "sync" and more straight "copy", again because we can safely assume only newly created files will ever be transferred. These options used together make this method of backing up events very close in terms of total traffic cost to natively writing to S3 straight from Zoneminder. Once again if your provider does not charge for API calls this will not matter to you.

Two other very important variables in this file are;

''delete = false'' this is also pretty self explanatory, file deletes will not be synced from source to target. In the case of my S3 bucket I have lifecycle rules that handle this. If you prefer for your remote storage location to synchronize the deletions made by Zoneminder you can set this to true. This also means if you accidentally delete events from your local storage they will be deleted from the cloud as well. Use with caution.

''init = false'' causes the lsyncd to not do a complete initial synchronization between source and target on service startup. On S3 this is expensive in terms of API calls and may take a while. I know I'm going to miss some events during system maintenance/OS updates etc anyway so I don't consider this worth the cost, but you can set to true if you want it. Be warned it will make your target an exact mirror of your source.

Having delete and init set to false also should make this config fairly safe to use against an existing target if you just run it on your machine without heeding my previous warning. Don't change or remove these unless you are absolutely sure you know what you are doing. There are also options besides true and false so read the docs for more info. You can also add options to be added directly to the rsync calls. You can sync multiple directories to multiple targets with multiple options. There are exclude options which you may find useful. It is far too much to cover here but the simple config above is all I need for my purposes.

Once the service is configured you can control it with systemctl like any other systemd service. By default it will be disabled so you will need to enable it to run automatically after suitable testing. You can check the logs for startup or running errors with journalctl. If syncs are working correctly you can watch them as uploads are logged very shortly after the events are saved to local disk;

<nowiki>[root@nvr system]# tail -50 /var/log/lsyncd.log
/1/2025-12-11/8707/8707-video.mp4
/1/2025-12-11/8707/snapshot.jpg
/1/2025-12-11/8707/alarm.jpg
/6/2025-12-11/8708/
/6/2025-12-11/
/6/
/6/2025-12-11/8708/8708-video.mp4
/6/2025-12-11/8708/snapshot.jpg
/6/2025-12-11/8708/alarm.jpg
/8/2025-12-11/8706/8706-video.mp4
/8/2025-12-11/8706/
/8/2025-12-11/
/8/
Thu Dec 11 14:30:25 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:31:50 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8709/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8709/8709-video.mp4
/2/2025-12-11/8709/snapshot.jpg
/2/2025-12-11/8709/alarm.jpg
Thu Dec 11 14:32:00 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:32:04 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8710/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8710/8710-video.mp4
/2/2025-12-11/8710/snapshot.jpg
/2/2025-12-11/8710/alarm.jpg
Thu Dec 11 14:32:11 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:32:45 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8711/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8711/8711-video.mp4
/2/2025-12-11/8711/snapshot.jpg
/2/2025-12-11/8711/alarm.jpg
Thu Dec 11 14:32:51 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:37:36 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/3/2025-12-11/8712/
/3/2025-12-11/
/3/
/
/3/2025-12-11/8712/8712-video.mp4
/3/2025-12-11/8712/snapshot.jpg
/3/2025-12-11/8712/alarm.jpg
Thu Dec 11 14:37:41 2025 Normal: Finished a list after exitcode: 0
[root@nvr system]#</nowiki>

Note: If you receive errors similar to "maximum number of watches reached" in the logs you may need to increase the default limits on your system for /proc/sys/fs/inotify/max_user_instances and /proc/sys/fs/inotify/max_user_watches. See here for more details;

https://support.scc.suse.com/s/kb/360054835111?language=en_US

I'm happy to again have offsite copies of all my events now. While they are not tracked in the Zoneminder database, they are still saved in folders by monitor id and date for easy retrieval should the ZM database become unavailable. Props to the ZM devs for their great software, and I hope this writeup proves useful to some other users in the future.

==See Also==
* https://github.com/lsyncd/lsyncd/issues/668 - Beware that lsync will do rsync with deletes on by default. With some casual testing, you might inadvertedly delete your home directory or root filesystem. From the github: "''I was told many times delete by default was a bad idea and was a result of the usual use case in the sense of replicating the target exactly like the source. I suppose the people telling so have a point.''"
* https://docs.rockylinux.org/10/books/learning_rsync/06_rsync_inotify/
* https://linuxvox.com/blog/what-is-the-proper-way-to-use-inotify/ - Using inotify-tools command line interface
* https://www.cyberciti.biz/faq/linux-inotify-examples-to-replicate-directories/ - Probably easier than lsyncd. (Was not available in default Debian Bullseye (have to use backports https://qa.debian.org/madison.php?package=incron&table=archived&a=&c=&s=#) but is in most other Debian releases.).
* https://wiki.alpinelinux.org/wiki/Inotifyd
* https://wiki.archlinux.org/title/Incron

Realtime event backup to cloud storage

2025-12-27T06:45:50Z

Kernelkurtz: Added Rclone info and link

It's possible to use lsync daemon, which leverages the inotify https://en.wikipedia.org/wiki/Inotify kernel subsystem to run triggers based on events in a directory (create, modify, delete). Triggers can be varied (you can run any arbitrary command) but in the default use case, is as a filesystem backup / clone using the rsync command.

You may also want to consider other options. Inotify has command line tools, and there is an incrond, which uses cron syntax to run commands based on inotify.

==About==
After recently migrating from another popular NVR software on Windows to Zoneminder on Linux I started looking for a way to do near-real-time backups of my events to offsite storage, simply as a way to have a copy should the local ZM server be compromised by break-in, fire, etc. Software such as Dropbox, Google Drive, etc. make it relatively easy to do this on Windows but the setup on Linux takes bit more effort.

I wanted to keep it as simple as possible and don't need my backup solution to interface with the ZM database at all. After experimenting with several other options, I have settled on an application called lsyncd. It runs as a service and leverages inotify and rsync to watch a directory or directories and mirror only new changes to another storage location. Lsyncd should be available as a package for most Linux distributions. I used the installation instructions here for my Rocky Linux system;

https://docs.rockylinux.org/10/guides/backup/mirroring_lsyncd/

Note the version of lsyncd included in EPEL for Rocky 8 (2.2.2-9) has a noticeable memory leak. Building from source solved this issue.

At this point it is worthwhile to at least skim through the docs.

https://lsyncd.github.io/lsyncd/manual/config/file/

https://linux.die.net/man/1/rsync

Both lsyncd and rsync are highly configurable and incredibly powerful. For many people the use case will be very simple like my own which I will describe here - watch my Zoneminder storage location and copy new files to a remote location, but much more complex configurations are certainly possible. In my case I'll be writing to an Amazon S3 bucket which I have already setup using S3FS-FUSE according to the documentation here;

https://zoneminder.readthedocs.io/en/latest/userguide/options/options_storage.html

Note you do not need to add the S3FS as a storage location in ZM to use lsyncd to copy files there, that is only required for ZM to write events directly to S3. You can also use an Rclone mount point as a target. I've tested this with Google Drive but it should work with any cloud provider supported by Rclone (also including S3). See here for more info;

https://rclone.org/

==Setup==

Once lsyncd is installed you will need to create a configuration file in /etc/lsyncd.conf. I've included mine as an example below. Note this script uses Lua syntax, not Bash. Be '''VERY CAREFUL''' if you are testing remote write/sync/copy operations to a destination that already has important data on it (see links below). I highly recommend initial testing with an empty bucket or target filesystem. You have been warned.

<nowiki>settings {

logfile = "/var/log/lsyncd.log",

statusFile = "/var/log/lsyncd-status.log",

statusInterval = 10,

maxProcesses = 1,

insist = true,

}

sync {

default.rsync,

source = "/home/Cameras",

target = "/media/aws",

delete = false,

delay = 10,

init = false,

rsync = {

archive = true,

ignore_times = true,

inplace = true,

whole_file = true,

compress = false

}

}</nowiki>

''logfile = '' is pretty self-explanatory. Be sure to set up log rotation after you are done setting lsyncd up, if required.

''maxProcesses = 1'' is the default. If you are syncing multiple sources or targets you may want to increase this.

''insist = true'' allows the service to start even if the target is not ready. I got errors without this which went away when I added it. YMMV.

''source = ''The directory where ZM events are stored.

''target = ''The location to copy events to. Must be accessible via rsync. In my case it is the mount point for the S3FS configured previously.

''targetdir = "/somedirectory"'' (not shown, part of sync block) subdirectory to use on the target. I'm just using the root directory in a dedicated bucket. You may not want this and should specify something here.

''delay = ''This is how often rsync will run if there are any filesystem changes. Default is 15 seconds. For many users this will be close enough to real-time for the purpose. This can be combined with (or substituted) for another value in the settings field;

''maxDelay = # '' (not shown, part of settings block) will queue this # of file changes before calling rsync. Between delay and/or maxDelay it is possible to tune the timing of your file copies to your exact preference. inotify waits for write_close to add files to the transfer list so there are no issues with rsync trying to upload uncompleted files. I typically only record short 10 second clips. If you use your cameras to continuously record be aware that files in the process of being written will not be copied until they are closed. It may be further possible to remove this limitation with the inotifyMode directive, though I have not tested this.

''archive = true ''This preserves ownership and permissions on the copied files.

''ignore_times = true'' This sets rsync's --ignore-times directive. For the purpose it is being used here it is safe to assume you will never have a newer copy of the files you are uploading already existing in your destination. Removing this check reduces API calls and is a noticeable optimization for AWS. If your cloud provider does not meter traffic you probably won't notice any difference with this either way.

''inplace = true'' and ''whole_file = true'' Sets these rsync options and are a further optimization for S3 API use efficiency. This makes rsync's functionality less "sync" and more straight "copy", again because we can safely assume only newly created files will ever be transferred. These options used together make this method of backing up events very close in terms of total traffic cost to natively writing to S3 straight from Zoneminder. Once again if your provider does not charge for API calls this will not matter to you.

Two other very important variables in this file are;

''delete = false'' this is also pretty self explanatory, file deletes will not be synced from source to target. In the case of my S3 bucket I have lifecycle rules that handle this. If you prefer for your remote storage location to synchronize the deletions made by Zoneminder you can set this to true. This also means if you accidentally delete events from your local storage they will be deleted from the cloud as well. Use with caution.

''init = false'' causes the lsyncd to not do a complete initial synchronization between source and target on service startup. On S3 this is expensive in terms of API calls and may take a while. I know I'm going to miss some events during system maintenance/OS updates etc anyway so I don't consider this worth the cost, but you can set to true if you want it. Be warned it will make your target an exact mirror of your source.

Having delete and init set to false also should make this config fairly safe to use against an existing target if you just run it on your machine without heeding my previous warning. Don't change or remove these unless you are absolutely sure you know what you are doing. There are also options besides true and false so read the docs for more info. You can also add options to be added directly to the rsync calls. You can sync multiple directories to multiple targets with multiple options. There are exclude options which you may find useful. It is far too much to cover here but the simple config above is all I need for my purposes.

Once the service is configured you can control it with systemctl like any other systemd service. By default it will be disabled so you will need to enable it to run automatically after suitable testing. You can check the logs for startup or running errors with journalctl. If syncs are working correctly you can watch them as uploads are logged very shortly after the events are saved to local disk;

<nowiki>[root@nvr system]# tail -50 /var/log/lsyncd.log
/1/2025-12-11/8707/8707-video.mp4
/1/2025-12-11/8707/snapshot.jpg
/1/2025-12-11/8707/alarm.jpg
/6/2025-12-11/8708/
/6/2025-12-11/
/6/
/6/2025-12-11/8708/8708-video.mp4
/6/2025-12-11/8708/snapshot.jpg
/6/2025-12-11/8708/alarm.jpg
/8/2025-12-11/8706/8706-video.mp4
/8/2025-12-11/8706/
/8/2025-12-11/
/8/
Thu Dec 11 14:30:25 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:31:50 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8709/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8709/8709-video.mp4
/2/2025-12-11/8709/snapshot.jpg
/2/2025-12-11/8709/alarm.jpg
Thu Dec 11 14:32:00 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:32:04 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8710/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8710/8710-video.mp4
/2/2025-12-11/8710/snapshot.jpg
/2/2025-12-11/8710/alarm.jpg
Thu Dec 11 14:32:11 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:32:45 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8711/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8711/8711-video.mp4
/2/2025-12-11/8711/snapshot.jpg
/2/2025-12-11/8711/alarm.jpg
Thu Dec 11 14:32:51 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:37:36 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/3/2025-12-11/8712/
/3/2025-12-11/
/3/
/
/3/2025-12-11/8712/8712-video.mp4
/3/2025-12-11/8712/snapshot.jpg
/3/2025-12-11/8712/alarm.jpg
Thu Dec 11 14:37:41 2025 Normal: Finished a list after exitcode: 0
[root@nvr system]#</nowiki>

Note: If you receive errors similar to "maximum number of watches reached" in the logs you may need to increase the default limits on your system for /proc/sys/fs/inotify/max_user_instances and /proc/sys/fs/inotify/max_user_watches. See here for more details;

https://support.scc.suse.com/s/kb/360054835111?language=en_US

I'm happy to again have offsite copies of all my events now. While they are not tracked in the Zoneminder database, they are still saved in folders by monitor id and date for easy retrieval should the ZM database become unavailable. Props to the ZM devs for their great software, and I hope this writeup proves useful to some other users in the future.

==See Also==
* https://github.com/lsyncd/lsyncd/issues/668 - Beware that lsync will do rsync with deletes on by default. With some casual testing, you might inadvertedly delete your home directory or root filesystem. From the github: "''I was told many times delete by default was a bad idea and was a result of the usual use case in the sense of replicating the target exactly like the source. I suppose the people telling so have a point.''"
* https://docs.rockylinux.org/10/books/learning_rsync/06_rsync_inotify/
* https://linuxvox.com/blog/what-is-the-proper-way-to-use-inotify/ - Using inotify-tools command line interface
* https://www.cyberciti.biz/faq/linux-inotify-examples-to-replicate-directories/ - Probably easier than lsyncd. (Was not available in default Debian Bullseye (have to use backports https://qa.debian.org/madison.php?package=incron&table=archived&a=&c=&s=#) but is in most other Debian releases.).
* https://wiki.alpinelinux.org/wiki/Inotifyd
* https://wiki.archlinux.org/title/Incron

Realtime event backup to cloud storage

2025-12-24T19:45:20Z

Kernelkurtz: Added more S3 optimizing.

It's possible to use lsync daemon, which leverages the inotify https://en.wikipedia.org/wiki/Inotify kernel subsystem to run triggers based on events in a directory (create, modify, delete). Triggers can be varied (you can run any arbitrary command) but in the default use case, is as a filesystem backup / clone using the rsync command.

You may also want to consider other options. Inotify has command line tools, and there is an incrond, which uses cron syntax to run commands based on inotify.

==About==
After recently migrating from another popular NVR software on Windows to Zoneminder on Linux I started looking for a way to do near-real-time backups of my events to offsite storage, simply as a way to have a copy should the local ZM server be compromised by break-in, fire, etc. Software such as Dropbox, Google Drive, etc. make it relatively easy to do this on Windows but the setup on Linux takes bit more effort.

I wanted to keep it as simple as possible and don't need my backup solution to interface with the ZM database at all. After experimenting with several other options, I have settled on an application called lsyncd. It runs as a service and leverages inotify and rsync to watch a directory or directories and mirror only new changes to another storage location. Lsyncd should be available as a package for most Linux distributions. I used the installation instructions here for my Rocky Linux system;

https://docs.rockylinux.org/10/guides/backup/mirroring_lsyncd/

Note the version of lsyncd included in EPEL for Rocky 8 (2.2.2-9) has a noticeable memory leak. Building from source solved this issue.

At this point it is worthwhile to at least skim through the docs.

https://lsyncd.github.io/lsyncd/manual/config/file/

https://linux.die.net/man/1/rsync

Both lsyncd and rsync are highly configurable and incredibly powerful. For many people the use case will be very simple like my own which I will describe here - watch my Zoneminder storage location and copy new files to a remote location, but much more complex configurations are certainly possible. In my case I'll be writing to an Amazon S3 bucket which I have already setup using S3FS-FUSE according to the documentation here;

https://zoneminder.readthedocs.io/en/latest/userguide/options/options_storage.html

Note you do not need to add the S3FS as a storage location in ZM to use lsyncd to copy files there, that is only required for ZM to write events directly to S3. Configuring rsync is beyond the scope of this document but this solution will work with any target that rsync is capable of writing to. Make sure your remote location is accessible via rsync before proceeding.

==Setup==

Once lsyncd is installed you will need to create a configuration file in /etc/lsyncd.conf. I've included mine as an example below. Note this script uses Lua syntax, not Bash. Be '''VERY CAREFUL''' if you are testing remote write/sync/copy operations to a destination that already has important data on it (see links below). I highly recommend initial testing with an empty bucket or target filesystem. You have been warned.

<nowiki>settings {

logfile = "/var/log/lsyncd.log",

statusFile = "/var/log/lsyncd-status.log",

statusInterval = 10,

maxProcesses = 1,

insist = true,

}

sync {

default.rsync,

source = "/home/Cameras",

target = "/media/aws",

delete = false,

delay = 10,

init = false,

rsync = {

archive = true,

ignore_times = true,

inplace = true,

whole_file = true,

compress = false

}

}</nowiki>

''logfile = '' is pretty self-explanatory. Be sure to set up log rotation after you are done setting lsyncd up, if required.

''maxProcesses = 1'' is the default. If you are syncing multiple sources or targets you may want to increase this.

''insist = true'' allows the service to start even if the target is not ready. I got errors without this which went away when I added it. YMMV.

''source = ''The directory where ZM events are stored.

''target = ''The location to copy events to. Must be accessible via rsync. In my case it is the mount point for the S3FS configured previously.

''targetdir = "/somedirectory"'' (not shown, part of sync block) subdirectory to use on the target. I'm just using the root directory in a dedicated bucket. You may not want this and should specify something here.

''delay = ''This is how often rsync will run if there are any filesystem changes. Default is 15 seconds. For many users this will be close enough to real-time for the purpose. This can be combined with (or substituted) for another value in the settings field;

''maxDelay = # '' (not shown, part of settings block) will queue this # of file changes before calling rsync. Between delay and/or maxDelay it is possible to tune the timing of your file copies to your exact preference. inotify waits for write_close to add files to the transfer list so there are no issues with rsync trying to upload uncompleted files. I typically only record short 10 second clips. If you use your cameras to continuously record be aware that files in the process of being written will not be copied until they are closed. It may be further possible to remove this limitation with the inotifyMode directive, though I have not tested this.

''archive = true ''This preserves ownership and permissions on the copied files.

''ignore_times = true'' This sets rsync's --ignore-times directive. For the purpose it is being used here it is safe to assume you will never have a newer copy of the files you are uploading already existing in your destination. Removing this check reduces API calls and is a noticeable optimization for AWS. If your cloud provider does not meter traffic you probably won't notice any difference with this either way.

''inplace = true'' and ''whole_file = true'' Sets these rsync options and are a further optimization for S3 API use efficiency. This makes rsync's functionality less "sync" and more straight "copy", again because we can safely assume only newly created files will ever be transferred. These options used together make this method of backing up events very close in terms of total traffic cost to natively writing to S3 straight from Zoneminder. Once again if your provider does not charge for API calls this will not matter to you.

Two other very important variables in this file are;

''delete = false'' this is also pretty self explanatory, file deletes will not be synced from source to target. In the case of my S3 bucket I have lifecycle rules that handle this. If you prefer for your remote storage location to synchronize the deletions made by Zoneminder you can set this to true. This also means if you accidentally delete events from your local storage they will be deleted from the cloud as well. Use with caution.

''init = false'' causes the lsyncd to not do a complete initial synchronization between source and target on service startup. On S3 this is expensive in terms of API calls and may take a while. I know I'm going to miss some events during system maintenance/OS updates etc anyway so I don't consider this worth the cost, but you can set to true if you want it. Be warned it will make your target an exact mirror of your source.

Having delete and init set to false also should make this config fairly safe to use against an existing target if you just run it on your machine without heeding my previous warning. Don't change or remove these unless you are absolutely sure you know what you are doing. There are also options besides true and false so read the docs for more info. You can also add options to be added directly to the rsync calls. You can sync multiple directories to multiple targets with multiple options. There are exclude options which you may find useful. It is far too much to cover here but the simple config above is all I need for my purposes.

Once the service is configured you can control it with systemctl like any other systemd service. By default it will be disabled so you will need to enable it to run automatically after suitable testing. You can check the logs for startup or running errors with journalctl. If syncs are working correctly you can watch them as uploads are logged very shortly after the events are saved to local disk;

<nowiki>[root@nvr system]# tail -50 /var/log/lsyncd.log
/1/2025-12-11/8707/8707-video.mp4
/1/2025-12-11/8707/snapshot.jpg
/1/2025-12-11/8707/alarm.jpg
/6/2025-12-11/8708/
/6/2025-12-11/
/6/
/6/2025-12-11/8708/8708-video.mp4
/6/2025-12-11/8708/snapshot.jpg
/6/2025-12-11/8708/alarm.jpg
/8/2025-12-11/8706/8706-video.mp4
/8/2025-12-11/8706/
/8/2025-12-11/
/8/
Thu Dec 11 14:30:25 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:31:50 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8709/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8709/8709-video.mp4
/2/2025-12-11/8709/snapshot.jpg
/2/2025-12-11/8709/alarm.jpg
Thu Dec 11 14:32:00 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:32:04 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8710/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8710/8710-video.mp4
/2/2025-12-11/8710/snapshot.jpg
/2/2025-12-11/8710/alarm.jpg
Thu Dec 11 14:32:11 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:32:45 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8711/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8711/8711-video.mp4
/2/2025-12-11/8711/snapshot.jpg
/2/2025-12-11/8711/alarm.jpg
Thu Dec 11 14:32:51 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:37:36 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/3/2025-12-11/8712/
/3/2025-12-11/
/3/
/
/3/2025-12-11/8712/8712-video.mp4
/3/2025-12-11/8712/snapshot.jpg
/3/2025-12-11/8712/alarm.jpg
Thu Dec 11 14:37:41 2025 Normal: Finished a list after exitcode: 0
[root@nvr system]#</nowiki>

Note: If you receive errors similar to "maximum number of watches reached" in the logs you may need to increase the default limits on your system for /proc/sys/fs/inotify/max_user_instances and /proc/sys/fs/inotify/max_user_watches. See here for more details;

https://support.scc.suse.com/s/kb/360054835111?language=en_US

I'm happy to again have offsite copies of all my events now. While they are not tracked in the Zoneminder database, they are still saved in folders by monitor id and date for easy retrieval should the ZM database become unavailable. Props to the ZM devs for their great software, and I hope this writeup proves useful to some other users in the future.

==See Also==
* https://github.com/lsyncd/lsyncd/issues/668 - Beware that lsync will do rsync with deletes on by default. With some casual testing, you might inadvertedly delete your home directory or root filesystem. From the github: "''I was told many times delete by default was a bad idea and was a result of the usual use case in the sense of replicating the target exactly like the source. I suppose the people telling so have a point.''"
* https://docs.rockylinux.org/10/books/learning_rsync/06_rsync_inotify/
* https://linuxvox.com/blog/what-is-the-proper-way-to-use-inotify/ - Using inotify-tools command line interface
* https://www.cyberciti.biz/faq/linux-inotify-examples-to-replicate-directories/ - Probably easier than lsyncd. (Was not available in default Debian Bullseye (have to use backports https://qa.debian.org/madison.php?package=incron&table=archived&a=&c=&s=#) but is in most other Debian releases.).
* https://wiki.alpinelinux.org/wiki/Inotifyd
* https://wiki.archlinux.org/title/Incron

Realtime event backup to cloud storage

2025-12-24T18:11:49Z

Kernelkurtz:

It's possible to use lsync daemon, which leverages the inotify https://en.wikipedia.org/wiki/Inotify kernel subsystem to run triggers based on events in a directory (create, modify, delete). Triggers can be varied (you can run any arbitrary command) but in the default use case, is as a filesystem backup / clone using the rsync command.

You may also want to consider other options. Inotify has command line tools, and there is an incrond, which uses cron syntax to run commands based on inotify.

==About==
After recently migrating from another popular NVR software on Windows to Zoneminder on Linux I started looking for a way to do near-real-time backups of my events to offsite storage, simply as a way to have a copy should the local ZM server be compromised by break-in, fire, etc. Software such as Dropbox, Google Drive, etc. make it relatively easy to do this on Windows but the setup on Linux takes bit more effort.

I wanted to keep it as simple as possible and don't need my backup solution to interface with the ZM database at all. After experimenting with several other options, I have settled on an application called lsyncd. It runs as a service and leverages inotify and rsync to watch a directory or directories and mirror only new changes to another storage location. Lsyncd should be available as a package for most Linux distributions. I used the installation instructions here for my Rocky Linux system;

https://docs.rockylinux.org/10/guides/backup/mirroring_lsyncd/

Note the version of lsyncd included in EPEL for Rocky 8 (2.2.2-9) has a noticeable memory leak. Building from source solved this issue.

At this point it is worthwhile to at least skim through the docs.

https://lsyncd.github.io/lsyncd/manual/config/file/

https://linux.die.net/man/1/rsync

Both lsyncd and rsync are highly configurable and incredibly powerful. For many people the use case will be very simple like my own which I will describe here - watch my Zoneminder storage location and copy new files to a remote location, but much more complex configurations are certainly possible. In my case I'll be writing to an Amazon S3 bucket which I have already setup using S3FS-FUSE according to the documentation here;

https://zoneminder.readthedocs.io/en/latest/userguide/options/options_storage.html

Note you do not need to add the S3FS as a storage location in ZM to use lsyncd to copy files there, that is only required for ZM to write events directly to S3. Configuring rsync is beyond the scope of this document but this solution will work with any target that rsync is capable of writing to. Make sure your remote location is accessible via rsync before proceeding.

==Setup==

Once lsyncd is installed you will need to create a configuration file in /etc/lsyncd.conf. I've included mine as an example below. Note this script uses Lua syntax, not Bash. Be '''VERY CAREFUL''' if you are testing remote write/sync/copy operations to a destination that already has important data on it (see links below). I highly recommend initial testing with an empty bucket or target filesystem. You have been warned.

<nowiki>settings {

logfile = "/var/log/lsyncd.log",

statusFile = "/var/log/lsyncd-status.log",

statusInterval = 10,

maxProcesses = 1,

insist = true,

}

sync {

default.rsync,

source = "/home/Cameras",

target = "/media/aws",

delete = false,

delay = 10,

init = false,

rsync = {

archive = true,

ignore_times = true,

inplace = true,

compress = false

}

}</nowiki>

''logfile = '' is pretty self-explanatory. Be sure to set up log rotation after you are done setting lsyncd up, if required.

''maxProcesses = 1'' is the default. If you are syncing multiple sources or targets you may want to increase this.

''insist = true'' allows the service to start even if the target is not ready. I got errors without this which went away when I added it. YMMV.

''source = ''The directory where ZM events are stored.

''target = ''The location to copy events to. Must be accessible via rsync. In my case it is the mount point for the S3FS configured previously.

''targetdir = "/somedirectory"'' (not shown, part of sync block) subdirectory to use on the target. I'm just using the root directory in a dedicated bucket. You may not want this and should specify something here.

''delay = ''This is how often rsync will run if there are any filesystem changes. Default is 15 seconds. For many users this will be close enough to real-time for the purpose. This can be combined with (or substituted) for another value in the settings field;

''maxDelay = # '' (not shown, part of settings block) will queue this # of file changes before calling rsync. Between delay and/or maxDelay it is possible to tune the timing of your file copies to your exact preference. inotify waits for write_close to add files to the transfer list so there are no issues with rsync trying to upload uncompleted files. I typically only record short 10 second clips. If you use your cameras to continuously record be aware that files in the process of being written will not be copied until they are closed. It may be further possible to remove this limitation with the inotifyMode and whole_file directives, though I have not tested this.

''archive = true ''This preserves ownership and permissions on the copied files.

''ignore_times = true'' This sets rsync's --ignore-times directive. For the purpose it is being used here it is safe to assume you will never have a newer copy of the files you are uploading already existing in your destination. Removing this check reduces API calls and is a noticeable optimization for AWS. If your cloud provider does not meter traffic you probably won't notice any difference with this either way.

''inplace = true'' This sets rsync's --in-place directive, and is a further optimization for S3 API use efficiency. Between ignore-times and in-place this makes rsync's functionality less "sync" and more straight "copy", again because we can safely assume only newly created files will ever be transferred. These two options used together make this method of backing up events very close in terms of total traffic cost to natively writing to S3 straight from Zoneminder. Once again if your provider does not charge for API calls this will not matter to you.

Two other very important variables in this file are;

''delete = false'' this is also pretty self explanatory, file deletes will not be synced from source to target. In the case of my S3 bucket I have lifecycle rules that handle this. If you prefer for your remote storage location to synchronize the deletions made by Zoneminder you can set this to true. This also means if you accidentally delete events from your local storage they will be deleted from the cloud as well. Use with caution.

''init = false'' causes the lsyncd to not do a complete initial synchronization between source and target on service startup. On S3 this is expensive in terms of API calls and may take a while. I know I'm going to miss some events during system maintenance/OS updates etc anyway so I don't consider this worth the cost, but you can set to true if you want it. Be warned it will make your target an exact mirror of your source.

Having delete and init set to false also should make this config fairly safe to use against an existing target if you just run it on your machine without heeding my previous warning. Don't change or remove these unless you are absolutely sure you know what you are doing. There are also options besides true and false so read the docs for more info. You can also add options to be added directly to the rsync calls. You can sync multiple directories to multiple targets with multiple options. There are exclude options which you may find useful. It is far too much to cover here but the simple config above is all I need for my purposes.

Once the service is configured you can control it with systemctl like any other systemd service. By default it will be disabled so you will need to enable it to run automatically after suitable testing. You can check the logs for startup or running errors with journalctl. If syncs are working correctly you can watch them as uploads are logged very shortly after the events are saved to local disk;

<nowiki>[root@nvr system]# tail -50 /var/log/lsyncd.log
/1/2025-12-11/8707/8707-video.mp4
/1/2025-12-11/8707/snapshot.jpg
/1/2025-12-11/8707/alarm.jpg
/6/2025-12-11/8708/
/6/2025-12-11/
/6/
/6/2025-12-11/8708/8708-video.mp4
/6/2025-12-11/8708/snapshot.jpg
/6/2025-12-11/8708/alarm.jpg
/8/2025-12-11/8706/8706-video.mp4
/8/2025-12-11/8706/
/8/2025-12-11/
/8/
Thu Dec 11 14:30:25 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:31:50 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8709/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8709/8709-video.mp4
/2/2025-12-11/8709/snapshot.jpg
/2/2025-12-11/8709/alarm.jpg
Thu Dec 11 14:32:00 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:32:04 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8710/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8710/8710-video.mp4
/2/2025-12-11/8710/snapshot.jpg
/2/2025-12-11/8710/alarm.jpg
Thu Dec 11 14:32:11 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:32:45 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8711/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8711/8711-video.mp4
/2/2025-12-11/8711/snapshot.jpg
/2/2025-12-11/8711/alarm.jpg
Thu Dec 11 14:32:51 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:37:36 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/3/2025-12-11/8712/
/3/2025-12-11/
/3/
/
/3/2025-12-11/8712/8712-video.mp4
/3/2025-12-11/8712/snapshot.jpg
/3/2025-12-11/8712/alarm.jpg
Thu Dec 11 14:37:41 2025 Normal: Finished a list after exitcode: 0
[root@nvr system]#</nowiki>

Note: If you receive errors similar to "maximum number of watches reached" in the logs you may need to increase the default limits on your system for /proc/sys/fs/inotify/max_user_instances and /proc/sys/fs/inotify/max_user_watches. See here for more details;

https://support.scc.suse.com/s/kb/360054835111?language=en_US

I'm happy to again have offsite copies of all my events now. While they are not tracked in the Zoneminder database, they are still saved in folders by monitor id and date for easy retrieval should the ZM database become unavailable. Props to the ZM devs for their great software, and I hope this writeup proves useful to some other users in the future.

==See Also==
* https://github.com/lsyncd/lsyncd/issues/668 - Beware that lsync will do rsync with deletes on by default. With some casual testing, you might inadvertedly delete your home directory or root filesystem. From the github: "''I was told many times delete by default was a bad idea and was a result of the usual use case in the sense of replicating the target exactly like the source. I suppose the people telling so have a point.''"
* https://docs.rockylinux.org/10/books/learning_rsync/06_rsync_inotify/
* https://linuxvox.com/blog/what-is-the-proper-way-to-use-inotify/ - Using inotify-tools command line interface
* https://www.cyberciti.biz/faq/linux-inotify-examples-to-replicate-directories/ - Probably easier than lsyncd. (Was not available in default Debian Bullseye (have to use backports https://qa.debian.org/madison.php?package=incron&table=archived&a=&c=&s=#) but is in most other Debian releases.).
* https://wiki.alpinelinux.org/wiki/Inotifyd
* https://wiki.archlinux.org/title/Incron

Realtime event backup to cloud storage

2025-12-17T18:02:44Z

Kernelkurtz:

It's possible to use lsync daemon, which leverages the inotify https://en.wikipedia.org/wiki/Inotify kernel subsystem to run triggers based on events in a directory (create, modify, delete). Triggers can be varied (you can run any arbitrary command) but in the default use case, is as a filesystem backup / clone using the rsync command.

You may also want to consider other options. Inotify has command line tools, and there is an incrond, which uses cron syntax to run commands based on inotify.

==About==
After recently migrating from another popular NVR software on Windows to Zoneminder on Linux I started looking for a way to do near-real-time backups of my events to offsite storage, simply as a way to have a copy should the local ZM server be compromised by break-in, fire, etc. Software such as Dropbox, Google Drive, etc. make it relatively easy to do this on Windows but the setup on Linux takes bit more effort.

I wanted to keep it as simple as possible and don't need my backup solution to interface with the ZM database at all. After experimenting with several other options, I have settled on an application called lsyncd. It runs as a service and leverages inotify and rsync to watch a directory or directories and mirror only new changes to another storage location. Lsyncd should be available as a package for most Linux distributions. I used the installation instructions here for my Rocky Linux system;

https://docs.rockylinux.org/10/guides/backup/mirroring_lsyncd/

At this point it is worthwhile to at least skim through the docs.

https://lsyncd.github.io/lsyncd/manual/config/file/

https://linux.die.net/man/1/rsync

Both lsyncd and rsync are highly configurable and incredibly powerful. For many people the use case will be very simple like my own which I will describe here - watch my Zoneminder storage location and copy new files to a remote location, but much more complex configurations are certainly possible. In my case I'll be writing to an Amazon S3 bucket which I have already setup using S3FS-FUSE according to the documentation here;

https://zoneminder.readthedocs.io/en/latest/userguide/options/options_storage.html

Note you do not need to add the S3FS as a storage location in ZM to use lsyncd to copy files there, that is only required for ZM to write events directly to S3. Configuring rsync is beyond the scope of this document but this solution will work with any target that rsync is capable of writing to. Make sure your remote location is accessible via rsync before proceeding.

==Setup==

Once lsyncd is installed you will need to create a configuration file in /etc/lsyncd.conf. I've included mine as an example below. Note this script uses LUA syntax, not bash. Be '''VERY CAREFUL''' if you are testing remote write/sync/copy operations to a destination that already has important data on it (see links below). I highly recommend initial testing with an empty bucket or target filesystem. You have been warned.

<nowiki>settings {

logfile = "/var/log/lsyncd.log",

statusFile = "/var/log/lsyncd-status.log",

statusInterval = 10,

maxProcesses = 1,

insist = true,

}

sync {

default.rsync,

source = "/home/Cameras",

target = "/media/aws",

delete = false,

delay = 10,

init = false,

rsync = {

archive = true,

ignore_times = true,

compress = false

}

}</nowiki>

''logfile = '' is pretty self-explanatory. Be sure to set up log rotation after you are done setting lsyncd up, if required.

''maxProcesses = 1'' is the default. If you are syncing multiple sources or targets you may want to increase this.

''insist = true'' allows the service to start even if the target is not ready. I got errors without this which went away when I added it. YMMV.

''source = ''The directory where ZM events are stored.

''target = ''The location to copy events to. Must be accessible via rsync. In my case it is the mount point for the S3FS configured previously.

''targetdir = "/somedirectory"'' (not shown, part of sync block) subdirectory to use on the target. I'm just using the root directory in a dedicated bucket. You may not want this and should specify something here.

''delay = ''This is how often rsync will run if there are any filesystem changes. Default is 15 seconds. For many users this will be close enough to real-time for the purpose. This can be combined with (or substituted) for another value in the settings field;

''maxDelay = # '' (not shown, part of settings block) will queue this # of file changes before calling rsync. Between delay and/or maxDelay it is possible to tune the timing of your file copies to your exact preference. inotify waits for write_close to add files to the transfer list so there are no issues with rsync trying to upload uncompleted files. I typically only record short 10 second clips. If you use your cameras to continuously record be aware that files in the process of being written will not be copied until they are closed.

''archive = true ''This preserves ownership and permissions on the copied files.

''ignore_times = true'' This sets rsync's --ignore-times directive. For the purpose it is being used here it is safe to assume you will never have a newer copy of the files you are uploading already existing in your destination. Removing this check reduces API calls and is a noticeable optimization for AWS. If your cloud provider does not meter traffic you probably won't notice any difference with this either way.

Two other very important variables in this file are;

''delete = false'' this is also pretty self explanatory, file deletes will not be synced from source to target. In the case of my S3 bucket I have lifecycle rules that handle this. If you prefer for your remote storage location to synchronize the deletions made by Zoneminder you can set this to true. This also means if you accidentally delete events from your local storage they will be deleted from the cloud as well. Use with caution.

''init = false'' causes the lsyncd to not do a complete initial synchronization between source and target on service startup. On S3 this is expensive in terms of API calls and may take a while. I know I'm going to miss some events during system maintenance/OS updates etc anyway so I don't consider this worth the cost, but you can set to true if you want it. Be warned it will make your target an exact mirror of your source.

Having delete and init set to false also should make this config fairly safe to use against an existing target if you just run it on your machine without heeding my previous warning. Don't change or remove these unless you are absolutely sure you know what you are doing. There are also options besides true and false so read the docs for more info. You can also add options to be added directly to the rsync calls. You can sync multiple directories to multiple targets with multiple options. There are exclude options which you may find useful. It is far too much to cover here but the simple config above is all I need for my purposes.

Once the service is configured you can control it with systemctl like any other systemd service. By default it will be disabled so you will need to enable it to run automatically after suitable testing. You can check the logs for startup or running errors with journalctl. If syncs are working correctly you can watch them as uploads are logged very shortly after the events are saved to local disk;

<nowiki>[root@nvr system]# tail -50 /var/log/lsyncd.log
/1/2025-12-11/8707/8707-video.mp4
/1/2025-12-11/8707/snapshot.jpg
/1/2025-12-11/8707/alarm.jpg
/6/2025-12-11/8708/
/6/2025-12-11/
/6/
/6/2025-12-11/8708/8708-video.mp4
/6/2025-12-11/8708/snapshot.jpg
/6/2025-12-11/8708/alarm.jpg
/8/2025-12-11/8706/8706-video.mp4
/8/2025-12-11/8706/
/8/2025-12-11/
/8/
Thu Dec 11 14:30:25 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:31:50 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8709/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8709/8709-video.mp4
/2/2025-12-11/8709/snapshot.jpg
/2/2025-12-11/8709/alarm.jpg
Thu Dec 11 14:32:00 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:32:04 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8710/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8710/8710-video.mp4
/2/2025-12-11/8710/snapshot.jpg
/2/2025-12-11/8710/alarm.jpg
Thu Dec 11 14:32:11 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:32:45 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8711/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8711/8711-video.mp4
/2/2025-12-11/8711/snapshot.jpg
/2/2025-12-11/8711/alarm.jpg
Thu Dec 11 14:32:51 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:37:36 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/3/2025-12-11/8712/
/3/2025-12-11/
/3/
/
/3/2025-12-11/8712/8712-video.mp4
/3/2025-12-11/8712/snapshot.jpg
/3/2025-12-11/8712/alarm.jpg
Thu Dec 11 14:37:41 2025 Normal: Finished a list after exitcode: 0
[root@nvr system]#</nowiki>

Note: If you receive errors similar to "maximum number of watches reached" in the logs you may need to increase the default limits on your system for /proc/sys/fs/inotify/max_user_instances and /proc/sys/fs/inotify/max_user_watches. See here for more details;

https://support.scc.suse.com/s/kb/360054835111?language=en_US

I'm happy to again have offsite copies of all my events now. While they are not tracked in the Zoneminder database, they are still saved in folders by monitor id and date for easy retrieval should the ZM database become unavailable. Props to the ZM devs for their great software, and I hope this writeup proves useful to some other users in the future.

==See Also==
* https://github.com/lsyncd/lsyncd/issues/668 - Beware that lsync will do rsync with deletes on by default. With some casual testing, you might inadvertedly delete your home directory or root filesystem. From the github: "''I was told many times delete by default was a bad idea and was a result of the usual use case in the sense of replicating the target exactly like the source. I suppose the people telling so have a point.''"
* https://docs.rockylinux.org/10/books/learning_rsync/06_rsync_inotify/
* https://linuxvox.com/blog/what-is-the-proper-way-to-use-inotify/ - Using inotify-tools command line interface
* https://www.cyberciti.biz/faq/linux-inotify-examples-to-replicate-directories/ - Probably easier than lsyncd. (Was not available in default Debian Bullseye (have to use backports https://qa.debian.org/madison.php?package=incron&table=archived&a=&c=&s=#) but is in most other Debian releases.).
* https://wiki.alpinelinux.org/wiki/Inotifyd
* https://wiki.archlinux.org/title/Incron

Realtime event backup to cloud storage

2025-12-17T16:35:53Z

Kernelkurtz: Ignore times S3 optimization

It's possible to use lsync daemon, which leverages the inotify https://en.wikipedia.org/wiki/Inotify kernel subsystem to run triggers based on events in a directory (create, modify, delete). Triggers can be varied (you can run any arbitrary command) but in the default use case, is as a filesystem backup / clone using the rsync command.

You may also want to consider other options. Inotify has command line tools, and there is an incrond, which uses cron syntax to run commands based on inotify.

==About==
After recently migrating from another popular NVR software on Windows to Zoneminder on Linux I started looking for a way to do near-real-time backups of my events to offsite storage, simply as a way to have a copy should the local ZM server be compromised by break-in, fire, etc. Software such as Dropbox, Google Drive, etc. make it relatively easy to do this on Windows but the setup on Linux takes bit more effort.

I wanted to keep it as simple as possible and don't need my backup solution to interface with the ZM database at all. After experimenting with several other options, I have settled on an application called lsyncd. It runs as a service and leverages inotify and rsync to watch a directory or directories and mirror only new changes to another storage location. Lsyncd should be available as a package for most Linux distributions. I used the installation instructions here for my Rocky Linux system;

https://docs.rockylinux.org/10/guides/backup/mirroring_lsyncd/

At this point it is worthwhile to at least skim through the docs.

https://lsyncd.github.io/lsyncd/manual/config/file/

https://linux.die.net/man/1/rsync

Both lsyncd and rsync are highly configurable and incredibly powerful. For many people the use case will be very simple like my own which I will describe here - watch my Zoneminder storage location and copy new files to a remote location, but much more complex configurations are certainly possible. In my case I'll be writing to an Amazon S3 bucket which I have already setup using S3FS-FUSE according to the documentation here;

https://zoneminder.readthedocs.io/en/latest/userguide/options/options_storage.html

Note you do not need to add the S3FS as a storage location in ZM to use lsyncd to copy files there, that is only required for ZM to write events directly to S3. Configuring rsync is beyond the scope of this document but this solution will work with any target that rsync is capable of writing to. Make sure your remote location is accessible via rsync before proceeding.

==Setup==

Once lsyncd is installed you will need to create a configuration file in /etc/lsyncd.conf. I've included mine as an example below. Note this script uses LUA syntax, not bash. Be '''VERY CAREFUL''' if you are testing remote write/sync/copy operations to a destination that already has important data on it (see links below). I highly recommend initial testing with an empty bucket or target filesystem. You have been warned.

<nowiki>settings {

logfile = "/var/log/lsyncd.log",

statusFile = "/var/log/lsyncd-status.log",

statusInterval = 10,

maxProcesses = 1,

insist = true,

}

sync {

default.rsync,

source = "/home/Cameras",

target = "/media/aws",

delete = false,

delay = 10,

init = false,

rsync = {

archive = true,

ignore_times = true,

compress = false

}

}</nowiki>

''logfile = '' is pretty self-explanatory. Be sure to set up log rotation after you are done setting lsyncd up, if required.

''maxProcesses = 1'' is the default. If you are syncing multiple sources or targets you may want to increase this.

''insist = true'' allows the service to start even if the target is not ready. I got errors without this which went away when I added it. YMMV.

''source = ''The directory where ZM events are stored.

''target = ''The location to copy events to. Must be accessible via rsync. In my case it is the mount point for the S3FS configured previously.

''targetdir = "/somedirectory"'' (not shown, part of sync block) subdirectory to use on the target. I'm just using the root directory in a dedicated bucket. You may not want this and should specify something here.

''delay = ''This is how often rsync will run if there are any filesystem changes. Default is 15 seconds. For many users this will be close enough to real-time for the purpose. This can be combined with (or substituted) for another value in the settings field;

''maxDelay = # '' (not shown, part of settings block) will queue this # of file changes before calling rsync. Between delay and/or maxDelay it is possible to tune the timing of your file copies to your exact preference. inotify waits for write_close to add files to the transfer list so there are no issues with rsync trying to upload uncompleted files. I typically only record short 10 second clips. If you use your cameras to continuously record be aware that files in the process of being written will not be copied until they are closed.

''archive = true ''This preserves ownership and permissions on the copied files.

''ignore_times = true'' This sets rsync's --ignore-times directive. For the purposes it is being used here it is assumed you will never have a newer copy of the files you are uploading already existing in your destination. Removing this check reduces API calls and is a noticeable optimization for AWS. If your cloud provider does not meter traffic you probably won't notice any difference with this either way.

Two other very important variables in this file are;

''delete = false'' this is also pretty self explanatory, file deletes will not be synced from source to target. In the case of my S3 bucket I have lifecycle rules that handle this. If you prefer for your remote storage location to synchronize the deletions made by Zoneminder you can set this to true. This also means if you accidentally delete events from your local storage they will be deleted from the cloud as well. Use with caution.

''init = false'' causes the lsyncd to not do a complete initial synchronization between source and target on service startup. On S3 this is expensive in terms of API calls and may take a while. I know I'm going to miss some events during system maintenance/OS updates etc anyway so I don't consider this worth the cost, but you can set to true if you want it. Be warned it will make your target an exact mirror of your source.

Having delete and init set to false also should make this config fairly safe to use against an existing target if you just run it on your machine without heeding my previous warning. Don't change or remove these unless you are absolutely sure you know what you are doing. There are also options besides true and false so read the docs for more info. You can also add options to be added directly to the rsync calls. You can sync multiple directories to multiple targets with multiple options. There are exclude options which you may find useful. It is far too much to cover here but the simple config above is all I need for my purposes.

Once the service is configured you can control it with systemctl like any other systemd service. By default it will be disabled so you will need to enable it to run automatically after suitable testing. You can check the logs for startup or running errors with journalctl. If syncs are working correctly you can watch them as uploads are logged very shortly after the events are saved to local disk;

<nowiki>[root@nvr system]# tail -50 /var/log/lsyncd.log
/1/2025-12-11/8707/8707-video.mp4
/1/2025-12-11/8707/snapshot.jpg
/1/2025-12-11/8707/alarm.jpg
/6/2025-12-11/8708/
/6/2025-12-11/
/6/
/6/2025-12-11/8708/8708-video.mp4
/6/2025-12-11/8708/snapshot.jpg
/6/2025-12-11/8708/alarm.jpg
/8/2025-12-11/8706/8706-video.mp4
/8/2025-12-11/8706/
/8/2025-12-11/
/8/
Thu Dec 11 14:30:25 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:31:50 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8709/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8709/8709-video.mp4
/2/2025-12-11/8709/snapshot.jpg
/2/2025-12-11/8709/alarm.jpg
Thu Dec 11 14:32:00 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:32:04 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8710/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8710/8710-video.mp4
/2/2025-12-11/8710/snapshot.jpg
/2/2025-12-11/8710/alarm.jpg
Thu Dec 11 14:32:11 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:32:45 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8711/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8711/8711-video.mp4
/2/2025-12-11/8711/snapshot.jpg
/2/2025-12-11/8711/alarm.jpg
Thu Dec 11 14:32:51 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:37:36 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/3/2025-12-11/8712/
/3/2025-12-11/
/3/
/
/3/2025-12-11/8712/8712-video.mp4
/3/2025-12-11/8712/snapshot.jpg
/3/2025-12-11/8712/alarm.jpg
Thu Dec 11 14:37:41 2025 Normal: Finished a list after exitcode: 0
[root@nvr system]#</nowiki>

Note: If you receive errors similar to "maximum number of watches reached" in the logs you may need to increase the default limits on your system for /proc/sys/fs/inotify/max_user_instances and /proc/sys/fs/inotify/max_user_watches. See here for more details;

https://support.scc.suse.com/s/kb/360054835111?language=en_US

I'm happy to again have offsite copies of all my events now. While they are not tracked in the Zoneminder database, they are still saved in folders by monitor id and date for easy retrieval should the ZM database become unavailable. Props to the ZM devs for their great software, and I hope this writeup proves useful to some other users in the future.

==See Also==
* https://github.com/lsyncd/lsyncd/issues/668 - Beware that lsync will do rsync with deletes on by default. With some casual testing, you might inadvertedly delete your home directory or root filesystem. From the github: "''I was told many times delete by default was a bad idea and was a result of the usual use case in the sense of replicating the target exactly like the source. I suppose the people telling so have a point.''"
* https://docs.rockylinux.org/10/books/learning_rsync/06_rsync_inotify/
* https://linuxvox.com/blog/what-is-the-proper-way-to-use-inotify/ - Using inotify-tools command line interface
* https://www.cyberciti.biz/faq/linux-inotify-examples-to-replicate-directories/ - Probably easier than lsyncd. (Was not available in default Debian Bullseye (have to use backports https://qa.debian.org/madison.php?package=incron&table=archived&a=&c=&s=#) but is in most other Debian releases.).
* https://wiki.alpinelinux.org/wiki/Inotifyd
* https://wiki.archlinux.org/title/Incron

Realtime event backup to cloud storage

2025-12-13T19:15:04Z

Kernelkurtz:

After recently migrating from another popular NVR software on Windows to Zoneminder on Linux I started looking for a way to do near-real-time backups of my events to offsite storage, simply as a way to have a copy should the local ZM server be compromised by break-in, fire, etc. Software such as Dropbox, Google Drive, etc. make it relatively easy to do this on Windows but the setup on Linux takes bit more effort.

I wanted to keep it as simple as possible and don't need my backup solution to interface with the ZM database at all. After experimenting with several other options, I have settled on an application called lsyncd. It runs as a service and leverages inotify and rsync to watch a directory or directories and mirror only new changes to another storage location. Lsyncd should be available as a package for most Linux distributions. I used the installation instructions here for my Rocky Linux system;

https://docs.rockylinux.org/10/guides/backup/mirroring_lsyncd/

At this point it is worthwhile to at least skim through the docs.

https://lsyncd.github.io/lsyncd/manual/config/file/

https://linux.die.net/man/1/rsync

Both lsyncd and rsync are highly configurable and incredibly powerful. For many people the use case will be very simple like my own which I will describe here - watch my Zoneminder storage location and copy new files to a remote location, but much more complex configurations are certainly possible. In my case I'll be writing to an Amazon S3 bucket which I have already setup using S3FS-FUSE according to the documentation here;

https://zoneminder.readthedocs.io/en/latest/userguide/options/options_storage.html

Note you do not need to add the S3FS as a storage location in ZM to use lsyncd to copy files there, that is only required for ZM to write events directly to S3. Configuring rsync is beyond the scope of this document but this solution will work with any target that rsync is capable of writing to. Make sure your remote location is accessible via rsync before proceeding.

Once lsyncd is installed you will need to create a configuration file in /etc/lsyncd.conf. I've included mine as an example below. Note this script uses LUA syntax, not bash. Be VERY CAREFUL if you are testing remote write/sync/copy operations to a destination that already has important data on it. I highly recommend initial testing with an empty bucket or target filesystem. You have been warned.

<nowiki>settings {

logfile = "/var/log/lsyncd.log",

statusFile = "/var/log/lsyncd-status.log",

statusInterval = 10,

maxProcesses = 1,

insist = true,

}

sync {

default.rsync,

source = "/home/Cameras",

target = "/media/aws",

delete = false,

delay = 10,

init = false,

rsync = {

archive = true,

compress = false

}

}</nowiki>

''logfile = '' is pretty self-explanatory. Be sure to set up log rotation after you are done setting lsyncd up, if required.

''maxProcesses = 1'' is the default. If you are syncing multiple sources or targets you may want to increase this.

''insist = true'' allows the service to start even if the target is not ready. I got errors without this which went away when I added it. YMMV.

''source = ''The directory where ZM events are stored.

''target = ''The location to copy events to. Must be accessible via rsync. In my case it is the mount point for the S3FS configured previously.

''targetdir = "/somedirectory"'' (not shown, part of sync block) subdirectory to use on the target. I'm just using the root directory in a dedicated bucket. You may not want this and should specify something here.

''delay = ''This is how often rsync will run if there are any filesystem changes. Default is 15 seconds. For many users this will be close enough to real-time for the purpose. This can be combined with (or substituted) for another value in the settings field;

''maxDelay = # '' (not shown, part of settings block) will queue this # of file changes before calling rsync. Between delay and/or maxDelay it is possible to tune the timing of your file copies to your exact preference. inotify waits for write_close to add files to the transfer list so there are no issues with rsync trying to upload uncompleted files. I typically only record short 10 second clips. If you use your cameras to continuously record be aware that files in the process of being written will not be copied until they are closed.

''archive = true ''This preserves permissions on the copied files.

Two other very important variables in this file are;

''delete = false'' this is also pretty self explanatory, file deletes will not be synced from source to target. In the case of my S3 bucket I have lifecycle rules that handle this. If you prefer for your remote storage location to synchronize the deletions made by Zoneminder you can set this to true. This also means if you accidentally delete events from your local storage they will be deleted from the cloud as well. Use with caution.

''init = false'' causes the lsyncd to not do a complete initial synchronization between source and target on service startup. On S3 this is expensive in terms of API calls and may take a while. I know I'm going to miss some events during system maintenance/OS updates etc anyway so I don't consider this worth the cost, but you can set to true if you want it. Be warned it will make your target an exact mirror of your source.

Having delete and init set to false also should make this config fairly safe to use against an existing target if you just run it on your machine without heeding my previous warning. Don't change these unless you are absolutely sure you know what you are doing. There are also options besides true and false so read the docs for more info. You can also add options to be added directly to the rsync calls. You can sync multiple directories to multiple targets with multiple options. There are exclude options which you may find useful. It is far too much to cover here so read the docs, but the simple config above is all I need for my purposes.

Once the service is configured you can control it with systemctl like any other systemd service. By default it will be disabled so you will need to enable it to run automatically after suitable testing. You can check the logs for startup or running errors with journalctl. If syncs are working correctly you can watch them as uploads are logged very shortly after the events are saved to local disk;

<nowiki>[root@nvr system]# tail -50 /var/log/lsyncd.log
/1/2025-12-11/8707/8707-video.mp4
/1/2025-12-11/8707/snapshot.jpg
/1/2025-12-11/8707/alarm.jpg
/6/2025-12-11/8708/
/6/2025-12-11/
/6/
/6/2025-12-11/8708/8708-video.mp4
/6/2025-12-11/8708/snapshot.jpg
/6/2025-12-11/8708/alarm.jpg
/8/2025-12-11/8706/8706-video.mp4
/8/2025-12-11/8706/
/8/2025-12-11/
/8/
Thu Dec 11 14:30:25 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:31:50 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8709/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8709/8709-video.mp4
/2/2025-12-11/8709/snapshot.jpg
/2/2025-12-11/8709/alarm.jpg
Thu Dec 11 14:32:00 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:32:04 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8710/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8710/8710-video.mp4
/2/2025-12-11/8710/snapshot.jpg
/2/2025-12-11/8710/alarm.jpg
Thu Dec 11 14:32:11 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:32:45 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8711/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8711/8711-video.mp4
/2/2025-12-11/8711/snapshot.jpg
/2/2025-12-11/8711/alarm.jpg
Thu Dec 11 14:32:51 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:37:36 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/3/2025-12-11/8712/
/3/2025-12-11/
/3/
/
/3/2025-12-11/8712/8712-video.mp4
/3/2025-12-11/8712/snapshot.jpg
/3/2025-12-11/8712/alarm.jpg
Thu Dec 11 14:37:41 2025 Normal: Finished a list after exitcode: 0
[root@nvr system]#</nowiki>

Note: If you receive errors similar to "maximum number of watches reached" in the logs you may need to increase the default limits on your system for /proc/sys/fs/inotify/max_user_instances and /proc/sys/fs/inotify/max_user_watches. See here for more details;

https://support.scc.suse.com/s/kb/360054835111?language=en_US

I'm happy to have offsite copies of all my events now. While they are not tracked in the Zoneminder database, they are still saved in folders by monitor id and date for easy retrieval should the ZM database become unavailable. Props to the ZM devs for their great software, and I hope this writeup proves useful to some other users in the future.

Realtime event backup to cloud storage

2025-12-13T19:13:33Z

Kernelkurtz: Added increase watch # info

After recently migrating from another popular NVR software on Windows to Zoneminder on Linux I started looking for a way to do near-real-time backups of my events to offsite storage, simply as a way to have a copy should the local ZM server be compromised by break-in, fire, etc. Software such as Dropbox, Google Drive, etc. make it relatively easy to do this on Windows but the setup on Linux takes bit more effort.

I wanted to keep it as simple as possible and don't need my backup solution to interface with the ZM database at all. After experimenting with several other options, I have settled on an application called lsyncd. It runs as a service and leverages inotify and rsync to watch a directory or directories and mirror only new changes to another storage location. Lsyncd should be available as a package for most Linux distributions. I used the installation instructions here for my Rocky Linux system;

https://docs.rockylinux.org/10/guides/backup/mirroring_lsyncd/

At this point it is worthwhile to at least skim through the docs.

https://lsyncd.github.io/lsyncd/manual/config/file/

https://linux.die.net/man/1/rsync

Both lsyncd and rsync are highly configurable and incredibly powerful. For many people the use case will be very simple like my own which I will describe here - watch my Zoneminder storage location and copy new files to a remote location, but much more complex configurations are certainly possible. In my case I'll be writing to an Amazon S3 bucket which I have already setup using S3FS-FUSE according to the documentation here;

https://zoneminder.readthedocs.io/en/latest/userguide/options/options_storage.html

Note you do not need to add the S3FS as a storage location in ZM to use lsyncd to copy files there, that is only required for ZM to write events directly to S3. Configuring rsync is beyond the scope of this document but this solution will work with any target that rsync is capable of writing to. Make sure your remote location is accessible via rsync before proceeding.

Once lsyncd is installed you will need to create a configuration file in /etc/lsyncd.conf. I've included mine as an example below. Note this script uses LUA syntax, not bash. Be VERY CAREFUL if you are testing remote write/sync/copy operations to a destination that already has important data on it. I highly recommend initial testing with an empty bucket or target filesystem. You have been warned.

<nowiki>settings {

logfile = "/var/log/lsyncd.log",

statusFile = "/var/log/lsyncd-status.log",

statusInterval = 10,

maxProcesses = 1,

insist = true,

}

sync {

default.rsync,

source = "/home/Cameras",

target = "/media/aws",

delete = false,

delay = 10,

init = false,

rsync = {

archive = true,

compress = false

}

}</nowiki>

''logfile = '' is pretty self-explanatory. Be sure to set up log rotation after you are done setting lsyncd up, if required.

''maxProcesses = 1'' is the default. If you are syncing multiple sources or targets you may want to increase this.

''insist = true'' allows the service to start even if the target is not ready. I got errors without this which went away when I added it. YMMV.

''source = ''The directory where ZM events are stored.

''target = ''The location to copy events to. Must be accessible via rsync. In my case it is the mount point for the S3FS configured previously.

''targetdir = "/somedirectory"'' (not shown, part of sync block) subdirectory to use on the target. I'm just using the root directory in a dedicated bucket. You may not want this and should specify something here.

''delay = ''This is how often rsync will run if there are any filesystem changes. Default is 15 seconds. For many users this will be close enough to real-time for the purpose. This can be combined with (or substituted) for another value in the settings field;

''maxDelay = # '' (not shown, part of settings block) will queue this # of file changes before calling rsync. Between delay and/or maxDelay it is possible to tune the timing of your file copies to your exact preference. inotify waits for write_close to add files to the transfer list so there are no issues with rsync trying to upload uncompleted files. I typically only record short 10 second clips. If you use your cameras to continuously record be aware that files in the process of being written will not be copied until they are closed.

''archive = true ''This preserves permissions on the copied files.

Two other very important variables in this file are;

''delete = false'' this is pretty self explanatory, file deletes will not be synced from source to target. In the case of my S3 bucket I have lifecycle rules that handle this. If you prefer for your remote storage location to synchronize the deletions made by Zoneminder you can set this to true. This also means if you accidentally delete events from your local storage they will be deleted from the cloud as well. Use with caution.

''init = false'' causes the lsyncd to not do a complete initial synchronization between source and target on service startup. On S3 this is expensive in terms of API calls and may take a while. I know I'm going to miss some events during system maintenance/OS updates etc anyway so I don't consider this worth the cost, but you can set to true if you want it. Be warned it will make your target an exact mirror of your source.

Having delete and init set to false also should make this config fairly safe to use against an existing target if you just run it on your machine without heeding my previous warning. Don't change these unless you are absolutely sure you know what you are doing. There are also options besides true and false so read the docs for more info. You can also add options to be added directly to the rsync calls. You can sync multiple directories to multiple targets with multiple options. There are exclude options which you may find useful. It is far too much to cover here so read the docs, but the simple config above is all I need for my purposes.

Once the service is configured you can control it with systemctl like any other systemd service. By default it will be disabled so you will need to enable it to run automatically after suitable testing. You can check the logs for startup or running errors with journalctl. If syncs are working correctly you can watch them as uploads are logged very shortly after the events are saved to local disk;

<nowiki>[root@nvr system]# tail -50 /var/log/lsyncd.log
/1/2025-12-11/8707/8707-video.mp4
/1/2025-12-11/8707/snapshot.jpg
/1/2025-12-11/8707/alarm.jpg
/6/2025-12-11/8708/
/6/2025-12-11/
/6/
/6/2025-12-11/8708/8708-video.mp4
/6/2025-12-11/8708/snapshot.jpg
/6/2025-12-11/8708/alarm.jpg
/8/2025-12-11/8706/8706-video.mp4
/8/2025-12-11/8706/
/8/2025-12-11/
/8/
Thu Dec 11 14:30:25 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:31:50 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8709/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8709/8709-video.mp4
/2/2025-12-11/8709/snapshot.jpg
/2/2025-12-11/8709/alarm.jpg
Thu Dec 11 14:32:00 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:32:04 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8710/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8710/8710-video.mp4
/2/2025-12-11/8710/snapshot.jpg
/2/2025-12-11/8710/alarm.jpg
Thu Dec 11 14:32:11 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:32:45 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8711/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8711/8711-video.mp4
/2/2025-12-11/8711/snapshot.jpg
/2/2025-12-11/8711/alarm.jpg
Thu Dec 11 14:32:51 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:37:36 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/3/2025-12-11/8712/
/3/2025-12-11/
/3/
/
/3/2025-12-11/8712/8712-video.mp4
/3/2025-12-11/8712/snapshot.jpg
/3/2025-12-11/8712/alarm.jpg
Thu Dec 11 14:37:41 2025 Normal: Finished a list after exitcode: 0
[root@nvr system]#</nowiki>

Note: If you receive errors similar to "maximum number of watches reached" in the logs you may need to increase the default limits on your system for /proc/sys/fs/inotify/max_user_instances and /proc/sys/fs/inotify/max_user_watches. See here for more details;

https://support.scc.suse.com/s/kb/360054835111?language=en_US

I'm happy to have offsite copies of all my events now. While they are not tracked in the Zoneminder database, they are still saved in folders by monitor id and date for easy retrieval should the ZM database become unavailable. Props to the ZM devs for their great software, and I hope this writeup proves useful to some other users in the future.

Realtime event backup to cloud storage

2025-12-13T02:40:41Z

Kernelkurtz: Better language

After recently migrating from another popular NVR software on Windows to Zoneminder on Linux I started looking for a way to do near-real-time backups of my events to offsite storage, simply as a way to have a copy should the local ZM server be compromised by break-in, fire, etc. Software such as Dropbox, Google Drive, etc. make it relatively easy to do this on Windows but the setup on Linux takes bit more effort.

I wanted to keep it as simple as possible and don't need my backup solution to interface with the ZM database at all. After experimenting with several other options, I have settled on an application called lsyncd. It runs as a service and leverages inotify and rsync to watch a directory or directories and mirror only new changes to another storage location. Lsyncd should be available as a package for most Linux distributions. I used the installation instructions here for my Rocky Linux system;

https://docs.rockylinux.org/10/guides/backup/mirroring_lsyncd/

At this point it is worthwhile to at least skim through the docs.

https://lsyncd.github.io/lsyncd/manual/config/file/

https://linux.die.net/man/1/rsync

Both lsyncd and rsync are highly configurable and incredibly powerful. For many people the use case will be very simple like my own which I will describe here - watch my Zoneminder storage location and copy new files to a remote location, but much more complex configurations are certainly possible. In my case I'll be writing to an Amazon S3 bucket which I have already setup using S3FS-FUSE according to the documentation here;

https://zoneminder.readthedocs.io/en/latest/userguide/options/options_storage.html

Note you do not need to add the S3FS as a storage location in ZM to use lsyncd to copy files there, that is only required for ZM to write events directly to S3. Configuring rsync is beyond the scope of this document but this solution will work with any target that rsync is capable of writing to. Make sure your remote location is accessible via rsync before proceeding.

Once lsyncd is installed you will need to create a configuration file in /etc/lsyncd.conf. I've included mine as an example below. Note this script uses LUA syntax, not bash. Be VERY CAREFUL if you are testing remote write/sync/copy operations to a destination that already has important data on it. I highly recommend initial testing with an empty bucket or target filesystem. You have been warned.

<nowiki>settings {

logfile = "/var/log/lsyncd.log",

statusFile = "/var/log/lsyncd-status.log",

statusInterval = 10,

maxProcesses = 1,

insist = true,

}

sync {

default.rsync,

source = "/home/Cameras",

target = "/media/aws",

delete = false,

delay = 10,

init = false,

rsync = {

archive = true,

compress = false

}

}</nowiki>

''logfile = '' is pretty self-explanatory. Be sure to set up log rotation after you are done setting lsyncd up, if required.

''maxProcesses = 1'' is the default. If you are syncing multiple sources or targets you may want to increase this.

''insist = true'' allows the service to start even if the target is not ready. I got errors without this which went away when I added it. YMMV.

''source = ''The directory where ZM events are stored.

''target = ''The location to copy events to. Must be accessible via rsync. In my case it is the mount point for the S3FS configured previously.

''targetdir = "/somedirectory"'' (not shown, part of sync block) subdirectory to use on the target. I'm just using the root directory in a dedicated bucket. You may not want this and should specify something here.

''delay = ''This is how often rsync will run if there are any filesystem changes. Default is 15 seconds. For many users this will be close enough to real-time for the purpose. This can be combined with (or substituted) for another value in the settings field;

''maxDelay = # '' (not shown, part of settings block) will queue this # of file changes before calling rsync. Between delay and/or maxDelay it is possible to tune the timing of your file copies to your exact preference. inotify waits for write_close to add files to the transfer list so there are no issues with rsync trying to upload uncompleted files. I typically only record short 10 second clips. If you use your cameras to continuously record be aware that files in the process of being written will not be copied until they are closed.

''archive = true ''This preserves permissions on the copied files.

Two other very important variables in this file are;

''delete = false'' this is pretty self explanatory, file deletes will not be synced from source to target. In the case of my S3 bucket I have lifecycle rules that handle this. If you prefer for your remote storage location to synchronize the deletions made by Zoneminder you can set this to true. This also means if you accidentally delete events from your local storage they will be deleted from the cloud as well. Use with caution.

''init = false'' causes the lsyncd to not do a complete initial synchronization between source and target on service startup. On S3 this is expensive in terms of API calls and may take a while. I know I'm going to miss some events during system maintenance/OS updates etc anyway so I don't consider this worth the cost, but you can set to true if you want it. Be warned it will make your target an exact mirror of your source.

Having delete and init set to false also should make this config fairly safe to use against an existing target if you just run it on your machine without heeding my previous warning. Don't change these unless you are absolutely sure you know what you are doing. You can also add options to be added directly to the rsync calls. You can sync multiple directories to multiple targets with multiple options. There are exclude options which you may find useful. It is far too much to cover here so read the docs, but the simple config above is all I need for my purposes.

Once the service is configured you can control it with systemctl like any other systemd service. By default it will be disabled so you will need to enable it to run automatically after suitable testing. You can check the logs for startup or running errors with journalctl. If syncs are working correctly you can watch them as uploads are logged very shortly after the events are saved to local disk;

<nowiki>[root@nvr system]# tail -50 /var/log/lsyncd.log
/1/2025-12-11/8707/8707-video.mp4
/1/2025-12-11/8707/snapshot.jpg
/1/2025-12-11/8707/alarm.jpg
/6/2025-12-11/8708/
/6/2025-12-11/
/6/
/6/2025-12-11/8708/8708-video.mp4
/6/2025-12-11/8708/snapshot.jpg
/6/2025-12-11/8708/alarm.jpg
/8/2025-12-11/8706/8706-video.mp4
/8/2025-12-11/8706/
/8/2025-12-11/
/8/
Thu Dec 11 14:30:25 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:31:50 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8709/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8709/8709-video.mp4
/2/2025-12-11/8709/snapshot.jpg
/2/2025-12-11/8709/alarm.jpg
Thu Dec 11 14:32:00 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:32:04 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8710/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8710/8710-video.mp4
/2/2025-12-11/8710/snapshot.jpg
/2/2025-12-11/8710/alarm.jpg
Thu Dec 11 14:32:11 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:32:45 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8711/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8711/8711-video.mp4
/2/2025-12-11/8711/snapshot.jpg
/2/2025-12-11/8711/alarm.jpg
Thu Dec 11 14:32:51 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:37:36 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/3/2025-12-11/8712/
/3/2025-12-11/
/3/
/
/3/2025-12-11/8712/8712-video.mp4
/3/2025-12-11/8712/snapshot.jpg
/3/2025-12-11/8712/alarm.jpg
Thu Dec 11 14:37:41 2025 Normal: Finished a list after exitcode: 0
[root@nvr system]#</nowiki>

I'm happy to have offsite copies of all my events now. While they are not tracked in the Zoneminder database, they are still saved in folders by monitor id and date for easy retrieval should the ZM database become unavailable. Props to the ZM devs for their great software, and I hope this writeup proves useful to some other users in the future.

Realtime event backup to cloud storage

2025-12-13T00:27:31Z

Kernelkurtz:

After recently migrating from another popular NVR software on Windows to Zoneminder on Linux I started looking for a way to do near-real-time backups of my events to offsite storage, simply as a way to have a copy should the local ZM server be compromised by break-in, fire, etc. Software such as Dropbox, Google Drive, etc. make it relatively easy to do this on Windows but the setup on Linux takes bit more effort.

I wanted to keep it as simple as possible and don't need my backup solution to interface with the ZM database at all. After experimenting with several other options, I have settled on an application called lsyncd. It runs as a service and leverages inotify and rsync to watch a directory or directories and mirror only new changes to another storage location. Lsyncd should be available as a package for most Linux distributions. I used the installation instructions here for my Rocky Linux system;

https://docs.rockylinux.org/10/guides/backup/mirroring_lsyncd/

At this point it is worthwhile to at least skim through the docs.

https://lsyncd.github.io/lsyncd/manual/config/file/

https://linux.die.net/man/1/rsync

Both lsyncd and rsync are highly configurable and incredibly powerful. For many people the use case will be very simple like my own which I will describe here - watch my Zoneminder storage location and copy new files to a remote location, but much more complex configurations are certainly possible. In my case I'll be writing to an Amazon S3 bucket which I have already setup using S3FS-FUSE according to the documentation here;

https://zoneminder.readthedocs.io/en/latest/userguide/options/options_storage.html

Note you do not need to add the S3FS as a storage location in ZM to use lsyncd to copy files there, that is only required for ZM to write events directly to S3. Configuring rsync is beyond the scope of this document but this solution will work with any target that rsync is capable of writing to. Make sure your remote location is accessible via rsync before proceeding.

Once lsyncd is installed you will need to create a configuration file in /etc/lsyncd.conf. I've included mine as an example below. Note this script uses LUA syntax, not bash. Be VERY CAREFUL if you are testing remote write/sync/copy operations to a destination that already has important data on it. I highly recommend initial testing with an empty bucket or target filesystem. You have been warned.

<nowiki>settings {

logfile = "/var/log/lsyncd.log",

statusFile = "/var/log/lsyncd-status.log",

statusInterval = 10,

maxProcesses = 1,

insist = true,

}

sync {

default.rsync,

source = "/home/Cameras",

target = "/media/aws",

delete = false,

delay = 10,

init = false,

rsync = {

archive = true,

compress = false

}

}</nowiki>

''logfile = '' is pretty self-explanatory. Be sure to set up log rotation after you are done setting lsyncd up, if required.

''maxProcesses = 1'' is the default. If you are syncing multiple sources or targets you may want to increase this.

''insist = true'' allows the service to start even if the target is not ready. I got errors without this which went away when I added it. YMMV.

''source = ''The directory where ZM events are stored.

''target = ''The location to copy events to. Must be accessible via rsync. In my case it is the mount point for the S3FS configured previously.

''targetdir = "/somedirectory"'' (not shown, part of sync block) subdirectory to use on the target. I'm just using the root directory in a dedicated bucket. You may not want this and should specify something here.

''delay = ''this is how often to run rsync if it is not triggered by any filesystem changes. Default is 15 seconds. For many users this will be close enough to real-time for the purpose. This can be combined with (or substituted) for another value in the settings field;

''maxDelay = # '' (not shown, part of settings block) will queue this # of file changes before calling rsync. Between delay and/or maxDelay it is possible to tune the timing of your file copies to your exact preference. inotify waits for write_close to add files to the transfer list so there are no issues with rsync trying to upload uncompleted files. I typically only record short 10 second clips. If you use your cameras to continuously record be aware that files in the process of being written will not be copied until they are closed.

''archive = true ''This preserves permissions on the copied files.

Two other very important variables in this file are;

''delete = false'' this is pretty self explanatory, file deletes will not be synced from source to target. In the case of my S3 bucket I have lifecycle rules that handle this. If you prefer for your remote storage location to synchronize the deletions made by Zoneminder you can set this to true. This also means if you accidentally delete events from your local storage they will be deleted from the cloud as well. Use with caution.

''init = false'' causes the lsyncd to not do a complete initial synchronization between source and target on service startup. On S3 this is expensive in terms of API calls and may take a while. I know I'm going to miss some events during system maintenance/OS updates etc anyway so I don't consider this worth the cost, but you can set to true if you want it. Be warned it will make your target an exact mirror of your source.

Having delete and init set to false also should make this config fairly safe to use against an existing target if you just run it on your machine without heeding my previous warning. Don't change these unless you are absolutely sure you know what you are doing. You can also add options to be added directly to the rsync calls. You can sync multiple directories to multiple targets with multiple options. There are exclude options which you may find useful. It is far too much to cover here so read the docs, but the simple config above is all I need for my purposes.

Once the service is configured you can control it with systemctl like any other systemd service. By default it will be disabled so you will need to enable it to run automatically after suitable testing. You can check the logs for startup or running errors with journalctl. If syncs are working correctly you can watch them as uploads are logged very shortly after the events are saved to local disk;

<nowiki>[root@nvr system]# tail -50 /var/log/lsyncd.log
/1/2025-12-11/8707/8707-video.mp4
/1/2025-12-11/8707/snapshot.jpg
/1/2025-12-11/8707/alarm.jpg
/6/2025-12-11/8708/
/6/2025-12-11/
/6/
/6/2025-12-11/8708/8708-video.mp4
/6/2025-12-11/8708/snapshot.jpg
/6/2025-12-11/8708/alarm.jpg
/8/2025-12-11/8706/8706-video.mp4
/8/2025-12-11/8706/
/8/2025-12-11/
/8/
Thu Dec 11 14:30:25 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:31:50 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8709/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8709/8709-video.mp4
/2/2025-12-11/8709/snapshot.jpg
/2/2025-12-11/8709/alarm.jpg
Thu Dec 11 14:32:00 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:32:04 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8710/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8710/8710-video.mp4
/2/2025-12-11/8710/snapshot.jpg
/2/2025-12-11/8710/alarm.jpg
Thu Dec 11 14:32:11 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:32:45 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8711/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8711/8711-video.mp4
/2/2025-12-11/8711/snapshot.jpg
/2/2025-12-11/8711/alarm.jpg
Thu Dec 11 14:32:51 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:37:36 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/3/2025-12-11/8712/
/3/2025-12-11/
/3/
/
/3/2025-12-11/8712/8712-video.mp4
/3/2025-12-11/8712/snapshot.jpg
/3/2025-12-11/8712/alarm.jpg
Thu Dec 11 14:37:41 2025 Normal: Finished a list after exitcode: 0
[root@nvr system]#</nowiki>

I'm happy to have offsite copies of all my events now. While they are not tracked in the Zoneminder database, they are still saved in folders by monitor id and date for easy retrieval should the ZM database become unavailable. Props to the ZM devs for their great software, and I hope this writeup proves useful to some other users in the future.

Realtime event backup to cloud storage

2025-12-12T16:28:27Z

Kernelkurtz:

After recently migrating from another popular NVR software on Windows to Zoneminder on Linux I started looking for a way to do near-real-time backups of my events to offsite storage, simply as a way to have a copy should the local ZM server be compromised by break-in, fire, etc. Software such as Dropbox, Google Drive, etc. make it relatively easy to do this on Windows but the setup on Linux takes bit more effort.

I wanted to keep it as simple as possible and don't need my backup solution to interface with the ZM database at all. After experimenting with several other options, I have settled on an application called lsyncd. It runs as a service and leverages inotify and rsync to watch a directory or directories and mirror only new changes to another storage location. Lsyncd should be available as a package for most Linux distributions. I used the installation instructions here for my Rocky Linux system;

https://docs.rockylinux.org/10/guides/backup/mirroring_lsyncd/

At this point it is worthwhile to at least skim through the docs.

https://lsyncd.github.io/lsyncd/manual/config/file/

https://linux.die.net/man/1/rsync

Both lsyncd and rsync are highly configurable and incredibly powerful. For many people the use case will be very simple like my own which I will describe here - watch my Zoneminder storage location and copy new files to a remote location, but much more complex configurations are certainly possible. In my case I'll be writing to an Amazon S3 bucket which I have already setup using S3FS-FUSE according to the documentation here;

https://zoneminder.readthedocs.io/en/latest/userguide/options/options_storage.html

Note you do not need to add the S3FS as a storage location in ZM to use lsyncd to copy files there, that is only required for ZM to write events directly to S3. Configuring rsync is beyond the scope of this document but this solution will work with any target that rsync is capable of writing to. Make sure your remote location is accessible via rsync before proceeding.

Once lsyncd is installed you will need to create a configuration file in /etc/lsyncd.conf. I've included mine as an example below. Note this script uses LUA syntax, not bash. Be VERY CAREFUL if you are testing remote write/sync/copy operations to a destination that already has important data on it. I highly recommend initial testing with an empty bucket or target filesystem. You have been warned.

<nowiki>settings {

logfile = "/var/log/lsyncd.log",

statusFile = "/var/log/lsyncd-status.log",

statusInterval = 10,

maxProcesses = 1,

insist = true,

}

sync {

default.rsync,

source = "/home/Cameras",

target = "/media/aws",

delete = false,

delay = 10,

init = false,

rsync = {

archive = true,

compress = false

}

}</nowiki>

''logfile = '' is pretty self-explanatory. Be sure to set up log rotation after you are done setting lsyncd up, if required.

''maxProcesses = 1'' is the default. If you are syncing multiple sources or targets you may want to increase this.

''insist = true'' allows the service to start even if the target is not ready. I got errors without this which went away when I added it. YMMV.

''source = ''The directory where ZM events are stored.

''target = ''The location to copy events to. Must be accessible via rsync. In my case it is the mount point for the S3FS configured previously.

''targetdir = "/somedirectory''(not shown, part of sync block) subdirectory to use on the target. I'm just using the root directory in a dedicated bucket. You may not want this and should specify something here.

''delay = ''this is how often to run rsync if it is not triggered by any filesystem changes. Default is 15 seconds. For many users this will be close enough to real-time for the purpose. This can be combined with (or substituted) for another value in the settings field;

''maxDelay = # '' (not shown, part of settings block) will queue this # of file changes before calling rsync. Between delay and/or maxDelay it is possible to tune the timing of your file copies to your exact preference. inotify waits for write_close to add files to the transfer list so there are no issues with rsync trying to upload uncompleted files. I typically only record short 10 second clips. If you use your cameras to continuously record be aware that files in the process of being written will not be copied until they are closed.

''archive = true ''This preserves permissions on the copied files.

Two other very important variables in this file are;

''delete = false'' this is pretty self explanatory, file deletes will not be synced from source to target. In the case of my S3 bucket I have lifecycle rules that handle this. If you prefer for your remote storage location to synchronize the deletions made by Zoneminder you can set this to true. This also means if you accidentally delete events from your local storage they will be deleted from the cloud as well. Use with caution.

''init = false'' causes the lsyncd to not do a complete initial synchronization between source and target on service startup. On S3 this is expensive in terms of API calls and may take a while. I know I'm going to miss some events during system maintenance/OS updates etc anyway so I don't consider this worth the cost, but you can set to true if you want it. Be warned it will make your target an exact mirror of your source.

Having delete and init set to false also should make this config fairly safe to use against an existing target if you just run it on your machine without heeding my previous warning. Don't change these unless you are absolutely sure you know what you are doing. You can also add options to be added directly to the rsync calls. You can sync multiple directories to multiple targets with multiple options. There are exclude options which you may find useful. It is far too much to cover here so read the docs, but the simple config above is all I need for my purposes.

Once the service is configured you can control it with systemctl like any other systemd service. By default it will be disabled so you will need to enable it to run automatically after suitable testing. You can check the logs for startup or running errors with journalctl. If syncs are working correctly you can watch them as uploads are logged very shortly after the events are saved to local disk;

<nowiki>[root@nvr system]# tail -50 /var/log/lsyncd.log
/1/2025-12-11/8707/8707-video.mp4
/1/2025-12-11/8707/snapshot.jpg
/1/2025-12-11/8707/alarm.jpg
/6/2025-12-11/8708/
/6/2025-12-11/
/6/
/6/2025-12-11/8708/8708-video.mp4
/6/2025-12-11/8708/snapshot.jpg
/6/2025-12-11/8708/alarm.jpg
/8/2025-12-11/8706/8706-video.mp4
/8/2025-12-11/8706/
/8/2025-12-11/
/8/
Thu Dec 11 14:30:25 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:31:50 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8709/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8709/8709-video.mp4
/2/2025-12-11/8709/snapshot.jpg
/2/2025-12-11/8709/alarm.jpg
Thu Dec 11 14:32:00 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:32:04 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8710/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8710/8710-video.mp4
/2/2025-12-11/8710/snapshot.jpg
/2/2025-12-11/8710/alarm.jpg
Thu Dec 11 14:32:11 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:32:45 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8711/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8711/8711-video.mp4
/2/2025-12-11/8711/snapshot.jpg
/2/2025-12-11/8711/alarm.jpg
Thu Dec 11 14:32:51 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:37:36 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/3/2025-12-11/8712/
/3/2025-12-11/
/3/
/
/3/2025-12-11/8712/8712-video.mp4
/3/2025-12-11/8712/snapshot.jpg
/3/2025-12-11/8712/alarm.jpg
Thu Dec 11 14:37:41 2025 Normal: Finished a list after exitcode: 0
[root@nvr system]#</nowiki>

I'm happy to have offsite copies of all my events now. While they are not tracked in the Zoneminder database, they are still saved in folders by monitor id and date for easy retrieval should the ZM database become unavailable. Props to the ZM devs for their great software, and I hope this writeup proves useful to some other users in the future.

Realtime event backup to cloud storage

2025-12-12T16:20:57Z

Kernelkurtz: Small corrections

After recently migrating from another popular NVR software on Windows to Zoneminder on Linux I started looking for a way to do near-real-time backups of my events to offsite storage, simply as a way to have a copy should the local ZM server be compromised by break-in, fire, etc. Software such as Dropbox, Google Drive, etc. make it relatively easy to do this on Windows but the setup on Linux takes bit more effort.

I wanted to keep it as simple as possible and don't need my backup solution to interface with the ZM database at all. After experimenting with several other options, I have settled on an application called lsyncd. It runs as a service and leverages inotify and rsync to watch a directory or directories and mirror only new changes to another storage location. Lsyncd should be available as a package for most Linux distributions. I used the installation instructions here for my Rocky Linux system;

https://docs.rockylinux.org/10/guides/backup/mirroring_lsyncd/

At this point it is worthwhile to at least skim through the docs.

https://lsyncd.github.io/lsyncd/manual/config/file/

https://linux.die.net/man/1/rsync

Both lsyncd and rsync are highly configurable and incredibly powerful. For many people the use case will be very simple like my own which I will describe here - watch my Zoneminder storage location and copy new files to a remote location, but much more complex configurations are certainly possible. In my case I'll be writing to an Amazon S3 bucket which I have already setup using S3FS-FUSE according to the documentation here;

https://zoneminder.readthedocs.io/en/latest/userguide/options/options_storage.html

Note you do not need to add the S3FS as a storage location in ZM to use lsyncd to copy files there, that is only required for ZM to write events directly to S3. Configuring rsync is beyond the scope of this document but this solution will work with any target that rsync is capable of writing to. Make sure your remote location is accessible via rsync before proceeding.

Once lsyncd is installed you will need to create a configuration file in /etc/lsyncd.conf. I've included mine as an example below. Note this script uses LUA syntax, not bash. Be VERY CAREFUL if you are testing remote write/sync/copy operations to a destination that already has important data on it. I highly recommend initial testing with an empty bucket or target filesystem. You have been warned.

<nowiki>settings {

logfile = "/var/log/lsyncd.log",

statusFile = "/var/log/lsyncd-status.log",

statusInterval = 10,

maxProcesses = 1,

insist = true,

}

sync {

default.rsync,

source = "/home/Cameras",

target = "/media/aws",

delete = false,

delay = 10,

init = false,

rsync = {

archive = true,

compress = false

}

}</nowiki>

Logging is pretty self-explanatory. Be sure to set up log rotation after you are done setting lsyncd up, if required.

''maxProcesses = 1'' is the default. If you are syncing multiple sources or targets you may want to increase this.

''insist = true'' allows the service to start even if the target is not ready. I got errors without this which went away when I added it. YMMV.

''source = ''The directory where ZM events are stored.

''target = ''The location to copy events to. Must be accessible via rsync. In my case it is the mount point for the S3FS configured previously.

''targetdir = "/somedirectory''(not shown, part of sync block) subdirectory to use on the target. I'm just using the root directory in a dedicated bucket. You may not want this and should specify something here.

''delay = ''this is how often to run rsync if it is not triggered by any filesystem changes. Default is 15 seconds. For many users this will be close enough to real-time for the purpose. This can be combined with (or substituted) for another value in the settings field;

''maxDelay = # '' (not shown, part of settings block) will queue this # of file changes before calling rsync. Between delay and/or maxDelay it is possible to tune the timing of your file copies to your exact preference. inotify waits for write_close to add files to the transfer list so there are no issues with rsync trying to upload uncompleted files. I typically only record short 10 second clips. If you use your cameras to continuously record be aware that files in the process of being written will not be copied until they are closed.

''archive = true ''This preserves permissions on the copied files.

Two other very important variables in this file are;

''delete = false'' this is pretty self explanatory, file deletes will not be synced from source to target. In the case of my S3 bucket I have lifecycle rules that handle this. If you prefer for your remote storage location to synchronize the deletions made by Zoneminder you can set this to true. This also means if you accidentally delete events from your local storage they will be deleted from the cloud as well. Use with caution.

''init = false'' causes the lsyncd to not do a complete initial synchronization between source and target on service startup. On S3 this is expensive in terms of API calls and may take a while. I know I'm going to miss some events during system maintenance/OS updates etc anyway so I don't consider this worth the cost, but you can set to true if you want it. Be warned it will make your target an exact mirror of your source.

Having delete and init set to false also should make this config fairly safe to use against an existing target if you just run it on your machine without heeding my previous warning. Don't change these unless you are absolutely sure you know what you are doing. You can also add options to be added directly to the rsync calls. You can sync multiple directories to multiple targets with multiple options. There are exclude options which you may find useful. It is far too much to cover here so read the docs, but the simple config above is all I need for my purposes.

Once the service is configured you can control it with systemctl like any other systemd service. By default it will be disabled so you will need to enable it to run automatically after suitable testing. You can check the logs for startup or running errors with journalctl. If syncs are working correctly you can watch them as uploads are logged very shortly after the events are saved to local disk;

<nowiki>[root@nvr system]# tail -50 /var/log/lsyncd.log
/1/2025-12-11/8707/8707-video.mp4
/1/2025-12-11/8707/snapshot.jpg
/1/2025-12-11/8707/alarm.jpg
/6/2025-12-11/8708/
/6/2025-12-11/
/6/
/6/2025-12-11/8708/8708-video.mp4
/6/2025-12-11/8708/snapshot.jpg
/6/2025-12-11/8708/alarm.jpg
/8/2025-12-11/8706/8706-video.mp4
/8/2025-12-11/8706/
/8/2025-12-11/
/8/
Thu Dec 11 14:30:25 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:31:50 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8709/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8709/8709-video.mp4
/2/2025-12-11/8709/snapshot.jpg
/2/2025-12-11/8709/alarm.jpg
Thu Dec 11 14:32:00 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:32:04 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8710/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8710/8710-video.mp4
/2/2025-12-11/8710/snapshot.jpg
/2/2025-12-11/8710/alarm.jpg
Thu Dec 11 14:32:11 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:32:45 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8711/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8711/8711-video.mp4
/2/2025-12-11/8711/snapshot.jpg
/2/2025-12-11/8711/alarm.jpg
Thu Dec 11 14:32:51 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:37:36 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/3/2025-12-11/8712/
/3/2025-12-11/
/3/
/
/3/2025-12-11/8712/8712-video.mp4
/3/2025-12-11/8712/snapshot.jpg
/3/2025-12-11/8712/alarm.jpg
Thu Dec 11 14:37:41 2025 Normal: Finished a list after exitcode: 0
[root@nvr system]#</nowiki>

I'm happy to have offsite copies of all my events now. While they are not tracked in the Zoneminder database, they are still saved in folders by monitor id and date for easy retrieval should the ZM database become unavailable. Props to the ZM devs for their great software, and I hope this writeup proves useful to some other users in the future.

Realtime event backup to cloud storage

2025-12-12T03:07:38Z

Kernelkurtz:

After recently migrating from another popular NVR software on Windows to Zoneminder on Linux I started looking for a way to do near-real-time backups of my events to offsite storage, simply as a way to have a copy should the local ZM server be compromised by break-in, fire, etc. Software such as Dropbox, Google Drive, etc. make it relatively easy to do this on Windows but the setup on Linux takes bit more effort.

I wanted to keep it as simple as possible and don't need my backup solution to interface with the ZM database at all. After experimenting with several other options, I have settled on an application called lsyncd. It runs as a service and leverages inotify and rsync to watch a directory or directories and mirror only new changes to another storage location. Lsyncd should be available as a package for most Linux distributions. I used the instructions here for my Rocky Linux system;

https://docs.rockylinux.org/10/guides/backup/mirroring_lsyncd/

At this point it is worthwhile to at least skim through the docs.

https://lsyncd.github.io/lsyncd/manual/config/file/

https://linux.die.net/man/1/rsync

Both lsyncd and rsync are highly configurable and incredibly powerful. For many people the use case will be very simple like my own which I will describe here - watch a single event directory and copy new files to a remote location, but much more complex configurations are certainly possible. In my case I'll be writing to an Amazon S3 bucket which I have already setup using S3FS-FUSE according to the documentation here;

https://zoneminder.readthedocs.io/en/latest/userguide/options/options_storage.html

Note you do not need to add the S3FS as a storage location in ZM to use lsyncd to copy files there, that is only required for ZM to write events directly to S3. Configuring rsync is beyond the scope of this document but this solution will work with any target that rsync is capable of writing to. Make sure your remote location is accessible via rsync before proceeding.

Once lsyncd is installed you will need to create a configuration file in /etc/lsyncd.conf. I've included mine as an example below. Note this script uses LUA syntax, not bash. Be VERY CAREFUL if you are testing remote write/sync/copy operations to a destination that already has important data on it. I suggest initial testing with an empty bucket or target filesystem. You have been warned.

<nowiki>settings {

logfile = "/var/log/lsyncd.log",

statusFile = "/var/log/lsyncd-status.log",

statusInterval = 10,

maxProcesses = 1,

insist = true,

}

sync {

default.rsync,

source = "/home/Cameras",

target = "/media/aws",

delete = false,

delay = 10,

init = false,

rsync = {

archive = true,

compress = false

}

}</nowiki>

Logging is pretty self-explanatory. Be sure to set up log rotation after you are done setting lsyncd up, if required.

''maxProcesses = 1'' is the default. If you are syncing multiple sources or targets you may want to increase this.

''insist = true'' allows the service to start even if the target is not ready. I got errors without this which went away when I added it. YMMV.

''source = ''The directory where ZM events are stored.

''target = ''The location to copy events to. Must be accessible via rsync. In my case it is the mount point for the S3FS configured previously.

''targetdir = ''(not shown, part of sync block) subdirectory to use on the target. I'm just using the root directory in a dedicated bucket. You may not want this and should specify something here.

''delay - ''this is how often to run rsync if it is not triggered by any filesystem changes. Default is 15 seconds. For many users this will be close enough to real-time for the purpose. This can be combined with (or substituted) for another value in the settings field;

''maxDelay - # '' (not shown, part of settings block) will queue this # of file changes before calling rsync. Between delay and/or maxDelay it is possible to tune the timing of your file copies to your exact preference. inotify waits for write_close to add files to the transfer list so there are no issues with rsync trying to upload uncompleted files. I typically only record short 10 second clips. If you use your cameras to continuously record be aware that files in the process of being written will not be copied until they are closed.

Two other very important variables in this file are;

''delete = false'' this is pretty self explanatory, file deletes will not be synced from source to target. In the case of my S3 bucket I have lifecycle rules that handle this. If you prefer for your remote storage location to synchronize the deletions made by Zoneminder you can set this to true.

''init = false'' causes the lsyncd to not do a complete initial synchronization between source and target on service startup. On S3 this is expensive in terms of API calls and may take a while. I know I'm going to miss some events during system maintenance/OS updates etc anyway so I don't consider this worth the cost, but you can set to true if you want it. Be warned it will make your target an exact mirror of your source.

Having delete and init set to false also should make this config fairly safe to run against an existing target if you just blindly copy it to your machine without heeding my previous warning. Don't change these unless you are absolutely sure you know what you are doing. You can also add options to be added directly to the rsync calls. You can sync multiple directories to multiple targets with multiple options. There are exclude options which you may find useful. It is far too much to cover here so read the docs, but at this point you should get the idea.

Once the service is configured you can control it with systemctl like any other systemd service. By default it will be disabled so you will need to enable it to run automatically after suitable testing. You can check the logs for startup or running errors with journalctl. If syncs are working correctly you can watch them as uploads are logged very shortly after the events are saved to local disk;

<nowiki>[root@nvr system]# tail -50 /var/log/lsyncd.log
/1/2025-12-11/8707/8707-video.mp4
/1/2025-12-11/8707/snapshot.jpg
/1/2025-12-11/8707/alarm.jpg
/6/2025-12-11/8708/
/6/2025-12-11/
/6/
/6/2025-12-11/8708/8708-video.mp4
/6/2025-12-11/8708/snapshot.jpg
/6/2025-12-11/8708/alarm.jpg
/8/2025-12-11/8706/8706-video.mp4
/8/2025-12-11/8706/
/8/2025-12-11/
/8/
Thu Dec 11 14:30:25 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:31:50 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8709/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8709/8709-video.mp4
/2/2025-12-11/8709/snapshot.jpg
/2/2025-12-11/8709/alarm.jpg
Thu Dec 11 14:32:00 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:32:04 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8710/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8710/8710-video.mp4
/2/2025-12-11/8710/snapshot.jpg
/2/2025-12-11/8710/alarm.jpg
Thu Dec 11 14:32:11 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:32:45 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8711/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8711/8711-video.mp4
/2/2025-12-11/8711/snapshot.jpg
/2/2025-12-11/8711/alarm.jpg
Thu Dec 11 14:32:51 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:37:36 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/3/2025-12-11/8712/
/3/2025-12-11/
/3/
/
/3/2025-12-11/8712/8712-video.mp4
/3/2025-12-11/8712/snapshot.jpg
/3/2025-12-11/8712/alarm.jpg
Thu Dec 11 14:37:41 2025 Normal: Finished a list after exitcode: 0
[root@nvr system]#</nowiki>

I'm happy to have offsite copies of all my events now. While they are not tracked in the Zoneminder database, they are still saved in folders by monitor # and date for easy retrieval should the ZM database become unavailable. Props to the ZM devs for their great software, and I hope this writeup proves useful to some other users in the future.

Realtime event backup to cloud storage

2025-12-12T02:58:26Z

Kernelkurtz:

After recently migrating from another popular NVR software on Windows to Zoneminder on Linux I started looking for a way to do near-real-time backups of my events to offsite storage, simply as a way to have a copy should the local ZM server be compromised by break-in, fire, etc. Software such as Dropbox, Google Drive, etc. make it relatively easy to do this on Windows but the setup on Linux takes bit more effort.

I wanted to keep it as simple as possible and don't need my backup solution to interface with the ZM database at all. After experimenting with several other options, I have settled on an application called lsyncd. It runs as a service and leverages inotify and rsync to watch a directory or directories and mirror only new changes to another storage location. Lsyncd should be available as a package for most Linux distributions. I used the instructions here for my Rocky Linux system;

https://docs.rockylinux.org/10/guides/backup/mirroring_lsyncd/

At this point it is worthwhile to at least skim through the docs.

https://lsyncd.github.io/lsyncd/manual/config/file/

https://linux.die.net/man/1/rsync

Both lsyncd and rsync are highly configurable and incredibly powerful. For many people the use case will be very simple like my own which I will describe here - watch a single event directory and copy new files to a remote location, but much more complex configurations are certainly possible. In my case I'll be writing to an Amazon S3 bucket which I have already setup using S3FS-FUSE according to the documentation here;

https://zoneminder.readthedocs.io/en/latest/userguide/options/options_storage.html

Note you do not need to add the S3FS as a storage location in ZM to use lsyncd to copy files there, that is only required for ZM to write events directly to S3. Configuring rsync is beyond the scope of this document but this solution will work with any target that rsync is capable of writing to. Make sure your remote location is accessible via rsync before proceeding.

Once lsyncd is installed you will need to create a configuration file in /etc/lsyncd.conf. I've included mine as an example below. Note this script uses LUA syntax, not bash. Be VERY CAREFUL if you are testing remote write/sync/copy operations to a destination that already has important data on it. I suggest initial testing with an empty bucket or target filesystem. You have been warned.

<nowiki>settings {

logfile = "/var/log/lsyncd.log",

statusFile = "/var/log/lsyncd-status.log",

statusInterval = 10,

maxProcesses = 1,

insist = true,

}

sync {

default.rsync,

source = "/home/Cameras",

target = "/media/aws",

delete = false,

delay = 10,

init = false,

rsync = {

archive = true,

compress = false

}

}</nowiki>

Logging is pretty self-explanatory. Be sure to set up log rotation after you are done setting lsyncd up, if required.

''maxProcesses = 1'' is the default. If you are syncing multiple sources or targets you may want to increase this.

''insist = true'' allows the service to start even if the target is not ready. I got errors without this which went away when I added it. YMMV.

''source = ''The directory where ZM events are stored.

''target = ''The location to copy events to. Must be accessible via rsync. In my case it is the mount point for the S3FS configured previously.

''targetdir = ''(not shown, part of sync block) subdirectory to use on the target. I'm just using the root directory in a dedicated bucket. You may not want this and should specify something here.

''delay - ''this is how often to run rsync if it is not triggered by any filesystem changes. Default is 15 seconds. For many users this will be close enough to real-time for the purpose. This can be combined with (or substituted) for another value in the settings field;

''maxDelay - # '' (not shown, part of settings block) will queue this # of file changes before calling rsync. Between delay and/or maxDelay it is possible to tune the timing of your file copies to your exact preference. inotify waits for write_close to add files to the transfer list so there are no issues with rsync trying to upload uncompleted files. I typically only record short 10 second clips. If you use your cameras to continuously record be aware that files in the process of being written will not be copied until they are closed.

Two other very important variables in this file are;

''delete = false'' this is pretty self explanatory, file deletes will not be synced from source to target. In the case of my S3 bucket I have lifecycle rules that handle this. If you prefer for your remote storage location to synchronize the deletions made by Zoneminder you can set this to true.

''init = false'' causes the lsyncd to not do a complete initial synchronization between source and target on service startup. On S3 this is expensive in terms of API calls and may take a while. I know I'm going to miss some events during system maintenance/OS updates etc anyway so I don't consider this worth the cost, but you can set to true if you want it.

Having delete and init set to false also should make this config fairly safe to run against an existing target if you just blindly copy it to your machine without heeding my previous warning. Don't change these unless you are absolutely sure you know what you are doing. You can also add options to be added directly to the rsync calls. You can sync multiple directories to multiple targets with multiple options. There are exclude options which you may find useful. It is far too much to cover here so read the docs, but at this point you should get the idea.

Once the service is configured you can control it with systemctl like any other systemd service. By default it will be disabled so you will need to enable it to run automatically after suitable testing. You can check the logs for startup or running errors with journalctl. If syncs are working correctly you can watch them as uploads are logged very shortly after the events are saved to local disk;

<nowiki>[root@nvr system]# tail -50 /var/log/lsyncd.log
/1/2025-12-11/8707/8707-video.mp4
/1/2025-12-11/8707/snapshot.jpg
/1/2025-12-11/8707/alarm.jpg
/6/2025-12-11/8708/
/6/2025-12-11/
/6/
/6/2025-12-11/8708/8708-video.mp4
/6/2025-12-11/8708/snapshot.jpg
/6/2025-12-11/8708/alarm.jpg
/8/2025-12-11/8706/8706-video.mp4
/8/2025-12-11/8706/
/8/2025-12-11/
/8/
Thu Dec 11 14:30:25 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:31:50 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8709/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8709/8709-video.mp4
/2/2025-12-11/8709/snapshot.jpg
/2/2025-12-11/8709/alarm.jpg
Thu Dec 11 14:32:00 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:32:04 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8710/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8710/8710-video.mp4
/2/2025-12-11/8710/snapshot.jpg
/2/2025-12-11/8710/alarm.jpg
Thu Dec 11 14:32:11 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:32:45 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8711/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8711/8711-video.mp4
/2/2025-12-11/8711/snapshot.jpg
/2/2025-12-11/8711/alarm.jpg
Thu Dec 11 14:32:51 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:37:36 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/3/2025-12-11/8712/
/3/2025-12-11/
/3/
/
/3/2025-12-11/8712/8712-video.mp4
/3/2025-12-11/8712/snapshot.jpg
/3/2025-12-11/8712/alarm.jpg
Thu Dec 11 14:37:41 2025 Normal: Finished a list after exitcode: 0
[root@nvr system]#</nowiki>

I'm happy to have offsite copies of all my events now. While they are not tracked in the Zoneminder database, they are still saved in folders by monitor # and date for easy retrieval should the ZM database become unavailable. Props to the ZM devs for their great software, and I hope this writeup proves useful to some other users in the future.

Realtime event backup to cloud storage

2025-12-12T02:55:10Z

Kernelkurtz:

After recently migrating from another popular NVR software on Windows to Zoneminder on Linux I started looking for a way to do near-real-time backups of my events to offsite storage, simply as a way to have a copy should the local ZM server be compromised by break-in, fire, etc. Software such as Dropbox, Google Drive, etc. make it relatively easy to do this on Windows but the setup on Linux takes bit more effort.

I wanted to keep it as simple as possible and don't need my backup solution to interface with the ZM database at all. After experimenting with several other options, I have settled on an application called lsyncd. It runs as a service and leverages inotify and rsync to watch a directory or directories and mirror only new changes to another storage location. Lsyncd should be available as a package for most Linux distributions. I used the instructions here for my Rocky Linux system;

https://docs.rockylinux.org/10/guides/backup/mirroring_lsyncd/

At this point it is worthwhile to at least skim through the docs.

https://lsyncd.github.io/lsyncd/manual/config/file/

https://linux.die.net/man/1/rsync

Both lsyncd and rsync are highly configurable and incredibly powerful. For many people the use case will be very simple like my own which I will describe here - watch a single event directory and copy new files to a remote location, but much more complex configurations are certainly possible. In my case I'll be writing to an Amazon S3 bucket which I have already setup using S3fs-FUSE according to the documentation here;

https://zoneminder.readthedocs.io/en/latest/userguide/options/options_storage.html

Note you do not need to add the S3FS as a storage location in ZM to use lsyncd to copy files there, that is only required for ZM to write events directly to S3. Configuring rsync is beyond the scope of this document but this solution will work with any target that rsync is capable of writing to. Be sure to have your remote location configured and accessible via rsync before proceeding.

Once lsyncd is installed you will need to create a configuration file in /etc/lsyncd.conf. I've included mine as an example below. Note this script uses LUA syntax, not bash. Be VERY CAREFUL if you are testing remote write/sync/copy operations to a destination that already has important data on it. I suggest initial testing with an empty bucket or target filesystem. You have been warned.

<nowiki>settings {

logfile = "/var/log/lsyncd.log",

statusFile = "/var/log/lsyncd-status.log",

statusInterval = 10,

maxProcesses = 1,

insist = true,

}

sync {

default.rsync,

source = "/home/Cameras",

target = "/media/aws",

delete = false,

delay = 10,

init = false,

rsync = {

archive = true,

compress = false

}

}</nowiki>

Logging is pretty self-explanatory. Be sure to set up log rotation after you are done setting lsyncd up, if required.

''maxProcesses = 1'' is the default. If you are syncing multiple sources or targets you may want to increase this.

''insist = true'' allows the service to start even if the target is not ready. I got errors without this which went away when I added it. YMMV.

''source = ''The directory where ZM events are stored.

''target = ''The location to copy events to. Must be accessible via rsync. In my case it is the mount point for the S3FS configured previously.

''targetdir = ''(not shown, part of sync block) subdirectory to use on the target. I'm just using the root directory in a dedicated bucket. You may not want this and should specify something here.

''delay - ''this is how often to run rsync if it is not triggered by any filesystem changes. Default is 15 seconds. For many users this will be close enough to real-time for the purpose. This can be combined with (or substituted) for another value in the settings field;

''maxDelay - # '' (not shown, part of settings block) will queue this # of file changes before calling rsync. Between delay and/or maxDelay it is possible to tune the timing of your file copies to your exact preference. inotify waits for write_close to add files to the transfer list so there are no issues with rsync trying to upload uncompleted files. I typically only record short 10 second clips. If you use your cameras to continuously record be aware that files in the process of being written will not be copied until they are closed.

Two other very important variables in this file are;

''delete = false'' this is pretty self explanatory, file deletes will not be synced from source to target. In the case of my S3 bucket I have lifecycle rules that handle this. If you prefer for your remote storage location to synchronize the deletions made by Zoneminder you can set this to true.

''init = false'' causes the lsyncd to not do a complete initial synchronization between source and target on service startup. On S3 this is expensive in terms of API calls and may take a while. I know I'm going to miss some events during system maintenance/OS updates etc anyway so I don't consider this worth the cost, but you can set to true if you want it.

Having delete and init set to false also should make this config fairly safe to run against an existing target if you just blindly copy it to your machine without heeding my previous warning. Don't change these unless you are absolutely sure you know what you are doing. You can also add options to be added directly to the rsync calls. You can sync multiple directories to multiple targets with multiple options. There are exclude options which you may find useful. It is far too much to cover here so read the docs, but at this point you should get the idea.

Once the service is configured you can control it with systemctl like any other systemd service. By default it will be disabled so you will need to enable it to run automatically after suitable testing. You can check the logs for startup or running errors with journalctl. If syncs are working correctly you can watch them as uploads are logged very shortly after the events are saved to local disk;

<nowiki>[root@nvr system]# tail -50 /var/log/lsyncd.log
/1/2025-12-11/8707/8707-video.mp4
/1/2025-12-11/8707/snapshot.jpg
/1/2025-12-11/8707/alarm.jpg
/6/2025-12-11/8708/
/6/2025-12-11/
/6/
/6/2025-12-11/8708/8708-video.mp4
/6/2025-12-11/8708/snapshot.jpg
/6/2025-12-11/8708/alarm.jpg
/8/2025-12-11/8706/8706-video.mp4
/8/2025-12-11/8706/
/8/2025-12-11/
/8/
Thu Dec 11 14:30:25 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:31:50 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8709/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8709/8709-video.mp4
/2/2025-12-11/8709/snapshot.jpg
/2/2025-12-11/8709/alarm.jpg
Thu Dec 11 14:32:00 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:32:04 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8710/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8710/8710-video.mp4
/2/2025-12-11/8710/snapshot.jpg
/2/2025-12-11/8710/alarm.jpg
Thu Dec 11 14:32:11 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:32:45 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8711/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8711/8711-video.mp4
/2/2025-12-11/8711/snapshot.jpg
/2/2025-12-11/8711/alarm.jpg
Thu Dec 11 14:32:51 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:37:36 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/3/2025-12-11/8712/
/3/2025-12-11/
/3/
/
/3/2025-12-11/8712/8712-video.mp4
/3/2025-12-11/8712/snapshot.jpg
/3/2025-12-11/8712/alarm.jpg
Thu Dec 11 14:37:41 2025 Normal: Finished a list after exitcode: 0
[root@nvr system]#</nowiki>

I'm happy to have offsite copies of all my events now. While they are not tracked in the Zoneminder database, they are still saved in folders by monitor # and date for easy retrieval should the ZM database become unavailable. Props to the ZM devs for their great software, and I hope this writeup proves useful to some other users in the future.

Realtime event backup to cloud storage

2025-12-12T00:30:28Z

Kernelkurtz:

After recently migrating from another popular NVR software on Windows to Zoneminder on Linux I started looking for a way to do near-real-time backups of my events to offsite storage, simply as a way to have a copy should the local ZM server be compromised by break-in, fire, etc. Software such as Dropbox, Google Drive, etc. make it relatively easy to do this on Windows but the setup on Linux takes bit more effort.

I wanted to keep it as simple as possible and don't need my backup solution to interface with the ZM database at all. After experimenting with several other options, I have settled on an application called lsyncd. It runs as a service and leverages inotify and rsync to watch a directory or directories and mirror only new changes to another storage location. Lsyncd should be available as a package for most Linux distributions. I used the instructions here for my Rocky Linux system;

https://docs.rockylinux.org/10/guides/backup/mirroring_lsyncd/

At this point it is worthwhile to at least skim through the docs.

https://lsyncd.github.io/lsyncd/manual/config/file/

https://linux.die.net/man/1/rsync

Both lsyncd and rsync are highly configurable and incredibly powerful. For many people the use case will be very simple like my own which I will describe here - watch a single event directory and copy new files to a remote location, but much more complex configurations are certainly possible. In my case I'll be writing to an Amazon S3 bucket which I have already setup using S3fs-FUSE according to the documentation here;

https://zoneminder.readthedocs.io/en/latest/userguide/options/options_storage.html

Note you do not need to add the S3FS as a storage location in ZM to use lsyncd to copy files there, that is only required for ZM to write events directly to S3. Configuring rsync is beyond the scope of this document but this solution will work with any target that rsync is capable of writing to. Be sure to have your remote location configured and accessible via rsync before proceeding.

Once lsyncd is installed you will need to create a configuration file in /etc/lsyncd.conf. I've included mine as an example below. Note this script uses LUA syntax, not bash. Be VERY CAREFUL if you are testing remote write/sync/copy operations to a destination that already has important data on it. I suggest initial testing with an empty bucket or target filesystem. You have been warned.

<nowiki>settings {

logfile = "/var/log/lsyncd.log",

statusFile = "/var/log/lsyncd-status.log",

statusInterval = 10,

maxProcesses = 1,

insist = true,

}

sync {

default.rsync,

source = "/home/Cameras",

target = "/media/aws",

delete = false,

delay = 10,

init = false,

rsync = {

archive = true,

compress = false

}

}</nowiki>

Logging is pretty self-explanatory. Be sure to set up log rotation after you are done setting lsyncd up, if required.

''maxProcesses = 1'' is the default. If you are syncing multiple sources or targets you may want to increase this.

''insist = true'' allows the service to start even if the target is not ready. I got errors without this which went away when I added it. YMMV.

''source = ''The directory where ZM events are stored.

''target = ''The location to copy events to. Must be accessible via rsync.

''targetdir = ''(not shown) subdirectory to use on the target. I'm just using the root directory in a dedicated bucket. You may not want this and should specify something here.

''delay - ''this is how often to run rsync if it is not triggered by any filesystem changes. Default is 15 seconds. For many users this will be close enough to real-time for the purpose. This can be combined with (or substituted) for another value in the settings field;

''maxDelay - # '' (not shown) will queue this # of file changes before calling rsync. Between delay and/or maxDelay it is possible to tune the timing of your file copies to your exact preference. inotify waits for write_close to add files to the transfer list so there are no issues with rsync trying to upload uncompleted files. I typically only record short 10 second clips. If you use your cameras to continuously record be aware that files in the process of being written will not be copied until they are closed.

Two other very important variables in this file are;

''delete = false'' this is pretty self explanatory, file deletes will not be synced from source to target. In the case of my S3 bucket I have lifecycle rules that handle this. If you prefer for your remote storage location to synchronize the deletions made by Zoneminder you can set this to true.

''init = false'' causes the lsyncd to not do a complete initial synchronization between source and target on service startup. On S3 this is expensive in terms of API calls and may take a while. I know I'm going to miss some events during system maintenance/OS updates etc anyway so I don't consider this worth the cost, but you can set to true if you want it.

Having delete and init set to false also should make this config fairly safe to run against an existing target if you just blindly copy it to your machine without heeding my previous warning. You can also add options to be added directly to the rsync calls. You can sync multiple directories to multiple targets with multiple options. There are exclude options which you may find useful. It is far too much to cover here so read the docs, but at this point you should get the idea.

Once the service is configured you can control it with systemctl like any other systemd service. You can check the logs for startup or running errors with journalctl. If syncs are working correctly you can watch them as uploads are logged very shortly after the events are saved to local disk;

<nowiki>[root@nvr system]# tail -50 /var/log/lsyncd.log
/1/2025-12-11/8707/8707-video.mp4
/1/2025-12-11/8707/snapshot.jpg
/1/2025-12-11/8707/alarm.jpg
/6/2025-12-11/8708/
/6/2025-12-11/
/6/
/6/2025-12-11/8708/8708-video.mp4
/6/2025-12-11/8708/snapshot.jpg
/6/2025-12-11/8708/alarm.jpg
/8/2025-12-11/8706/8706-video.mp4
/8/2025-12-11/8706/
/8/2025-12-11/
/8/
Thu Dec 11 14:30:25 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:31:50 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8709/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8709/8709-video.mp4
/2/2025-12-11/8709/snapshot.jpg
/2/2025-12-11/8709/alarm.jpg
Thu Dec 11 14:32:00 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:32:04 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8710/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8710/8710-video.mp4
/2/2025-12-11/8710/snapshot.jpg
/2/2025-12-11/8710/alarm.jpg
Thu Dec 11 14:32:11 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:32:45 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8711/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8711/8711-video.mp4
/2/2025-12-11/8711/snapshot.jpg
/2/2025-12-11/8711/alarm.jpg
Thu Dec 11 14:32:51 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:37:36 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/3/2025-12-11/8712/
/3/2025-12-11/
/3/
/
/3/2025-12-11/8712/8712-video.mp4
/3/2025-12-11/8712/snapshot.jpg
/3/2025-12-11/8712/alarm.jpg
Thu Dec 11 14:37:41 2025 Normal: Finished a list after exitcode: 0
[root@nvr system]#</nowiki>

I'm happy to have offsite copies of all my events now. While they are not tracked in the Zoneminder database, they are still saved in folders by monitor # and date for easy retrieval should the ZM database become unavailable. Props to the ZM devs for their great software, and I hope this writeup proves useful to some other users in the future.

Realtime event backup to cloud storage

2025-12-12T00:20:49Z

Kernelkurtz:

After recently migrating from another popular NVR software on Windows to Zoneminder on Linux I started looking for a way to do near-real-time backups of my events to offsite storage, simply as a way to have a copy should the local ZM server be compromised by break-in, fire, etc. Software such as Dropbox, Google Drive, etc. make it relatively easy to do this on Windows but the setup on Linux takes bit more effort.

I wanted to keep it as simple as possible and don't need my backup solution to interface with the ZM database at all. After experimenting with several other options, I have settled on an application called lsyncd. It runs as a service and leverages inotify and rsync to watch a directory or directories and mirror only new changes to another storage location. Lsyncd should be available as a package for most Linux distributions. I used the instructions here for my Rocky Linux system;

https://docs.rockylinux.org/10/guides/backup/mirroring_lsyncd/

At this point it is worthwhile to at least skim through the docs.

https://lsyncd.github.io/lsyncd/manual/config/file/

https://linux.die.net/man/1/rsync

Both lsyncd and rsync are highly configurable and incredibly powerful. For many people the use case will be very simple like my own which I will describe here - watch a single event directory and copy new files to a remote location, but much more complex configurations are certainly possible. In my case I'll be writing to an Amazon S3 bucket which I have already setup using S3fs-FUSE according to the documentation here;

https://zoneminder.readthedocs.io/en/latest/userguide/options/options_storage.html

Note you do not need to add the S3FS as a storage location in ZM to use lsyncd to copy files there, that is only required for ZM to write events directly to S3. Configuring rsync is beyond the scope of this document but this solution will work with any target that rsync is capable of writing to. Be sure to have your remote location configured and accessible via rsync before proceeding.

Once lsyncd is installed you will need to create a configuration file in /etc/lsyncd.conf. I've included mine as an example below. Note this script uses LUA syntax, not bash. Be VERY CAREFUL if you are testing remote write/sync/copy operations to a destination that already has important data on it. I suggest initial testing with an empty bucket or target filesystem. You have been warned.

<nowiki>settings {

logfile = "/var/log/lsyncd.log",

statusFile = "/var/log/lsyncd-status.log",

statusInterval = 10,

maxProcesses = 1,

insist = true,

}

sync {

default.rsync,

source = "/home/Cameras",

target = "/media/aws",

delete = false,

delay = 10,

init = false,

rsync = {

archive = true,

compress = false

}

}</nowiki>

Logging is pretty self-explanatory. Be sure to set up log rotation after you are done setting lsyncd up, if required.

maxProcesses = 1 is the default. If you are syncing multiple sources or targets you may want to increase this.

insist = true allows the service to start even if the target is not ready. I got errors without this which went away when I added it. YMMV.

source = The directory where ZM events are stored.

target = The location to copy events to. Must be accessible via rsync.

targetdir = (not shown) subdirectory to use on the target. I'm just using the root directory in a dedicated bucket. You may not want this and should specify something here.

delay - this is how often to run rsync if it is not triggered by any filesystem changes. Default is 15 seconds. For many users this will be close enough to real-time for the purpose. This can be combined with (or substituted) for another value in the settings field;

maxDelay - # (not shown) will queue this # of file changes before calling rsync. Between delay and/or maxDelay it is possible to tune the timing of your file copies to your exact preference. inotify waits for write_close to add files to the transfer list so there are no issues with rsync trying to upload uncompleted files. I typically only record short 10 second clips. If you use your cameras to continuously record be aware that files in the process of being written will not be copied until they are closed.

Two other very important variables in this file are;

delete = false this is pretty self explanatory, file deletes will not be synced from source to target. In the case of my S3 bucket I have lifecycle rules that handle this. If you prefer for your remote storage location to synchronize the deletions made by Zoneminder you can set this to true.

init = false causes the lsyncd to not do a complete initial synchronization between source and target on service startup. On S3 this is expensive in terms of API calls and may take a while. I know I'm going to miss some events during system maintenance/OS updates etc anyway so I don't consider this worth the cost, but you can set to true if you want it.

Having delete and init set to false also should make this config fairly safe to run against an existing target if you just blindly copy it to your machine without heeding my previous warning. You can also add options to be added directly to the rsync calls. You can sync multiple directories to multiple targets with multiple options. There are exclude options which you may find useful. It is far too much to cover here so read the docs, but at this point you should get the idea.

Once the service is configured you can control it with systemctl like any other systemd service. You can check the logs for startup or running errors with journalctl. If syncs are working correctly you can watch them as uploads are logged very shortly after the events are saved to local disk;

<nowiki>[root@nvr system]# tail -50 /var/log/lsyncd.log
/1/2025-12-11/8707/8707-video.mp4
/1/2025-12-11/8707/snapshot.jpg
/1/2025-12-11/8707/alarm.jpg
/6/2025-12-11/8708/
/6/2025-12-11/
/6/
/6/2025-12-11/8708/8708-video.mp4
/6/2025-12-11/8708/snapshot.jpg
/6/2025-12-11/8708/alarm.jpg
/8/2025-12-11/8706/8706-video.mp4
/8/2025-12-11/8706/
/8/2025-12-11/
/8/
Thu Dec 11 14:30:25 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:31:50 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8709/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8709/8709-video.mp4
/2/2025-12-11/8709/snapshot.jpg
/2/2025-12-11/8709/alarm.jpg
Thu Dec 11 14:32:00 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:32:04 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8710/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8710/8710-video.mp4
/2/2025-12-11/8710/snapshot.jpg
/2/2025-12-11/8710/alarm.jpg
Thu Dec 11 14:32:11 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:32:45 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8711/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8711/8711-video.mp4
/2/2025-12-11/8711/snapshot.jpg
/2/2025-12-11/8711/alarm.jpg
Thu Dec 11 14:32:51 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:37:36 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/3/2025-12-11/8712/
/3/2025-12-11/
/3/
/
/3/2025-12-11/8712/8712-video.mp4
/3/2025-12-11/8712/snapshot.jpg
/3/2025-12-11/8712/alarm.jpg
Thu Dec 11 14:37:41 2025 Normal: Finished a list after exitcode: 0
[root@nvr system]#</nowiki>

I'm happy to have offsite copies of all my events now. While they are not tracked in the Zoneminder database, they are still saved in folders by monitor # and date for easy retrieval should the ZM database become unavailable. Props to the ZM devs for their great software, and I hope this writeup proves useful to some other users in the future.

Realtime event backup to cloud storage

2025-12-12T00:12:33Z

Kernelkurtz: Configuring lsyncd for realtime backups.

After recently migrating from another popular NVR software on Windows to Zoneminder on Linux I started looking for a way to do near-real-time backups of my events to offsite storage, simply as a way to have a copy should the local ZM server be compromised by break-in, fire, etc. Software such as Dropbox, Google Drive, etc. make it relatively easy to do this on Windows but the setup on Linux takes bit more effort.

I wanted to keep it as simple as possible and don't need my backup solution to interface with the ZM database at all. After experimenting with several other options, I have settled on an application called lsyncd. It runs as a service and leverages inotify and rsync to watch a directory or directories and mirror only new changes to another storage location. Lsyncd should be available as a package for most Linux distributions. I used the instructions here for my Rocky Linux system;

https://docs.rockylinux.org/10/guides/backup/mirroring_lsyncd/

At this point it is worthwhile to at least skim through the docs.

https://lsyncd.github.io/lsyncd/manual/config/file/

https://linux.die.net/man/1/rsync

Both lsyncd and rsync are highly configurable and incredibly powerful. For many people the use case will be very simple like my own which I will describe here - watch a single event directory and copy new files to a remote location, but much more complex configurations are certainly possible. In my case I'll be writing to an Amazon S3 bucket which I have already setup using S3fs-FUSE according to the documentation here;

https://zoneminder.readthedocs.io/en/latest/userguide/options/options_storage.html

Note you do not need to add the S3FS as a storage location in ZM to use lsyncd to copy files there, that is only required for ZM to write events directly to S3. Configuring rsync is beyond the scope of this document but this solution will work with any target that rsync is capable of writing to. Be sure to have your remote location configured and accessible via rsync before proceeding.

Once lsyncd is installed you will need to create a configuration file in /etc/lsyncd.conf. I've included mine as an example below. Note this script uses LUA syntax, not bash. Be VERY CAREFUL if you are testing remote write/sync/copy operations to a destination that already has important data on it. I suggest initial testing with an empty bucket or target filesystem. You have been warned.

settings {

logfile = "/var/log/lsyncd.log",

statusFile = "/var/log/lsyncd-status.log",

statusInterval = 10,

maxProcesses = 1,

insist = true,

}

sync {

default.rsync,

source = "/home/Cameras",

target = "/media/aws",

delete = false,

delay = 10,

init = false,

rsync = {

archive = true,

compress = false

}

}

Logging is pretty self-explanatory. Be sure to set up log rotation after you are done setting lsyncd up, if required.

maxProcesses = 1 is the default. If you are syncing multiple sources or targets you may want to increase this.

insist = true allows the service to start even if the target is not ready. I got errors without this which went away when I added it. YMMV.

source = The directory where ZM events are stored.

target = The location to copy events to. Must be accessible via rsync.

targetdir = (not shown) subdirectory to use on the target. I'm just using the root directory in a dedicated bucket. You may not want this and should specify something here.

delay - this is how often to run rsync if it is not triggered by any filesystem changes. Default is 15 seconds. For many users this will be close enough to real-time for the purpose. This can be combined with (or substituted) for another value in the settings field;

maxDelay - # (not shown) will queue this # of file changes before calling rsync. Between delay and/or maxDelay it is possible to tune the timing of your file copies to your exact preference. inotify waits for write_close to add files to the transfer list so there are no issues with rsync trying to upload uncompleted files. I typically only record short 10 second clips. If you use your cameras to continuously record be aware that files in the process of being written will not be copied until they are closed.

Two other very important variables in this file are;

delete = false this is pretty self explanatory, file deletes will not be synced from source to target. In the case of my S3 bucket I have lifecycle rules that handle this. If you prefer for your remote storage location to synchronize the deletions made by Zoneminder you can set this to true.

init = false causes the lsyncd to not do a complete initial synchronization between source and target on service startup. On S3 this is expensive in terms of API calls and may take a while. I know I'm going to miss some events during system maintenance/OS updates etc anyway so I don't consider this worth the cost, but you can set to true if you want it.

Having delete and init set to false also should make this config fairly safe to run against an existing target if you just blindly copy it to your machine without heeding my previous warning. You can also add options to be added directly to the rsync calls. You can sync multiple directories to multiple targets with multiple options. There are exclude options which you may find useful. It is far too much to cover here so read the docs, but at this point you should get the idea.

Once the service is configured you can control it with systemctl like any other systemd service. You can check the logs for startup or running errors with journalctl. If syncs are working correctly you can watch them as uploads are logged very shortly after the events are saved to local disk;

[root@nvr system]# tail -50 /var/log/lsyncd.log
/1/2025-12-11/8707/8707-video.mp4
/1/2025-12-11/8707/snapshot.jpg
/1/2025-12-11/8707/alarm.jpg
/6/2025-12-11/8708/
/6/2025-12-11/
/6/
/6/2025-12-11/8708/8708-video.mp4
/6/2025-12-11/8708/snapshot.jpg
/6/2025-12-11/8708/alarm.jpg
/8/2025-12-11/8706/8706-video.mp4
/8/2025-12-11/8706/
/8/2025-12-11/
/8/
Thu Dec 11 14:30:25 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:31:50 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8709/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8709/8709-video.mp4
/2/2025-12-11/8709/snapshot.jpg
/2/2025-12-11/8709/alarm.jpg
Thu Dec 11 14:32:00 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:32:04 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8710/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8710/8710-video.mp4
/2/2025-12-11/8710/snapshot.jpg
/2/2025-12-11/8710/alarm.jpg
Thu Dec 11 14:32:11 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:32:45 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/2/2025-12-11/8711/
/2/2025-12-11/
/2/
/
/2/2025-12-11/8711/8711-video.mp4
/2/2025-12-11/8711/snapshot.jpg
/2/2025-12-11/8711/alarm.jpg
Thu Dec 11 14:32:51 2025 Normal: Finished a list after exitcode: 0
Thu Dec 11 14:37:36 2025 Normal: Calling rsync with filter-list of new/modified files/dirs
/3/2025-12-11/8712/
/3/2025-12-11/
/3/
/
/3/2025-12-11/8712/8712-video.mp4
/3/2025-12-11/8712/snapshot.jpg
/3/2025-12-11/8712/alarm.jpg
Thu Dec 11 14:37:41 2025 Normal: Finished a list after exitcode: 0
[root@nvr system]#

I'm happy to have offsite copies of all my events now. While they are not tracked in the Zoneminder database, they are still saved in folders by monitor # and date for easy retrieval should the ZM database become unavailable. Props to the ZM devs for their great software, and I hope this writeup proves useful to some other users in the future.

Helpful user contributed resources

2025-12-12T00:04:56Z

Kernelkurtz: /* Community docs */

==FAQ==

[[FAQ]]

==Installation==

[http://zoneminder.readthedocs.org/en/latest/installationguide/index.html Official install guides ]

[https://wiki.zoneminder.com/Ubuntu Ubuntu specific guides (currently more updated than official guides)]

[https://wiki.zoneminder.com/Debian Debian specific guides]

[https://wiki.zoneminder.com/Ubuntu#Common_Issues_with_Zoneminder_Installation_on_Ubuntu._Includes_upgrade_instructions.21 Common problems migrating from old versions to new versions ]

[https://github.com/pliablepixels/zmNinja/wiki/Configuring-ZoneMinder-with-API API installation/validation guide]- (use the link above first, if you face problems, refer to this link)

[https://wiki.zoneminder.com/Using_a_dedicated_Hard_Drive Using a dedicated Hard Drive] - Adding HDDs.

[[Single Board Computers]] - ARM devices.

[[GPU passthrough in VMWare]] - Notes on using GPUs with Zoneminder running in a virtual machine

[[Email]]

==Supported==

[[Beginner hardware]] - What cameras to start with.

[[Supported distributions]]

[[Hardware Compatibility List ]]

[[MobileDevices]] - View ZM from your phone.

==Third party==

[[Utilities]] - Software for ZM

[[Infrared Leds, Cameras, DC-DC converters etc]] - Hardware

[[External resources of information related to ZM]]

[[Consultants]]

==Community docs==

[[How To]]

[[Miscellaneous helpful hints]]

[[Various Learnings from getting Zomeminder 1.28.1 working well on Ubuntu Server 14.04]]

[[Dummies Guide]]

[[MySQL]]

[[Hardware recommendations]] - What computer hardware to use.

[[Realtime event backup to cloud storage]]

==CCTV Laws==
[[Area Specific Laws]]