How to Decide Between Edge Storage and Centralized Recording

How to Decide Between Edge Storage and Centralized Recording

Every video project eventually reaches the same fork: record at the camera, record at a central server or NVR, or some blend of the two. The debate usually gets argued on cost, and that is the wrong axis. The real decision is about failure domains — what footage survives which failure — and about who is going to operate the thing for the next five years. I have seen edge-only designs quietly lose months of coverage to worn-out SD cards nobody was monitoring, and I have seen centralized designs lose the exact clip that mattered because a switch rebooted during the incident. Neither architecture is wrong; each is wrong for specific sites.

Here is the decision process I actually run, step by step.

Step 1: Define the Network Risk Profile

Start by writing down what sits between each camera and the would-be recorder, because every device on that path is a component whose failure erases video in a centralized design. A camera plugged into the same rack as its NVR has a network risk profile near zero. A camera at a remote gate, across a wireless bridge, two switches, and a leased line from the recording server, has a profile that practically demands local storage.

Quantify it from history where you can: pull the last 12 months of network incidents for the site. A LAN that logged two brief switch reboots is a different design input than a site whose WAN drops for hours monthly. And be honest about scheduled risk too — IT departments patch and reboot switches, and each maintenance window on the camera path is a recording gap in a purely centralized design. The rule of thumb I use: if the camera-to-recorder path has more than two active devices, or crosses any link you don't control, that camera is a candidate for edge storage at minimum as a buffer.

While you have the topology drawn, run the bandwidth arithmetic for the centralized case: forty cameras at 4 Mbps is a continuous 160 Mbps of recording traffic, which is trivial on a local gigabit LAN and impossible on a 100 Mbps site uplink. Any camera whose recorded stream would cross a constrained link is either recording locally, recording centrally at a reduced secondary-stream bitrate, or quietly destined to fail — pick one on purpose at design time rather than discovering the third option in production.

Step 2: Local vs Central Retention Targets

Edge and central storage are not interchangeable buckets; they hold different amounts for different purposes. A 256 GB SD card holds roughly 5–7 days of a single 4 Mbps continuous stream (4 Mbps is about 43 GB/day) — more with motion-only recording or a lower-bitrate edge stream. That is buffer-scale, not archive-scale. A central system with a proper drive array is where 30/60/90-day retention lives; surveillance-rated hard drives in the 8–18 TB class make multi-camera, multi-month retention routine.

So the design question is not "edge or central storage" but "what retention does each tier need." Typical pattern: central tier sized for the site's formal retention requirement (30 days is the common commercial floor, some industries want 90+), edge tier sized to cover the site's longest plausible outage plus margin — if the worst realistic WAN outage is 48 hours, a card that buffers 5 days of the recorded stream is comfortable. Write both numbers into the spec. "Has an SD card slot" is not a retention design.

Step 3: ANR and Failover Behavior

The blend only works if the recovery mechanism is real. ANR — automatic network replenishment — is the VMS/camera feature where the camera records to its card during a connection loss and the recorder backfills the gap into the central archive automatically once the link returns, leaving a seamless timeline. When it works, an outage becomes a non-event. The caveats: both ends must support it (camera firmware and the recorder/VMS), it must be licensed and enabled per camera on some platforms, and the backfill consumes bandwidth when the link returns — a 4-hour outage across 40 cameras is a lot of catch-up traffic hitting a link that may still be fragile. Axis cameras paired with ANR-aware VMSes are the long-standing reference implementation of this pattern, and it is a fair screening question for any camera line you are considering: not "does it have edge storage" but "does it replenish automatically, and has anyone here tested it?"

Test it at commissioning the blunt way: unplug the camera's uplink for ten minutes during recorded motion, replug, and verify the timeline over that window is complete at the recorder. If the gap is still there a day later, you have edge storage but not failover — footage exists on the card, and someone will have to notice the gap and manually retrieve it, which in practice means nobody will.

Step 4: SD Card Lifecycle Reality

The dirty secret of edge storage is that SD cards are consumables. Continuous video is close to a worst-case write workload, and consumer cards die in it — sometimes in months. Spec industrial or surveillance-class (high-endurance) cards only; they are rated in total write endurance, and the arithmetic is straightforward: a card rated for, say, hundreds of TB written, receiving ~43 GB/day from a 4 Mbps stream, has a paper life measured in years — a consumer card rated for a fraction of that, doesn't. Worse, cards often fail silently: the camera keeps streaming live video perfectly while writes fail, so the failure is invisible until someone needs the recording. Two mitigations are non-negotiable: enable the camera's card-health monitoring and wear-level reporting where available, alarmed into the VMS — not just logged — and put card replacement on a calendar (proactively at 2–3 years for high-endurance cards under continuous write, sooner for heavy workloads) instead of waiting for failure. Budget it: a fleet of 60 cameras is a fleet of 60 consumable cards plus the labor to swap them, and that recurring line item belongs in the TCO comparison against central storage honestly.

Worked Example: Bank Branch vs Warehouse

Two real profiles that landed on opposite architectures. The bank branch: 14 cameras, all within 300 ft of the comms room, regulated retention (90 days), an IT-managed LAN with UPS, and a compliance requirement that footage be centrally searchable and exportable with audit trails. Decision: centralized recording on an NVR with a RAID array of surveillance drives sized for 90 days at full frame rate, plus high-endurance SD cards in the four cameras covering teller lines and the vault corridor as ANR buffers — not for retention, purely to bridge switch maintenance and the rare LAN event. Edge cards on the other ten cameras were skipped deliberately; the risk profile didn't justify the consumable fleet.

The warehouse: 22 cameras across a yard, three buildings, and a truck gate on a wireless bridge, no regulated retention, a WAN that drops routinely, and no on-site IT. Decision: edge-heavy — every camera carrying a high-endurance card sized to buffer a week, motion-based recording to stretch it, a modest central recorder at the main building for 30-day consolidated retention on the interior cameras, and ANR everywhere the VMS supported it. The truck gate camera, on the flakiest link with the highest evidentiary value, got the largest card and a quarterly manual verification in the service contract. Same decision framework, opposite answers — because the failure domains and the operating reality differed, not the taste of the designer.

Edge Storage Deployment Audit

Whichever way the blend lands, audit the edge tier against this checklist before sign-off:

The two rows that fail most often in the field are health monitoring and the replacement cadence — which together are exactly how sites end up with a third of their edge fleet silently dead.

Step 5: Cybersecurity at the Edge

Distributing storage distributes the attack and theft surface. A centralized archive lives in a lockable room; an edge architecture puts recorded footage inside every housing on every pole, where a pried-open camera can become a walked-away evidence archive. Mitigations: enable SD card encryption where the camera supports it (footage is unreadable off-camera), and treat camera hardening as archive hardening — unique per-device credentials, current firmware, disabled unused services, and 802.1X on the camera ports where the switch infrastructure supports it, because in an edge design the camera is no longer just a sensor; it is a small recording server. Centralized designs concentrate risk instead: the recorder is a single high-value target, so the same energy goes into OS patching, isolated VLANs for the video network, and offsite or immutable copies of critical exports. Neither model is inherently more secure — they need different security work, and the failure I see is applying neither because each camp assumed the architecture itself was the protection.

Step 6: Operations and Replace Cadence

Finally, weight the decision by who operates the system. Centralized recording concentrates the operational work in one place: one drive array to monitor, one box to patch, RAID alarms someone will actually see. Surveillance drives in a busy array should be treated as 4–5 year components with health monitoring watched, and that is a manageable discipline. Edge-heavy designs distribute the maintenance across every camera — card swaps on ladders, per-camera firmware for ANR quirks, and a monitoring burden that only works if the alarms are configured. A site with capable staff or a solid service contract can run either; a site with neither should bias centralized, because a single neglected NVR degrades visibly while sixty neglected SD cards degrade silently. Put the replace cadence for both tiers — drives and cards — in writing in the service agreement, with named responsibility. Architecture without an owner is the real failure mode behind most "storage" failures I get called into.

Where This Fits in a Deployment Program

The edge-versus-central decision sits upstream of most of the bill of materials — it drives camera selection (card slots, ANR support, encryption), recorder and drive sizing, and even the network hardening plan — so run this framework at design review, before hardware is ordered. When you get to sizing, the Video & Storage catalog covers recorders and surveillance-class drives for the central tier, with the hard drive buying guide as a companion for the array math; on the camera side, the Axis catalog is a dependable reference for edge-storage and ANR-capable models, and you can cross-check card support and housings across all Axis products while you finalize the list. If you are weighing the architectures for a specific site — or inheriting a design where nobody can say what happens to footage when the WAN drops — send over the camera count, network topology, and retention requirement, and I'm glad to help you map the failure domains and spec the blend before the first drive ships.