Build a CCTV Recording Server Without an NVR — RTSP + ffmpeg + systemd, 180-Day Retention

Home and small-office CCTV storage usually comes down to one of three options: an SD card in the camera, a vendor cloud subscription, or an NVR appliance. Each has a clear ceiling.

But most IP cameras can emit their video over RTSP (Real Time Streaming Protocol), a standard protocol. If a device can receive RTSP, it can be your recorder. And if you already have a Linux server running around the clock, that server is your NVR.

The architecture is simple. The camera sits on a wireless VLAN dedicated to IoT devices, and the recording server connects out to the camera’s RTSP port (554/tcp) to pull the stream. The incoming stream is sliced into 15-minute files and written to the backup disk with no re-encoding.

[CCTV camera]           [recording server]           [disk]
IoT-only VLAN     ←──   ffmpeg pulls RTSP     ──→   15-minute .mkv
554/tcp (RTSP)          -c copy (no re-encode)      auto-deleted after 180 days

The key point is that the camera does not push to the server — the server pulls from the camera. That means no configuration whatsoever has to be added on the camera, and the firewall only needs a single one-way rule: “recording server → camera port 554”. You can block every outbound path from the camera and recording still works perfectly.

Two things had to be handled before recording could start: network isolation and a fixed IP.

① A dedicated IoT VLAN. IoT gear like CCTV cameras and smart plugs tends to get firmware updates on an irregular schedule, and the security track record is often poor. So they go on an IoT-only VLAN, separated from the server and office networks. The goal is simple: if an IoT device is compromised, it must not be able to reach the server network.

② A DHCP reservation.The recording server connects by IP, so if the camera picks up a new address every time it reboots, recording breaks. We reserved an IP against the camera’s MAC address in the router/firewall DHCP settings so it always gets the same address. After that, confirm the camera’s RTSP port is reachable.

nc -vz <camera-ip> 554
# Connection to <camera-ip> 554 port [tcp/rtsp] succeeded!

The RTSP URL format differs by manufacturer. It is usually documented in the camera’s admin UI or manual, in a form likertsp://user:password@camera-ip/stream_ch00_0.

The entire recording script is a single ffmpeg invocation. The RTSP URL containing credentials is never hardcoded into the script — it comes in through an environment variable (kept separately, see the systemd section below).

#!/usr/bin/env bash
set -euo pipefail
: "${RTSP_URL:?missing RTSP_URL}"
: "${OUTPUT_DIR:?missing OUTPUT_DIR}"
SEGMENT_SECONDS="${SEGMENT_SECONDS:-900}"
umask 027
mkdir -p "$OUTPUT_DIR"
exec /usr/bin/ffmpeg \
  -hide_banner \
  -loglevel warning \
  -rtsp_transport tcp \
  -fflags +genpts \
  -use_wallclock_as_timestamps 1 \
  -i "$RTSP_URL" \
  -map 0:v:0 \
  -an \
  -c copy \
  -f segment \
  -segment_time "$SEGMENT_SECONDS" \
  -reset_timestamps 1 \
  -strftime 1 \
  "$OUTPUT_DIR/%Y%m%d_%H%M%S.mkv"

Every one of those flags maps directly to operational stability.

Recording is not a one-shot command — it is a permanent process that must never stop. Registering it as a systemd service instead of running it under nohup or screen is what lets it recover automatically from server reboots, brief network drops, and abnormal process exits.

[Unit]
Description=Record CCTV RTSP stream
Wants=network-online.target
After=network-online.target

[Service]
Type=simple
User=cctv
Group=cctv
EnvironmentFile=/etc/cctv/camera.env
ExecStart=/usr/local/sbin/cctv-record
Restart=always
RestartSec=10
NoNewPrivileges=true
PrivateTmp=true
ProtectSystem=full
ReadWritePaths=/mnt/storage/cctv

[Install]
WantedBy=multi-user.target

What this unit takes care of:

• Credential separation — the URL containing the RTSP username and password lives only in/etc/cctv/camera.env, protected with root-only permissions (0600). No password ends up in the script, the unit file, or git.
• Restart=always + RestartSec=10 — if ffmpeg dies because the camera rebooted or the Wi-Fi dropped, it reconnects automatically 10 seconds later.
• Least privilege — it runs as a dedicated account, and NoNewPrivileges, ProtectSystem, and ReadWritePaths make writing anywhere outside the recording directory impossible. If the recording process is ever compromised, the blast radius is one folder.
• Waiting on network-online.target — prevents ffmpeg from starting before the network is up at boot and failing immediately.

sudo systemctl daemon-reload
sudo systemctl enable --now cctv-record.service

systemctl status cctv-record.service     # active (running)
systemctl show cctv-record -p NRestarts  # check the restart count
ls -lh /mnt/storage/cctv/ | tail         # confirm files keep appearing

We rebooted the server once during production (remotely, via WoL) and recording resumed on its own right after boot. Since then all 96 daily segments have landed without a single gap, and the abnormal ffmpeg restart count (NRestarts) is 0.

Disks are not infinite, so old recordings have to be removed automatically. A single find command is enough for the cleanup script, and we run it every night with a systemd timer rather than cron.

#!/usr/bin/env bash
set -euo pipefail
OUTPUT_DIR=/mnt/storage/cctv
RETENTION_DAYS=180
find "$OUTPUT_DIR" -type f \( -name "*.mkv" -o -name "*.mp4" \) \
  -mtime +"$RETENTION_DAYS" -print -delete
find "$OUTPUT_DIR" -type d -empty -print -delete

[Timer]
OnCalendar=*-*-* 03:20:00
Persistent=true

[Install]
WantedBy=timers.target

Pick the retention window based on your capacity. We started at 30 days, then measured actual usage, saw how much headroom was left, and raised it to 180 days. Here is the math from the real measurements.

Even storing 2K footage as untouched HEVC, six months comes in under 1TB.At current disk prices, a few months of cloud subscription fees buy you years of local storage.

The moment an IP camera is exposed to the internet, it becomes a target. Cameras indexed by search engines and viewable by anyone are still a common occurrence. The real advantage of local recording is not cost — it is that you can take the camera off the internet entirely.

Here is how the firewall rules ended up.

A couple of other things we handled: the RTSP password exists only in the environment file (0600) and is never left in plaintext in any document or repository. And the camera’s default admin password was changed, obviously.

The result is a CCTV recording system with six months of 2K retention, zero additional hardware spend and zero monthly subscription. Several weeks in, segments are recorded with no gaps, and automatic recovery after a server reboot has been confirmed in practice.

For initial server setup, see our Linux server initial setup checklist, and for real-world office bandwidth measurements, see testing office network speed with iperf3.