Blackjack AI Server and Video Storage Sizing
Blackjack servers and AI appliances provide purpose-built recording platforms for DW Spectrum. Model selection should follow measured camera throughput, storage retention, analytics workload, redundancy, rack, power and service requirements rather than camera count alone.
Select the complete system, not one headline feature
Match devices, software, licensing, infrastructure, retention, integrations and support to the operating requirement before finalizing the design.
Calculate the recording workload
Inventory every stream with resolution, codec, frame rate, estimated bitrate, recording schedule and retention. Add simultaneous viewing, export, analytics and failover traffic. Use representative scene measurements because motion, noise and lighting can change bitrate substantially.
A sizing model carries assumptions, so write down which retention periods came from policy, which bitrates were measured on site and which were estimated from a similar camera. Where a number is a guess, note the range you used and revisit it once the system has recorded through a normal week of activity.
- Per-stream bitrate and schedule
- Retention and evidence requirements
- Concurrent playback and export
- Analytics and integration overhead
Choose server, storage and redundancy
Compare appliance form factor, drive bays, usable capacity, network interfaces, operating system and supported camera or analytics load. Decide whether RAID, spare capacity, server failover or external storage is required. Redundancy protects different failures and does not replace backup of configuration.
Confirm before the purchase order that the appliance ships with the drive configuration, camera channel licensing and analytics support you priced. Two units sold under one product family name can differ in usable capacity after RAID and in how many streams the software will accept, and neither difference shows up in the model number.
- Raw versus usable capacity
- RAID and spare strategy
- Server failover scope
- Model support and lifecycle
| Input | Why it matters | Evidence |
|---|---|---|
| Video bitrate | Sets recording throughput | Camera stream measurement |
| Retention | Sets usable storage | Policy and calculator output |
| Analytics | Consumes server resources | Supported workload matrix |
| Resilience | Changes hardware and capacity | Failure and recovery plan |
Rack, power and network design
Coordinate rack depth, rail clearances, front-to-back airflow, dual power where available, UPS runtime, bonding and network uplinks. Isolate recording traffic when design requires it and avoid oversubscribing a single switch or uplink. Label drives, interfaces and management connections.
Administrative access to the recorder, the switch and the UPS network card belongs to named people rather than one shared login. Schedule firmware work on these devices for a window when a gap in recording is acceptable, and confirm the running configuration has been exported somewhere off the appliance before anything is applied.
- Rack, cooling and UPS
- Network interfaces and uplinks
- Time and management services
- Drive and port labeling
Commissioning and lifecycle
Test recording across all cameras, playback, export, analytics, alarms, time synchronization and recovery after restart. Review storage forecasts after real operation. Record warranty, support status, drive replacement method and the software ceiling of older server generations.
Sign-off should rest on evidence rather than a screen that looks right: recorded days per camera measured against the target, an export a reviewer can actually open, and a documented drive-replacement path. Hand over serials, license keys, drive layout, network settings and any camera whose retention fell short with the owner named.
- Sustained recording test
- Playback/export validation
- Storage forecast review
- Replacement and support record
How we plan and deliver the work
The final design depends on site conditions, existing systems, client policies and the selected manufacturer or platform.
Measure throughput
Collect camera counts, resolutions, frame rates and codecs to calculate the actual recording bitrate the server must absorb.
Size retention
Convert that bitrate into usable storage for the required retention days, allowing for RAID overhead and future growth.
Select and stage
Choose the server, drive configuration and network interfaces, then build and burn in the platform before delivery.
Rack and verify
Install in the rack, connect power and network, then confirm recording, retention and failover behave as designed.
Information to gather before design
Recorder sizing follows measured video load rather than camera count, so gather stream, retention and rack details before any model is quoted.
- Camera count by resolution and codec
- Frame rate and recording mode per group
- Retention required in days
- Analytics running on server or camera
- Rack space, power and cooling available
Frequently asked questions
These are common planning questions. A site-specific answer should be confirmed during discovery and design.
Is camera count enough to size a recorder?
No. Bitrate, retention, analytics, playback and redundancy determine the real workload.
Is raw disk capacity the usable recording capacity?
No. RAID, formatting, reserve and operational overhead reduce usable storage.
Does RAID replace server failover or backup?
No. Each control addresses different failure conditions.
Can older Blackjack servers run every new DW Spectrum release?
Not necessarily; verify the server model, operating system and current support documentation.
Manufacturer software, firmware and technical files remain on the manufacturer’s official website. We do not mirror firmware files locally.
Size a Blackjack recorder for your camera load
Describe the camera load in real terms: counts by resolution and codec, frame rate per group, retention in days, and whether analytics run on the server or at the camera. Rack space, power and cooling limits matter just as much.