A SkyHawk surveillance drive out of a DVR that had recorded continuously for years. The incident under investigation was three weeks old, and on a system overwriting its oldest footage daily, three weeks is the entire question.
A business needed footage of an incident roughly three weeks old. The DVR had stopped showing recent recordings and its own playback interface returned errors, so nobody could establish whether the relevant period still existed. The system had been left running throughout — the standard mistake, and an entirely understandable one, because the recorder is a security device and switching it off feels like the wrong instinct.
This single calculation decides most CCTV jobs before any bench work starts, and almost no site has done it.
A DVR records continuously and, once the disk is full, begins overwriting its oldest footage. How long that gives you is not a fixed figure — it falls directly out of total bitrate. Work it in bytes per day:
A modest system. Eight channels at 2 Mbit/s each is 16 Mbit/s, which is 2 MB per second, about 173 GB per day. A 4 TB disk holds roughly 23 days.
A busy one. Sixteen channels at 4 Mbit/s each is 64 Mbit/s, which is 8 MB per second, about 691 GB per day. The same 4 TB disk now holds under six days.
Same drive, same building, four times the retention difference — and higher resolutions, higher frame rates and continuous rather than motion-triggered recording all push it the wrong way. H.265 roughly halves the bitrate against H.264 for equivalent quality, which is worth knowing before assuming a figure quoted at installation still applies after a camera upgrade.
So every day a recorder stays powered after an incident is another day of the oldest footage being destroyed — and the oldest footage is precisely the period under investigation. That is why the first instruction on any CCTV enquiry is to power the recorder down. Not to protect the disk: to stop the clock. Here the system had run three weeks past the incident, putting the target period close to the edge of its window.
SkyHawk, WD Purple and equivalent surveillance-class drives are not desktop disks in different packaging. They are specified for sustained sequential writing from many simultaneous streams, typically rated around 180 TB per year of workload against roughly 55 TB for a desktop drive, and fitted with rotational vibration sensors because they are expected to sit in multi-bay recorders.
The behaviour that matters for recovery is in the firmware. Surveillance drives run a short error recovery timeout — a handful of seconds rather than the tens of seconds a desktop drive will spend on a stubborn sector. The design intent is sound: a recorder must not drop frames while a disk sulks over one block, so the drive gives up quickly and moves on.
The side effect is that a surveillance drive can accumulate genuinely unreadable regions while continuing to look healthy to the recorder, because the recorder never goes back to check. Attribute 197 climbs, attribute 187 climbs, and nothing in the DVR interface reports either. The fault surfaces only when somebody tries to play something back — which is to say, only when it matters.
The drive was removed and imaged read-only through a write blocker, and the imaging order was decided from the incident date rather than starting at sector zero.
The recorder writes chronologically in a circular pattern, so a date maps to an approximate physical region. That region was located first from the block headers and secured before anything difficult was attempted, on the principle that the one thing the client actually needed should be in hand before the drive was asked to do anything strenuous. Bulk passes then covered the remainder, with defective areas deferred to graduated passes at reducing block sizes.
DVR manufacturers do not use NTFS, ext4 or exFAT. They write their own layouts directly to the raw device, because a general-purpose file system carries overhead a recorder does not want and offers guarantees a recorder does not need. There was nothing to mount and nothing a conventional recovery tool would recognise.
The structure was reverse-engineered from the image. These formats follow a consistent pattern: fixed-size allocation units, each prefixed by a header carrying channel number, timestamp, stream identifier and payload length, with an index region near the start of the disk mapping time ranges to unit addresses. The headers were located by their repeating signature and stride, parsed into an index of what existed and when, and cross-checked against the recorder’s own index where that had survived.
The payloads themselves are ordinary compressed video — H.264 or H.265 elementary streams, complete with sequence and picture parameter sets. Once the units were ordered by channel and timestamp, the streams were extracted and remuxed into a standard container that plays anywhere, without needing the original recorder or its proprietary player.
Timestamps were preserved from the block headers rather than regenerated, which matters when footage may be used evidentially: a clip whose timing comes from the recorder’s own metadata can be accounted for, and one that has been re-timed on export cannot.
The target period was recovered in full, together with a substantial run either side of it.
Some earlier footage was not recoverable, and the distinction there is worth stating precisely: it had not been damaged, corrupted or lost to bad sectors. It had been overwritten — physically replaced by newer recordings while the system continued running. No technique retrieves that, at any price, and anyone who says otherwise is selling something.
Had the recorder been powered down on the day the incident was discovered rather than three weeks later, the entire period either side would have been sitting on the disk untouched.
Kick off with an instant online quote, or ring us and talk it through first. Either way you’ll know a clear, fixed price before any work starts.