Surveillance DVR and NVR systems store footage on hard drives using proprietary file systems that no PC, Mac, or Linux machine can read. When the drive fails or the footage disappears, the video data is still on the platters, but accessing it requires both physical drive repair and proprietary file system parsing.
We recover footage from Hikvision, Dahua, Swann, Lorex, NightOwl, and other surveillance systems. Physical drive repair using PC-3000, followed by file system identification and video stream extraction. Footage is delivered in standard MP4 format playable on any device.
Yes, in most cases. The footage stays on the platters even when a PC shows the drive as unallocated and prompts you to initialize it. We repair the physical drive with PC-3000, parse the DVR's proprietary file system, then carve the H.264 video frames and deliver them as standard MP4. No data, no fee.
When you connect a DVR hard drive to a Windows PC, Disk Management will show it as "Not Initialized" or "Unallocated" and prompt you to initialize and format it. This is because Windows does not recognize the proprietary surveillance file system. Clicking "Initialize" or "Format" overwrites the on-disk structures the DVR layout depends on and destroys footage in whatever regions get written. The drive is not empty or corrupted; Windows simply cannot read the file system. Disconnect the drive and contact a recovery lab instead.
DVR and NVR manufacturers use proprietary file systems designed for continuous sequential video writes, not random-access file storage. These file systems prioritize sustained write throughput and circular overwrite (oldest footage deleted first when the drive fills) over compatibility with standard operating systems.
The drive itself is a standard SATA HDD (WD Purple, Seagate SkyHawk, or Toshiba surveillance-series). What makes it unreadable is the data layout on the platters; the DVR formatted the drive with its own file system that only the DVR firmware knows how to interpret.
Camera-side storage carries a different risk. Systems that record to a microSD in the camera depend on that card holding the capacity it claims, and a card built to overstate its size can leave a month of expected footage that was never written, discovered only when someone goes looking for a specific incident.
Standard data recovery tools (R-Studio, Disk Drill, Recuva) scan for known file system signatures: NTFS, ext4, XFS, HFS+, FAT32, exFAT. Surveillance file systems use entirely different signatures and data layouts. These tools will report the drive as empty or unformatted even though gigabytes of video data exist on the platters.
Recovery requires specialized software that understands each manufacturer's proprietary format. The DVR brand determines the file system, not the drive brand. A WD Purple drive from a Hikvision NVR has a completely different data layout than the same WD Purple drive from a Dahua NVR.
Some NVR appliances expose a small mountable partition on the drive. It does not hold the footage.
Many standalone analog DVRs expose nothing mountable at all. They write their proprietary block structure across most or all of the disk, so Linux often sees the drive as one unpartitioned span, or reports the video region as an unknown filesystem no Linux driver recognizes.
Either way the video is written to a raw block region, or a large preallocated proprietary allocation, that sits outside any mountable filesystem. Hikvision keeps it in the Master Sector and HIKBTREE layout, and Dahua in DHFS 4.1. Neither is a filesystem Linux can mount.
So mounting the drive, or seeing unallocated space where you expected a filesystem, does not reveal the surveillance video. Recovering it means parsing the proprietary video layout directly, the same work described in the Hikvision, Dahua, and Swann sections below.
Hikvision DVRs and NVRs use a proprietary file system with no public specification. Forensic analysis (Han & Jeong, ICDF2C 2015) identified the following on-disk structure:
Located at disk offset 0x200. Contains the signature HIKVISION@HANGZHOU (18 bytes). Defines the disk layout: total capacity, system log offset, video data area offset, data block size, total data block count, HIKBTREE index offset, and the system initialization timestamp (UNIX epoch). A backup Master Sector follows the system logs area for redundancy.
Raw H.264 (or H.265 on newer units) video stored in data blocks, typically 1 GB each. Each data block contains sequential video frames from one channel. Video frames are stored as raw NAL units; there is no MP4, AVI, or MKV container wrapping the video.
A B-tree structure (signature: HIKBTREE) that maps recording timestamps to data block locations. Each entry includes the channel identifier, start/end timestamps, and a data block offset pointer. Once the DVR's circular recording has written new footage over old blocks, that footage cannot be recovered.
Stores UNIX timestamps of DVR events: power on/off, recording start/stop, alarm triggers, user logins, and configuration changes. These logs are useful in forensic investigations to establish a timeline of DVR activity independent of the video recordings.
Dahua uses a proprietary file system called DHFS (Dahua File System). Current devices run DHFS 4.1. Unlike Hikvision's format, Dahua wraps each video frame in a DHAV container with header and footer signatures that enable frame-level validation during recovery.
Each DHAV frame begins with the ASCII header DHAV (uppercase) and ends with the footer dhav (lowercase). The header contains: frame type identifier (1 byte at offset 4; 0xFD = video, 0xF0 = audio), channel identifier (1 byte at offset 6), frame number (32-bit little-endian at offset 8), frame length (32-bit little-endian at offset 12), date/time (32-bit little-endian at offset 16), and a timestamp field at offset 20. That 24-byte fixed header is followed by a variable-length extension header before the video payload begins.
This dual-signature design (uppercase header, lowercase footer) means recovery tools can validate individual frames even when the surrounding file system metadata is corrupted. FFmpeg includes a DHAV demuxer (libavformat/dhav.c) that can parse raw DHAV frame streams, which makes Dahua footage reconstruction possible even from heavily damaged disk images.
Swann surveillance systems write video in a proprietary on-disk format with no public specification.
There are no discrete video files to copy off. The recorder writes H.264 or H.265 data sequentially and loops back over the oldest recordings once the drive fills, and it keeps its own index to map recording times back to positions on the disk.
If that index is corrupted or lost, the raw video data is separated from its temporal metadata.
When the timestamp-to-block mapping is corrupted or unreadable, the timestamp references go with it. Recovery from that drive then falls back to sequential NAL frame carving, which returns the surviving video without date/time metadata.
Do not put a drive you want recovered back into a Swann unit, a replacement unit, or any other DVR, even to check whether it still works. Initializing or formatting through a DVR interface writes over the existing data layout. Send the drive to the lab instead of testing it in a DVR.
Surveillance drives run 24/7 for months or years. Head crashes, motor bearing failure, and firmware corruption are the most common physical failures. If the drive clicks, does not spin up, or is not detected in BIOS, we repair it using PC-3000 and create a sector-by-sector clone to a healthy drive before touching the data layer. This is identical to standard hard drive data recovery.
Scan the cloned image for manufacturer signatures.HIKVISION@HANGZHOUidentifies a Hikvision file system.DHAVframe headers identify Dahua DHFS. Other brands (Swann, Lorex, NightOwl) use vendor-specific proprietary formats. Each requires a different parsing approach.
Parse the proprietary index structures to map recording timestamps to physical data block locations. In Hikvision systems, the HIKBTREE index enables date/time range extraction. In Dahua systems, DHFS metadata serves the same function. If the index is corrupt (common after power loss), we fall back to raw video carving in the next step.
Extract raw H.264 or H.265 video from the proprietary data blocks. For unfinalized recordings (footage that was being written when power was lost), we scan the raw data area for NAL start codes (0x00 0x00 0x00 0x01) and identify frame types: IDR keyframes (NAL type 5), SPS/PPS decoder configuration (NAL types 7 and 8), and inter-coded frames (NAL type 1). These are reassembled into playable video sequences and wrapped in standard MP4 containers.
DVR systems write video frames to disk in real time but update their file system index on a separate schedule. When power is cut during active recording, the video data from the most recent segment exists on the platters but the index does not reference it. The DVR treats this segment as if it never existed.
Power loss before an index update leaves recorded footage unreferenced. The recording was not lost; the index was not updated before power was cut. Recovery means ignoring the index entirely and scanning the raw video data area for frame signatures. In Hikvision systems, we look for H.264 NAL units within data blocks that have no corresponding HIKBTREE entry. In Dahua systems, we scan for orphaned DHAV frame pairs (uppercase header, lowercase footer) outside the DHFS metadata scope.
The critical risk factor is circular overwrite. If the DVR continued recording after power was restored and the drive was full, the system will overwrite the oldest data blocks first. If the unfinalized segment occupied those oldest blocks, the video frames may already be partially or fully overwritten. The sooner the drive is pulled from the DVR after a power loss event, the higher the likelihood of recovering the unindexed footage.
No, not once new video has physically landed on the sectors. CCTV systems record in a circular buffer that overwrites the oldest footage first. Once a data block is physically overwritten by new video, the previous content is gone.
On modern perpendicular magnetic recording (PMR) and shingled magnetic recording (SMR) surveillance platters, the magnetic domains are packed so densely that a single overwrite leaves no readable residual of the prior state.
The magnetic-remanence idea, the notion behind the Gutmann 35-pass method that a lab can read under overwritten data with a microscope, does not apply at current drive densities. We do not offer, and no legitimate lab offers, remanence recovery of overwritten sectors.
The caveat is in what "overwritten" covers. Unindexed or unfinalized footage that sits in blocks the circular buffer has not yet cycled back over is still recoverable by carving. What is destroyed is only what new writes physically landed on top of.
This is why pulling the drive from the DVR quickly after an incident matters. It stops the ring from overwriting the segment you need. A unit left recording over the following days keeps cycling new video across the platters, and every pass narrows what carving can still reach.
When both the proprietary file system and its metadata index are too damaged to parse, we fall back to raw H.264 frame carving directly from the disk image. This is the last-resort recovery method and produces results even when no file system information survives.
H.264 video is composed of NAL (Network Abstraction Layer) units, each preceded by a 3-byte (0x00 0x00 0x01) or 4-byte (0x00 0x00 0x00 0x01) start code.
The byte following the start code identifies the NAL unit type: type 5 is an IDR keyframe (the starting point of a decodable sequence), types 7 and 8 are SPS (Sequence Parameter Set) and PPS (Picture Parameter Set) containing decoder configuration (resolution, frame rate, encoding profile), and type 1 is a non-IDR inter-coded frame.
The carving process scans the raw disk image for these start codes, classifies each NAL unit by type, and reassembles them into playable sequences. SPS and PPS parameters are essential for playback; if they are lost from the damaged sectors, compatible parameters must be reconstructed based on the DVR model's known encoding settings. The reassembled H.264 stream is then wrapped in an MP4 container with synthesized timing metadata.
Frame carving recovers video content but loses the original timestamp associations. The footage can be placed in approximate chronological order based on frame sequence numbers and any surviving metadata fragments, but exact date/time accuracy depends on how much of the file system index survived.
The scan that finds the video is the same; the header you read afterward is twice as long. Newer CCTV systems record H.265/HEVC instead of H.264, and in an Annex B byte stream HEVC still uses the same start-code prefixes: the 3-byte 0x00 0x00 0x01 or 4-byte 0x00 0x00 0x00 0x01. Carving locates NAL units by those prefixes exactly as it does for H.264.
The structural difference sits in the header. An HEVC NAL unit header is 2 bytes, versus H.264's 1 byte. In that 2-byte header the forbidden_zero_bit is 0, followed by the 6-bit nal_unit_type, then nuh_layer_id and nuh_temporal_id_plus1. Identifying a carved HEVC NAL means reading the type field out of a 2-byte header, not the single byte that follows an H.264 start code.
HEVC also carries a parameter set H.264 does not have: the Video Parameter Set (VPS), NAL type 32. Alongside it are the Sequence Parameter Set (SPS), NAL type 33, and the Picture Parameter Set (PPS), NAL type 34. IDR keyframes are NAL types 19 and 20 (IDR_W_RADL and IDR_N_LP).
Partial-sector damage is where the difference bites. The VPS, SPS, and PPS carry resolution, frame rate, and decoder configuration. If a damaged sector wipes them out, the surviving IDR keyframes and the inter-coded frames that depend on them are orphaned: the decoder cannot establish picture size or GOP initialization, so those frames will not play until a matching parameter set is recovered or reconstructed from another segment.
An H.265 carve off a damaged drive can therefore return raw frames that still need their parameter sets rebuilt before playback.
| Brand | File System | Video Format | Notes |
|---|---|---|---|
| Hikvision | Proprietary (HIK) | raw H.264 | HIKBTREE index maps timestamps to data blocks |
| Dahua | DHFS 4.1 | .dav / DHAV / raw H.264 | Dual-signature frames (DHAV/dhav), FFmpeg demuxer available |
| Swann | Proprietary (undocumented) | H.264 / H.265 | Circular buffer, proprietary layout |
| Lorex | Varies by model | H.264 / H.265 | Some models rebadged from Dahua; may use DHFS |
| NightOwl | Varies by model | H.264 | Consumer-grade; often uses generic HiSilicon-based firmware |
| Samsung / Hanwha | Proprietary | H.264 / H.265 | Wisenet series; enterprise-grade, different from consumer Samsung |
Many lower-cost DVR brands are white-label products that share a hardware platform with a larger OEM. If your DVR brand is not listed, contact us with the brand and model number. We identify the on-disk format from the drive image itself rather than from the label on the box.
DVR and NVR systems use surveillance-rated drives designed for 24/7 continuous sequential writes. These drives have firmware optimizations for sustained throughput and vibration tolerance in multi-drive enclosures. When they fail, the physical recovery is identical to any HDD; the difference is in the file system layer above.
Desktop drives in DVRs: Using a non-surveillance drive (WD Blue, Seagate Barracuda) in a DVR shortens the drive's life. WD rates the Purple line at up to 180 TB/year, which its product brief puts at up to three times the workload rating of a desktop drive. Running a desktop drive 24/7 in a continuous write environment accelerates bearing wear, increases reallocated sector counts, and leads to premature head crashes.
Seagate SkyHawk surveillance drives run ImagePerfect firmware. Seagate markets it as handling simultaneous HD video streams from up to 64 cameras without a drop in frame quality.
On a degraded SkyHawk we image sector by sector using PC-3000 with controlled per-sector read timeouts, rather than leaving the pacing to the drive. For drives with weak heads, we map the head performance and build a custom imaging profile that reads good heads first and defers degraded heads to subsequent passes.
Surveillance footage used in criminal investigations, civil litigation, or insurance disputes must meet evidentiary standards. Federal Rule of Evidence 901 asks the proponent to produce evidence sufficient to support a finding that an item is what the proponent claims it is, which is why the imaging documentation and hash records matter. Improper handling can result in a motion to suppress the evidence, rendering the footage inadmissible regardless of its content.
DVR drives are imaged read-only: the imager issues read commands to the source and writes nothing back to the original media. This is not optional for forensic work. Never reconnect a drive you want preserved to a DVR unit to check it, even briefly. An initialize or format through the DVR interface is how evidence gets overwritten.
Before imaging begins, a SHA-256 hash is computed over the entire original drive. After the forensic image (E01 format) is created, the same hash is computed on the image and compared. Matching hashes prove bit-level integrity: no data was added, removed, or altered during the imaging process. MD5 hashes are also generated for compatibility with legacy forensic workflows.
Each evidence item receives a unique identifier. Documentation records the timestamp of every handling event: when the drive was received, who handled it, what procedures were performed, where it was stored, and when it was returned. This audit trail establishes an unbroken chain from evidence collection to courtroom presentation.
Recovered footage is delivered in standard MP4 containers with original timestamp metadata preserved where the proprietary index survived. A forensic report accompanies the delivery, listing: the original drive model and serial number, SHA-256 hashes, the number of channels recovered, total hours of footage, and any gaps caused by physical damage or overwritten sectors.
Break-ins, robberies, assaults, and property crimes captured on surveillance cameras. Law enforcement may need footage from a specific date/time range. We can extract targeted segments when the HIKBTREE or DHFS metadata is intact, preserving chain of custody documentation.
Fire damage, flooding, vehicle accidents, and liability incidents. Insurance adjusters and attorneys request surveillance footage as evidence for claims processing. Footage is delivered in standard MP4 format with timestamp metadata when available.
Warehouses, retail stores, restaurants, and facilities with regulatory recording requirements. A failed DVR drive does not eliminate the compliance obligation. Recovery of the footage restores the documentation trail.
DVR recovery pricing depends on two factors: the physical condition of the drive and the complexity of the file system parsing. If the drive is mechanically healthy (no clicking, spins up, detected in BIOS), the cost covers proprietary file system parsing and video extraction only. If the drive has a physical failure, standard HDD repair pricing applies for the drive repair, with file system parsing included.
Your drive works, you just need the data moved off it
Functional drive; data transfer to new media
Rush available: +$100
$100
3-5 business days
Your drive isn't recognized by your computer, but it's not making unusual sounds
File system corruption. Accessible with professional recovery software but not by the OS
Starting price; final depends on complexity
From $250
2-4 weeks
Your drive is completely inaccessible. It may be detected but shows the wrong size or won't respond
Firmware corruption: ROM, modules, or translator tables corrupted; requires PC-3000 terminal access
CMR drive: $600. SMR drive: $900.
$600–$900
3-6 weeks
Most Common
Your drive is clicking, beeping, or won't spin. The internal read/write heads have failed
Head stack assembly failure. Transplanting heads from a matching donor drive on a clean bench
50% deposit required. CMR: $1,200-$1,500 + donor. SMR: $1,500 + donor.
50% deposit required
$1,200–$1,500
4-8 weeks
Your drive was dropped, has visible damage, or a head crash scraped the platters
Platter scoring or contamination. Requires platter cleaning and head swap
50% deposit required. Donor parts are consumed in the repair. Most difficult recovery type.
50% deposit required
$2,000
4-8 weeks
Our "no data, no fee" policy applies to hardware recovery. We do not bill for unsuccessful physical repairs. If we replace a hard drive read/write head assembly or repair a liquid-damaged logic board to a bootable state, the hardware repair is complete and standard rates apply. If data remains inaccessible due to user-configured software locks, a forgotten passcode, or a remote wipe command, the physical repair is still billable. We cannot bypass user encryption or activation locks.
No data, no fee. Free evaluation and firm quote before any paid work. Full guarantee details. Head swap and surface damage require a 50% deposit because donor parts are consumed in the attempt.
The prices above are for standard hard drives, which covers most jobs. Helium-sealed drives (for example WD or HGST Ultrastar He and Seagate Exos X) must be resealed and refilled with helium in-house after the chamber is opened, so they price higher, in the $200–$5,000+ range. See helium drive pricing.
Free evaluation. Firm quote before any paid work begins. No data recovered means no charge. Call (512) 212-9111 or request an evaluation online.
No. Hikvision uses a proprietary file system that is not ext, NTFS, FAT, or any format Windows or Linux recognizes. Connecting the drive to a PC shows it as 'Unallocated' in Disk Management, and Windows will prompt you to initialize and format the drive. Accepting that prompt overwrites the proprietary on-disk structures the DVR layout depends on, destroys footage in whatever regions get written, and reduces what is recoverable. Disconnect the drive instead.
DAV is Dahua's proprietary video container format. It wraps H.264 or H.265 video streams in a non-standard container that most media players cannot open. Windows Media Player and QuickTime will not play .dav files natively. Dahua's own player software can play them. For recovery purposes, we extract the raw H.264 stream from inside the .dav container and re-wrap it in a standard MP4 container for universal playback.
Usually yes, for footage recorded before the power loss. DVR systems write H.264 video frames to disk in real time, but update the file system index (the part that makes footage searchable by date/time) on a separate schedule. Power loss interrupts the index update, so the most recent recording segment becomes 'invisible' to the DVR even though the raw video data is on the platters. We recover unfinalized footage by scanning the raw data area for H.264 NAL start codes and reassembling the video frames. The risk: if the DVR continued recording after power was restored, it may have begun overwriting that unindexed footage with new recordings.
DVR recovery for drives with no physical damage that need proprietary file system parsing falls under our file system recovery tier (From $250). Drives with head failures, motor seizure, or platter damage follow our standard HDD pricing tiers. The forensic video reconstruction step (parsing the proprietary file system, reassembling unfinalized streams, carving H.264 frames) is included in the quoted price. Free evaluation. No data recovered means no charge.
Both are surveillance-rated drives designed for 24/7 continuous write workloads. WD Purple is rated for 180 TB/year write workload. Seagate SkyHawk carries the same 180 TB/year rating. When either one fails, it fails through head crashes, motor seizures, firmware corruption, or reallocated sector accumulation. The recovery procedure for the physical drive is the same as any HDD. The difference is in the file system layer, which is determined by the DVR brand, not the drive brand.
Yes, if the metadata index is intact. Hikvision stores a HIKBTREE index that maps timestamps to data block locations on disk. Dahua stores equivalent metadata in DHFS. If these indexes survive, we can extract footage from specific date and time ranges. If the index is corrupted or the blocks have been overwritten by circular recording, we fall back to sequential H.264 frame carving, which recovers all surviving video but loses the timestamp associations.
Yes. Swann DVRs write video in a proprietary on-disk format without standard file boundaries. The same NAL start code scanning and H.264 frame carving techniques used for Hikvision and Dahua apply.
Yes, if proper forensic handling is followed. The drive is imaged read-only, so the imager issues read commands to the source and nothing is written back to the original media. A SHA-256 hash of the original drive is computed before imaging and verified against the forensic copy. We provide chain-of-custody documentation including timestamps, handler identification, and hash verification records. Federal Rule of Evidence 901 asks the proponent to produce evidence sufficient to support a finding that an item is what the proponent claims it is, which is what imaging documentation and hash records establish.
That partition is not where the recordings are. The video sits in a raw block region written in the manufacturer's proprietary layout, which no Linux filesystem driver can mount. Mounting the partition will not reveal footage; recovery means parsing the proprietary video layout directly.
No. Once new video is physically written over a block, that footage is gone, because a single overwrite on modern PMR and SMR surveillance platters leaves no readable residual. Footage the circular buffer has not yet cycled over is still recoverable by carving, so pulling the drive early, before the ring overwrites the segment you need, is what preserves it.
Our Austin lab operates on a transparency-first model. We use industry-standard recovery tools, including PC-3000 and DeepSpar, combined with strict environmental controls to maintain drive integrity. This approach allows us to serve clients nationwide with consistent technical standards.
Open-drive work is performed in a 0.02 micron ULPA-filtered laminar clean bench.
Serving clients nationwide via mail-in service since 2008. Our lead engineer holds PC-3000 and HEX Akademia certifications for hard drive firmware repair and mechanical recovery.
Our repair work has been covered by The Wall Street Journal and Business Insider, with CBC News reporting on our pricing transparency. Louis Rossmann has testified in Right to Repair hearings in multiple states and founded the Repair Preservation Group.
Our "No Data, No Charge" policy means we assume the risk of the recovery attempt, not the client.
Louis Rossmann
Our engineers review all lab protocols to maintain technical accuracy and honest service. Since 2008, his focus has been on clear technical communication and accurate diagnostics rather than sales-driven explanations.
We believe in showing the bench rather than just describing it. Open-drive work runs on a 0.02 micron ULPA-filtered laminar clean bench, and we filmed it.
See the particle counter test at the benchRelated services
WD Purple surveillance drive recovery for DVR/NVR systems
Seagate SkyHawk firmware repair and head swap for NVR/DVR drives
Mechanical HDD failure and head swaps
Multi-drive NVR arrays
Network storage systems
Enterprise server drives
MicroSD wear-out and video reconstruction for vehicle cameras
View complete catalog
Free evaluation. Proprietary file system parsing for Hikvision, Dahua, and other DVR systems. Footage delivered in standard MP4 format. No data recovered, no charge.
