The Archiver is the role that turns cameras into evidence, and it is the role whose storage was sized once, at tender, from a bitrate somebody picked off a datasheet. Three years later there are more cameras, higher resolutions, a retention policy that got extended after an incident, and a system that quietly keeps eleven days of video instead of the thirty the policy says. Nobody notices until the eleventh day is the one that matters.
This is how I size Archiver storage so it still meets the policy after the system has grown, and how I read a storage layout that is about to fail. It picks up where the video drive section of the tuning guide leaves off: that page covers how to configure a volume; this one covers how many you need and what they should be made of.
Retention arithmetic that survives contact with reality
The calculation is simple and everyone does it wrong in the same way.
Storage (TB) = cameras × average bitrate (Mbps) × 3600 × 24 × retention days ÷ 8 ÷ 1,000,000 × overhead
Worked through for 200 cameras at 4 Mbps average with 30 days of retention:
200 × 4 × 86,400 × 30 ÷ 8 ÷ 1,000,000 = 259 TB of video × 1.15 for file system and index overhead = 298 TB
The number that breaks the calculation is the bitrate. The datasheet figure is an average under the vendor’s test scene. A camera facing a car park at night with infrared on and rain falling produces two to three times its daytime average, and it does so for the whole of the winter. A camera on H.264 continuous recording in a busy lobby is not producing the number the calculator was given either. Use one of three sources for the bitrate, in order of preference:
- Measured. Security Center’s statistics tasks report actual archived bitrate per camera. On an existing system, this is the only number worth using.
- Pilot. On a new system, run ten representative cameras for a week and measure.
- Datasheet, multiplied by 1.5 for outdoor and 1.2 for indoor. Then write the assumption down so the next person knows why the number is what it is.
Then add the things the calculator forgets: motion-triggered recording that turns out to be continuous because the scene has a flag in it, the 20 percent of cameras that were added after the tender, and the retention extension the security manager will ask for after the first incident review. Size for the system it will be in year three, not the one on the drawing.
Throughput, per Archiver and per volume
Capacity is the number everyone sizes to. Throughput is the number that decides whether the Archiver can actually write the video it has room for.
Each Archiver has a practical ceiling on the aggregate bitrate it can ingest and write, set by CPU, NIC, and above all disk. Genetec’s enterprise guidance has long put a comfortable working figure around 300 Mbps per Archiver on conventional hardware, with higher figures achievable on well-specified servers and appliances. Treat the vendor’s current number for your release as the ceiling and design to run at two-thirds of it. An Archiver at 90 percent of its ceiling records fine until a firmware update triples the bitrate on a camera family, and then it drops frames on every camera it owns.
Per volume, the constraint is sustained sequential write. A single 7,200 RPM enterprise drive sustains around 150 to 200 MB/s on its own; in a RAID set the array throughput is what matters, and it depends on the level, the controller, and the cache. The Archiver writes many streams concurrently, which the operating system turns into something less than pure sequential I/O. The safe planning figure is that a volume should not be asked to sustain more than half of its benchmarked sequential write rate under Archiver load.
The practical consequence: an Archiver with one large volume is usually throughput-bound before it is capacity-bound. Spread the cameras across volumes, and spread the volumes across controllers where the hardware allows it.
RAID and drive selection
| Option | Where it fits | Where it does not |
|---|---|---|
| RAID 6 | The default for archive volumes. Two-drive fault tolerance, good capacity efficiency, adequate sequential write on a controller with battery-backed or flash-backed cache. | Rebuild times on large drives run to days, during which write performance drops and a third failure loses the volume. |
| RAID 10 | Archivers where throughput matters more than capacity: LPR, high-bitrate cameras, small fast volumes. | Half the raw capacity. Expensive at scale. |
| RAID 5 | Small volumes of small drives, if at all. | Single-drive tolerance on multi-terabyte drives is a rebuild waiting to fail. I do not specify it for video. |
| No RAID | Nowhere in production. | A single drive failure is missing video with no recovery. |
Drives: enterprise or surveillance-class, rated for continuous duty and for the vibration of a chassis full of other drives. Desktop drives fail in archive duty within a year or two, and they fail in groups because they were bought in one batch. Match the drive to the array size; helium-filled high-capacity drives are fine in RAID 6 with a controller that handles the rebuild load, and they are a false economy in RAID 5.
Controller cache with battery or flash backup is not optional. Without it, write-back caching is unsafe and the controller falls back to write-through, and the sequential write figure the array was sized on is now a fraction of itself.
Local, iSCSI, or SMB
Direct-attached storage is the simplest and, per terabyte, usually the cheapest. It is also the one with the fewest moving parts between the Archiver and the disk, which matters when the disk is what makes the video exist.
iSCSI to a SAN or a NAS presenting block storage works well and is the normal pattern for larger deployments. Give it a dedicated network path, jumbo frames end to end, and multipath if the target supports it. The volume appears to Windows as a local disk and the Archiver treats it as one.
SMB shares are supported for archive storage and I avoid them where I can. The path from the Archiver to the file involves the SMB client, the network, and the file server’s own file system, each with its own caching behaviour and its own failure modes, and an SMB share that becomes briefly unavailable produces recording gaps that are hard to attribute. Where SMB is the only option, keep the share on a dedicated file server with nothing else on it, disable SMB signing on that path if policy permits, and monitor it as if it were an Archiver, because functionally it is.
What the Archiver does when the disk is full
The Archiver does not stop when a volume fills. It deletes the oldest video on that volume to make room, subject to the retention settings, and carries on. That is the correct behaviour and it is also why nobody notices that retention has silently dropped from thirty days to eleven: the system keeps recording and the timeline keeps working, it just does not go back as far as the policy says it should.
Two settings govern this. The retention period per camera, which is the upper bound on how long video is kept, and the minimum free space threshold on the volume, below which the Archiver starts deleting. If actual retention is shorter than the configured retention, the volume is undersized for its cameras and the deletion is being driven by free space rather than by policy. That condition should be an alarm, and the Health Monitor can raise one. On most systems I audit, it is not configured to.
Protected video. Video that has been flagged as protected is exempt from automatic deletion. On a site where operators protect footage generously and nobody ever unprotects it, protected video accumulates until it is a meaningful share of the volume and the effective retention for everything else shrinks to match. Review the protected footage list quarterly.
Redundancy: archive transfer and redundant archiving
RAID protects against a drive failing. It does nothing about an Archiver failing, a controller failing, a site burning down, or ransomware encrypting the volume. For any of those you need a second copy somewhere else.
Redundant archiving assigns a second Archiver to record the same cameras at the same time. It doubles ingest, doubles storage, and gives you two independent copies from the moment of recording. It is the right answer where the video is genuinely business-critical or where regulation requires it, and the wrong answer everywhere else because of what it costs.
Archive transfer copies recorded video from one Archiver to another on a schedule, typically the most recent day or the video from specified cameras, to a central or off-site store. It costs a fraction of redundant archiving and it is what most systems should have and do not. Set it up for the cameras whose footage would be requested in an incident, schedule it overnight, and monitor the transfer task the same way you monitor the recording.
Failover archiving is different again: a standby Archiver takes over recording if the primary fails. It protects continuity of recording, not the video already recorded, which stays on the failed Archiver’s disks until it comes back.
The failures, by symptom
| What operators report | What is usually wrong |
|---|---|
| Timeline only goes back eleven days on a thirty-day policy | Volume undersized; free-space deletion outrunning retention. Sometimes protected video hoarding. |
| Recording gaps on many cameras at once, network fine | Volume throughput exceeded. Check disk queue length on the archive volume during the gap. |
| Recording gaps on cameras on one Archiver | That Archiver over its ingest ceiling, or its antivirus exclusions gone. |
| Playback stutters, live is fine | Archiver database fragmentation, or read contention on an array that is rebuilding. |
| Everything fine, then a volume vanishes | RAID rebuild failed, or the iSCSI path dropped. Multipath and controller logs. |
| Video exists but export is slow or fails | Export share on the same volume as the archive. Move it. |
The checklist
- Measured bitrate per camera, not datasheet, and a documented growth assumption.
- Retention arithmetic with the overhead factor, sized for year three.
- Aggregate bitrate per Archiver at two-thirds of the ceiling or less.
- Sustained write per volume at half the benchmarked figure or less; cameras spread across volumes.
- RAID 6 or RAID 10, enterprise drives, controller cache with battery or flash backup.
- Free-space alarm configured in Health Monitor and routed to someone.
- Actual retention compared to configured retention, per camera, quarterly.
- Protected video reviewed and released.
- Archive transfer configured for incident-relevant cameras and monitored.
- Antivirus exclusions on every archive path. The exclusion list is separate because it applies to every platform.
Storage is where a video system either keeps its promises or does not, and it is the part that gets sized once and forgotten. If the last time anyone checked actual retention against the policy was commissioning, that is the first thing to check, and it takes about ten minutes in Security Desk.