Disk positions, usable recording capacity and continued service after failure are separate requirements. Ask for the actual storage architecture before approving redundancy.
Section 01
Separate disk management from failure protection
Several disks in an NVR do not establish RAID, a hot spare or unchanged recording after a disk failure. The supplied manual's storage section describes disk information, selected formatting, full-disk behavior and the startup no-disk prompt. Those functions cannot prove a redundancy architecture. Before approving a multi-bay recorder for a failure-survival requirement, identify the exact model and firmware, request its documented storage arrangement and define which recording and retrieval tasks must remain available. Calculate retention against confirmed usable capacity under that arrangement. Keep incident exports separate from continuous-service protection, and compare complete equipment and support scopes only after the required behavior has been established.
Section 4.12.21 is headed External Storage Devices. Read its described actions literally: viewing attached-disk information helps establish media state, while full-disk controls address capacity exhaustion. The heading alone does not establish NAS, NFS, iSCSI, RAID or shared-storage support.
The menu also describes formatting. Any actual formatting requires identification of the selected media, authorization and preservation of required accessible footage first. It is not a way to prove redundancy, and a destructive operation on production media should not be introduced merely to investigate a marketing assumption.
Section 02
Attach architecture claims to the identified recorder
The private source is NVR4.0 user manual CH_V2.4.doc, whose body states V2.2. Sections 1.2 and 5.2 describe a recorder family and model-specific distinctions. Section references take priority over page numbering. A shared interface or family overview cannot establish every function on the proposed unit.
Use the recorder's actual identity and applicable firmware when requesting storage evidence. The manual covers TS models without establishing a mapping to NexPro-Link commercial SKUs. Do not use a TS specification row to fill a missing field in a commercial quotation.
The same discipline applies to a RAID-ready summary. Unless the offered configuration states the applicable architecture and conditions, it does not establish a RAID level, usable capacity, hot-spare behavior or continued operation. Ask for clarification without treating an undocumented field as proof that the feature is absent.
Section 03
Specify what must remain available after failure
Replace an instruction such as 'provide redundancy' with an operating requirement. State whether new recording must continue, whether existing footage must remain retrievable, and what interruption or recovery arrangement the owner can accept. Identify the failure being considered and the person responsible for the next action.
A requirement to continue unchanged after a disk fails needs more evidence than a disk count. Ask the supplier to describe the supported behavior during the failure condition and during the applicable recovery process. Include the incoming stream load and required playback or export task in that discussion.
Check channel and stream support, incoming bitrate, playback combination, interfaces and environment alongside storage architecture. A candidate can have adequate retention capacity while failing another operating constraint. Keep unsupported, confirmed and awaiting-confirmation fields distinct so procurement can see the unresolved requirement.
| Claim or requirement | What it establishes | Evidence still needed |
|---|---|---|
| Several fitted disks | Physical media count | Documented storage architecture |
| Visible disk-management menu | Described disk operations | Model-specific failure behavior |
| RAID-ready summary | A claim needing configuration detail | Applicable arrangement and usable capacity |
| Recording continues after failure | A required operating outcome | Supported model behavior and acceptance method |
| Verified incident export | A usable copy of selected footage | Separate evidence for continuous recording protection |
Section 04
Calculate retention after the layout is confirmed
Collect channel groups, representative average video bitrate, recording hours per day and retention days. Account separately for audio, overhead and reserve. The engineering formula in decimal units is video TB = 0.00045 × Σ(channels × Mbps × hours/day × days). Where reserve is a fraction r of usable capacity, required usable TB = recording demand ÷ (1 - r).
This topic supplies no site stream values or confirmed array layout, so it cannot produce a disk quantity or a redundancy-capacity total. Do not assume unknown layout deductions are zero. Establish what the offered arrangement makes available for recording before comparing it with the retention requirement.
If usable capacity is sufficient only under a different layout from the one supporting the failure task, that configuration does not meet both requirements together. Ask for an alternative that satisfies the same recording profile and retention period. Capacity, failure behavior and recovery conditions must refer to the same offered configuration.
Section 05
Preserve selected incidents through a separate copy task
A storage architecture and an exported incident file address different outcomes. Section 4.11.4 describes video backup. Use it to select the required channel and period, then open the resulting copy on the receiving system. Confirm the footage source, start/end coverage and any required audio.
The manual mentions players such as VLC without guaranteeing every platform and codec combination. Record the viewing method used and the authorized receiving destination. Keep the original required footage available until the copy has been verified.
An export preserves the selected deliverable; it does not demonstrate that new recording survives a disk failure. Conversely, a claimed redundancy arrangement does not remove the need to check whether an incident copy can be played by its recipient. Keep both tasks and their evidence in the acceptance record.
Section 06
Compare the complete failure-survival scope
Normalize the camera profile, retention period and playback task before comparing quotations. Require the offered storage arrangement, usable capacity and failure-response scope to be stated. Include necessary disks, accessories, software and configuration work, with the boundary of site services clearly identified.
Where an architecture needs a specific recovery process, ask who performs it and what supported conditions apply. Do not assume local labor, data recovery or unlimited replacement is included in hardware supply. Keep those obligations in the written scope rather than relying on a general resilience label.
If matched quotations are unavailable, publish a requirement-and-evidence comparison without a saving percentage or brand winner. NexPro-Link BOQ and tender support is a route for organizing the equipment and technical discussion; it does not turn an unspecified multi-disk unit into an approved failure-survival design.
Section 07
Resolve the four-disk assumption before approval
Illustrative project scenario: An owner assumes a four-disk recorder will continue unchanged after any one disk fails. The engineer records that expectation as a required outcome and asks for the model's actual architecture, usable capacity and supported recovery behavior. The cost manager holds the comparison open until those details refer to the same offered configuration.
The proposed acceptance method should address new recording and historical retrieval under the agreed conditions, with a separate export check. The scenario does not establish that the recorder passes or fails. Its useful result is a purchasing requirement that can be checked instead of an assumption derived from bay count.
Section 08
Does a multi-disk menu prove a hot spare?
No. The supplied menu describes disk-management operations. A hot-spare requirement needs explicit evidence for the identified model and offered storage configuration.
Section 09
Define the failure task for the storage proposal
Send NexPro-Link the candidate recorder identity and the recording and retrieval behavior required after a disk failure at info@nexpro-link.com.
Engineering references
These sources support the general planning principles. Always use the selected product's current datasheet and applicable project standards for final design.
