Network Storage

Use surveillance-grade disks, or at least NAS-class disks rated for 24/7 operation. Desktop disks are commonly specified for about 2,400 power-on hours per year (24/7 operation is 8,760 hours) and a workload of around 55 TB/year, while surveillance disks are designed for continuous operation and typically rated at 180 TB/year, with higher-end surveillance and AI models often rated at up to about 550 TB/year. Surveillance firmware is optimized for many simultaneous write streams, typically up to 64 HD cameras per disk, and keeps the stream flowing instead of retrying a weak sector for a long time, which helps prevent dropped frames; many larger models also have vibration sensors for multi-bay chassis. A desktop disk may work at first, but under 24/7 recording it usually develops gaps, errors and a shorter life.

The workload rating is the amount of data the manufacturer expects the disk to read plus write per year while still meeting its reliability specification; typical values are 55 TB/year for desktop disks and 180 TB/year for surveillance disks. One megabit per second of continuous traffic equals about 3.94 TB per year, so a 180 TB/year disk corresponds to roughly 45 Mbps of round-the-clock traffic, including playback and backup reads. Example: 16 cameras at 4 Mbps recorded on a single disk means 64 Mbps, or about 252 TB/year, which exceeds a 180 TB/year rating; spreading the recording over two disks (about 126 TB/year each) or choosing a higher-rated model solves this. Exceeding the rating does not stop the disk immediately, but it increases the probability of failure.

CMR (conventional magnetic recording) writes tracks side by side, while SMR (shingled magnetic recording) partly overlaps them to increase density; changing data on an SMR disk means rewriting neighbouring tracks, so sustained or scattered writes slow down sharply once its internal cache is full. In a single-disk recorder with mostly sequential writes the difference can be small, but in RAID arrays SMR disks can make rebuilds extremely slow and may even be dropped from the array. For multi-disk recorders and RAID, choose CMR disks and check the recording technology in the manufacturer's datasheet before buying.

For recording, rotational speed matters much less than firmware and workload rating. Even a 5400 rpm-class surveillance disk sustains well over 50 MB/s (400 Mbps) of sequential writing across the whole disk, far more than a typical NVR writes: 32 cameras at 4 Mbps are only 128 Mbps, or 16 MB/s. 7200 rpm disks help in large RAID arrays, in faster rebuilds and under heavy simultaneous playback and search, at the cost of more heat, power and noise. In a small NVR, a cooler 5400 rpm-class surveillance disk is a perfectly good choice.

It is not recommended for recordings that may serve as evidence, because the remaining life of a used disk is unknown and 24/7 recording is a demanding workload. If you must use one, check its SMART data first: power-on hours (attribute 9) show its age, and any reallocated (attribute 5) or pending (attribute 197) sectors are a reason to reject it; then run a full (long) self-test before installation. Buy only from a trusted seller, since the SMART counters of resold disks are not always reliable.

MTBF is a statistical figure for a large population of disks, not the life of a single disk: 1,000,000 hours corresponds to an annualized failure rate (AFR) of roughly 0.9 percent, that is, about 9 failures per 1,000 disks per year when they are operated within the rated workload and temperature. It says nothing about wear-out as the disk ages. As a practical guideline, plan to replace disks after about 4 to 5 years of continuous service, and replace sooner any disk whose SMART counters for reallocated or pending sectors keep rising.

Disk manufacturers use decimal units (1 TB = 10^12 bytes), while most recorders and operating systems calculate in binary units (1 TiB = 2^40 bytes, about 1,099.5 billion bytes) but still label the result TB. So an 8 TB disk, which holds 8,000 billion bytes, appears as about 7.28 TB; a 4 TB disk appears as about 3.64 TB and a 16 TB disk as about 14.55 TB. The file system and the recorder's index take a little more space, so a figure slightly below these values is normal and does not mean the disk is faulty.

An NVR is a dedicated recorder that receives the camera streams, records them on its own internal hard disks and provides live view and playback in the same box; it is the simplest choice for small and medium projects. A NAS is essentially network storage and does not record by itself unless VMS software is installed on it; normally an NVR or VMS software writes to it. A VMS server is a standard server running video management software, with storage inside the server or on external NAS and SAN arrays, and it scales to hundreds of cameras, several recording servers and enterprise RAID. In practice an NVR (available on the market in models from 4 up to 128 channels) is the usual choice for a single site with a few dozen cameras, while a VMS server is chosen when you need more channels, central management of several sites or higher redundancy.

A SAN provides block-level storage: the storage array presents a volume (LUN) to the recording server, which formats it and uses it like a local disk. iSCSI carries this block traffic over ordinary Ethernet (by default on TCP port 3260), so it costs less than Fibre Channel, and because the operating system sees it as a local disk, practically any VMS server, as well as some NVRs under the name IP SAN, can use it. It is used when several recording servers need central, RAID-protected storage, each with its own LUN, or when capacity must grow beyond what fits inside the servers. Standard practice is a dedicated storage network or VLAN, 10 GbE links for large systems, and sustained link load kept below about 70 percent.

Yes, many NVRs and most VMS platforms can record to a NAS, either through a network share (NFS or SMB/CIFS) or as an iSCSI volume; for continuous recording iSCSI is usually preferred, because the recorder manages the volume directly without file-sharing overhead. The NAS must sustain the combined bitrate of all cameras around the clock, which requires 24/7-rated disks, a redundant RAID level and enough network capacity. Keep the NAS on the same local network as the recorder, never behind a slow WAN link, and check in the recorder's datasheet whether network storage can be used for main recording or only for backup.

The usual options are: replace the disks with larger ones, up to the maximum capacity per disk stated in the datasheet (footage on removed disks is no longer available for playback, so export what you need first); use an eSATA port if the NVR supports recording to it; add network storage (NAS or IP SAN) if the NVR supports it; or split the cameras between two recorders. A USB hard disk is meant for export and backup, not for 24/7 recording, because enclosure power saving and USB disconnects can cause recording gaps. For large systems it is usually more economical to move to a recording server with an external RAID array than to keep adding small NVRs.

Yes. Put the operating system, the VMS software and its database on a separate volume, ideally two SSDs in RAID 1, and keep video on a separate HDD array, for example RAID 6 or RAID 10. Continuous video writing on the system disk slows down the operating system and the database, and if the video volume fills up or fails, the server must still boot and keep managing the cameras. This separation also lets you expand, rebuild or replace the video array without reinstalling the system.

With N identical disks: RAID 0 (striping) uses the full capacity of all disks but has no redundancy, so one failed disk loses the whole array; RAID 1 (mirroring, usually 2 disks) gives the capacity of one disk and survives one failure; RAID 5 (single parity, at least 3 disks) gives the capacity of N−1 disks and survives one failure; RAID 6 (dual parity, at least 4 disks) gives N−2 disks and survives any two failures; RAID 10 (striped mirrors, at least 4 disks, even number) gives half the total capacity, always survives one failure, and survives more if the failed disks are in different mirror pairs. Example with 8 disks of 8 TB: RAID 0 = 64 TB, RAID 5 = 56 TB, RAID 6 = 48 TB, RAID 10 = 32 TB. The capacity shown by the recorder is somewhat lower because of TB/TiB units and file-system overhead.

With 2 disks, use RAID 1. RAID 5 is acceptable only for small arrays, typically 3 to 5 disks of up to about 4 TB each, preferably with a hot spare or a spare disk on site; with more or larger disks, RAID 6 is the standard choice for surveillance because it survives two failures, including a second failure during a rebuild. RAID 10 costs half of the raw capacity but offers the best write performance and the fastest, lowest-risk rebuild, since only the mirror partner is copied, so it suits systems with heavy recording plus frequent playback and search. RAID 0 should never be used for footage that may become evidence.

When one disk in a RAID 5 array fails, the array has no redundancy until the rebuild finishes, and the rebuild must read every sector of all the remaining disks. Rebuilding one large disk takes many hours even on an idle array: at about 200 MB/s an 8 TB disk needs at least 11 hours and a 16 TB disk about 22 hours, and with cameras recording at the same time it usually takes considerably longer. During this window a second disk failure, or an unreadable sector on a surviving disk, can abort the rebuild or cause data loss; datasheets specify a worst-case unrecoverable read error rate, typically one per 10^14 bits read (about 12.5 TB) for desktop-class disks and one per 10^15 bits for enterprise-class disks. Disks bought together also tend to age together, which is why RAID 6 or RAID 10 is preferred for large arrays.

A hot spare is an extra disk installed in the recorder or storage array that stays idle until a member disk fails; the controller then starts rebuilding onto it automatically, without waiting for someone to reach the site. This shortens the period in which the array runs without redundancy, which matters most for RAID 5 and for unattended or remote sites. A global hot spare can serve any array in the device while a dedicated one serves a single array, and its capacity must be at least equal to that of the disks it replaces. As a rule of thumb, add a hot spare to arrays of about 8 disks or more, or wherever a failed disk cannot be replaced within a day.

It usually works technically, but the array treats every member as if it had the size of the smallest disk and runs at the pace of the slowest, so the extra capacity is wasted. Mixing CMR and SMR disks, or surveillance and desktop disks, can make rebuilds very slow and cause disks to drop out of the array. Best practice is the same model and capacity for all members; a replacement disk must be at least as large as the failed one, and the same model is the safest choice.

For small systems with one or two disks, yes, and it is the most common setup. Without RAID each disk is an independent volume; depending on the model and its disk-group settings, an NVR fills the disks one after another or assigns cameras to particular disks, so if a disk fails only the footage on that disk is lost and recording continues on the others. The downside is that the footage on a failed disk cannot be recovered, so for sites where every hour counts, such as banks, cash desks and sensitive areas, use RAID, redundant recording or N+1. In either case, enable the disk-error alarm so a failure is noticed immediately.

Yes. RAID only protects against the physical failure of a disk; it does not protect against accidental deletion, overwriting, failure of the controller or the recorder, fire, theft, water damage or malware, because every copy is in the same box. Important footage should be exported as soon as it is identified and kept on separate media, following the 3-2-1 rule: three copies, on two different types of media, one of them off-site. For critical sites, add redundancy at the recorder level as well, such as N+1 failover or recording at a second location.

Yes, as long as you initialize (format) only the new disk: in the NVR's storage menu select just the new disk and leave the others untouched, because formatting erases a disk's recordings. Shut the NVR down properly before installing the disk unless it has hot-swap bays. Adding a disk to an existing RAID array requires online capacity expansion or RAID level migration, which only some devices support and which can take many hours or even days on large arrays, so export important footage first. Afterwards, confirm that the new disk shows a normal status and is included in the recording disk group.

Hot-swap means removing and inserting disks while the device is powered on, and it is safe only if the recorder or storage array explicitly supports it, typically with front-loading drive trays and a backplane. On such devices you can replace a failed RAID member while recording continues: identify the failed bay by its LED or by the bay number in the storage menu, remove the disk and insert the new one, and the rebuild starts automatically or from the menu. On NVRs whose disks are mounted inside the case with cables, always shut down properly and disconnect power before touching the disks. Pulling a healthy disk by mistake from a RAID 5 array that already has a failed disk can take the whole array offline and cause data loss, so double-check the bay number.

SMART (Self-Monitoring, Analysis and Reporting Technology) is the disk's built-in health log, which recorders and servers can read and raise alerts from. The most telling attributes are 5 (Reallocated Sectors Count), 187 (Reported Uncorrectable Errors), 188 (Command Timeout), 197 (Current Pending Sector Count) and 198 (Offline Uncorrectable); a non-zero value that keeps rising is a strong reason to replace the disk. Attribute 199 (UDMA CRC Error Count) usually points to a faulty SATA cable, backplane or connector rather than the disk itself. Also watch the temperature (attribute 194), and run a long self-test on every new disk and whenever errors appear.

First export any important footage that is still readable from that disk, then check its SMART data: if reallocated or pending sectors are present or increasing, replace the disk. If SMART is clean, power down, reseat or replace the SATA data and power cables, and check the power supply, because weak power and loose cables cause many false disk errors. If the status is uninitialized, the disk is new or not recognized and must be initialized in the NVR, which erases it. Finally, configure exception alarms (HDD error, HDD full, no disk) to send e-mail or push notifications so the next problem is noticed immediately.

If the disk is not detected, check the SATA data and power cables and make sure its capacity does not exceed the maximum per-disk capacity in the NVR datasheet; older firmware may not support newer large disks, so update it from the official source. If the disk is detected but shows as uninitialized, initialize it from the storage menu. If it shows a normal status but nothing is recorded, check each camera's recording schedule, the disk group or quota assignment and the disk's properties, such as a read-only setting if the NVR has one. Finally, confirm by playing back a few minutes from every camera.

Datasheets typically allow a maximum of about 60 to 70 °C, but for a long life keep disks well below that, ideally around 30 to 45 °C in continuous operation. Install the recorder in a ventilated place or rack with free space around its vents, away from heaters and direct sunlight, and clean dusty fans and filters periodically, because a failed fan quickly overheats the disks. Avoid vibrating surfaces and heavy machinery nearby, and after installation check the disk temperature reported in the SMART data (attribute 194).

Usually not directly: NVRs store video in their own file system or storage format, so Windows typically does not recognize the disk and may offer to initialize or format it; decline, because that would erase the recordings. The reliable method is to export the required clips from the NVR, locally to USB or over the network with the client software, or to use the manufacturer's dedicated disk-reading tool if one exists. A disk can generally be moved only to another recorder of the same family, and even then it is safer to export first.

Continuous recording keeps a complete timeline and is recommended for critical points such as entrances, cash desks and perimeters, but it uses the most storage. Motion or event recording (motion detection, line crossing, intrusion, alarm inputs) stores only periods with activity, so storage use falls roughly in proportion to the share of time with activity: quiet scenes save a lot, busy scenes very little. Many sites combine modes with a schedule, for example continuous recording during working hours and event recording at night, or continuous recording with event markers for faster searching. Event recording is only as good as its detection, so use human and vehicle classification where available to avoid missed events and floods of false clips.

Pre-record keeps a short rolling buffer so that a saved clip starts a few seconds before the trigger and shows how the event began; post-record keeps recording for a while after the event ends. Typical settings are 5 to 10 seconds of pre-record and 10 to 30 seconds of post-record, with longer post-record where people linger, such as cash desks. If a new event occurs within the post-record time, recording simply continues, so the footage is not fragmented into many short clips.

If overwrite is enabled, which is the usual default, the NVR deletes the oldest recordings first and keeps recording, so the disks always hold the most recent period. If overwrite is disabled, recording stops when the disks are full and an HDD full alarm is raised; this makes sense only when someone archives the footage or replaces the disks on a schedule. Locked or protected clips are not overwritten, so too many of them reduce the space available for new recordings.

Use the maximum retention (expiry) setting that many NVRs and VMS platforms offer per camera or globally: recordings older than the set number of days are deleted automatically even if free space remains, which helps meet privacy rules and internal policies. This setting only limits age; to actually guarantee 30 days, the installed capacity must be sized for 30 days at the cameras' real bitrates (see the storage calculation topic). After commissioning, periodically check the oldest available recording of each camera in playback, since real retention often differs from the design because of scene activity, night-time image noise and bitrate changes.

As soon as an incident is identified, lock (protect) the relevant clip in the NVR so that overwriting skips it, and export a copy to separate media without delay. Locking is only a short-term measure: locked files stay on the same disks, remain exposed to disk or recorder failure, and reduce the space for new recordings. Also restrict delete and export permissions to authorized users and keep the operation log enabled, so footage cannot disappear without a trace.

On the storage side, the usual causes are a disk with errors or bad sectors, a disk that cannot keep up (a desktop or SMR disk, or too many streams on one disk), full disks with overwrite disabled, a recording schedule that does not cover that time, and power cuts or reboots. On the network side, the camera stream itself may have dropped, which the NVR logs as video loss; ANR with an SD card in the camera can fill such gaps. Start with the NVR log for that period: HDD error, video loss and reboot entries usually point straight to the cause.

Edge recording means the camera itself records to its microSD card, continuously, on events, or only when its connection to the recorder is lost. It is an excellent backup for network or recorder outages and a practical option for very small installations, but it does not replace an NVR: a typical card holds a few days to about two weeks of main-stream video, far less than an NVR, it can be stolen or damaged together with the camera, and it wears out under continuous writing. Best practice is NVR recording as the primary copy and the SD card as a safety net, combined with ANR when both the camera and the recorder support it.

Use a card sold as high endurance or industrial and intended for continuous video recording; ordinary cards made for phones and cameras wear out quickly under 24/7 writing. Speed is rarely the limit, since Class 10, U1 or V10 already guarantees 10 MB/s of sustained writing, while even a high 8 Mbps camera stream is only 1 MB/s; endurance is what matters. Cards larger than 32 GB are SDXC, so check the maximum card capacity the camera supports in its datasheet, format the card in the camera before use, and check its status periodically in the camera's web interface.

With ANR, when the link between a camera and the NVR is lost, the camera keeps recording to its microSD card; once the link is restored, the NVR automatically downloads the missing period from the card and fills the gap in its own timeline. It requires a camera with an SD card and ANR support, an NVR that supports ANR for that camera, the function enabled on both sides, and correct time synchronization (NTP) on both devices. The backfill uses extra bandwidth on top of the live streams and can take a while after long outages, especially if the link is already heavily loaded. In mixed-brand systems it generally works only if both devices support ONVIF Profile G (edge storage and retrieval) and the NVR implements replenishment over it.

In an N+1 system, N working recorders or recording servers are protected by one standby unit; if a working unit fails or goes offline, the standby automatically takes over recording its cameras. When the failed unit returns, the standby can typically copy the footage it recorded during the outage back to it, so the main timeline is completed. N+1 protects against recorder failure, not against a disk failure inside a working unit, so it is combined with RAID; the recorders or VMS must support the feature, and the standby must be able to reach all protected cameras over the network.

Each layer covers a different failure: RAID 5, 6 or 10 protects against disk failure; N+1 failover or a second recorder protects against recorder failure; recording on the camera's microSD card with ANR covers network or recorder outages; a UPS covers power cuts; and exported copies on separate media protect against deletion, overwriting, theft and fire. Choose the layers according to the value of the footage: a small shop may need only surveillance-grade disks, a UPS and SD cards in the key cameras, while a bank or a city project typically combines all of them.

Export the original recorded stream without re-encoding, in the recorder's native format together with its player if that player can verify the watermark, and optionally an extra MP4 copy for easy viewing. Record the camera name, the exact start and end times, the offset of the recorder's clock from real time, the person who exported and the export date, and calculate a hash (for example SHA-256) of each file so its integrity can be proven later. Never hand over video filmed off the monitor with a phone, and keep the recorder's clock synchronized with NTP, because wrong timestamps weaken the evidence.

A digital watermark is information embedded in the video by the camera or recorder that the manufacturer's player can check; if frames are edited or re-encoded, the verification fails. A hash such as SHA-256 is a fixed-length fingerprint calculated from the exported file; changing even a single bit produces a completely different value, so recording the hash at export time and recalculating it later proves the file is unchanged. A hash can be calculated with standard tools on any computer, for example certutil -hashfile file SHA256 on Windows or sha256sum on Linux.

The most common reason is the H.265 (HEVC) codec, which some computers and default players cannot decode without an additional codec, or a native export format that needs the manufacturer's player. Use a player with built-in H.265 support such as VLC, the player bundled with the export, or export in MP4 format if the recorder offers it. If the video plays but without sound or with a wrong time overlay, check the audio option in the export settings and the recorder's time settings.

Many flash drives are formatted as FAT32, which limits a single file to 4 GB; a one-hour clip at 8 Mbps is about 3.6 GB, so longer or higher-bitrate clips hit the limit unless the recorder splits the files or supports exFAT or NTFS. Check which file systems the NVR supports for USB backup, use a USB 3.0 drive with enough free space, and export long periods in parts or over the network with the client software.

Yes. Sudden power cuts can corrupt the recording index and the file being written, force long disk checks at start-up and shorten disk life, while surges and brownouts damage power supplies and disks. Size the UPS from the real load in watts: the recorder, its disks (a 3.5-inch disk typically draws about 3 to 9 W while running and briefly much more at spin-up), the PoE cameras powered by the NVR or switch, and the network switch, plus about 30 percent margin. Note that VA is not watts: a 1000 VA UPS often delivers only 600 to 900 W, depending on its power factor. Online (double-conversion) or line-interactive models are suitable, runtime depends on battery capacity, and batteries typically need replacing every 3 to 5 years, sooner in hot rooms.

Usually only the last moments before the cut are lost, but at start-up the recorder may need several minutes to check the disks and rebuild its index, and in bad cases the last recording file or the file system is damaged. When power returns, check that every camera is recording again, that the disks show a normal status and that the date and time are correct. If the clock has reset to a default date, the small coin-cell battery on the main board is probably flat; replace it and enable NTP so recordings get correct timestamps.

For bulk 24/7 video, HDDs remain the standard: their cost per TB is much lower, and SSDs have a limited write endurance, specified as TBW (terabytes written). Consumer 1 TB SSDs are typically rated at roughly 200 to 600 TBW, so 16 cameras at 4 Mbps (about 252 TB per year) would use up even a 600 TBW rating in less than two and a half years. SSDs make sense for the operating system and database of a VMS server, for mobile and vehicle recorders exposed to vibration and shock, and as a fast cache tier; if you do record on SSDs, choose high-endurance or enterprise models rated in DWPD (drive writes per day).

A practical routine: every week, play back a short period from each camera and look for gaps; every month, review disk status and SMART values, confirm that the oldest available recording matches the required retention, and verify the recorder's time against NTP; every few months, test that alarm notifications (HDD error, video loss) actually arrive and check the UPS batteries. Install official firmware updates after reading the release notes, keep the ventilation clean, and keep a record of disk serial numbers and installation dates so ageing disks are replaced before they fail.