How Tesla stores video files on USB drives

Six cameras, one-minute clips

Every Tesla built from mid-2017 onwards has six external cameras used for Sentry Mode and Dashcam recording: front, back, left repeater, right repeater, left pillar, and right pillar. When recording is active, Tesla writes a separate MP4 file per camera, in continuous one-minute chunks. A single minute of Dashcam footage produces six MP4 files of roughly 15–30 MB each.

Cybertruck and the refreshed Model S Plaid add a rear-backup camera that also participates in recording, so you may see seven-clip events on those vehicles. The carving mechanics are identical — just one more file per minute.

The TeslaCam folder structure

On a functioning Tesla USB drive, the root directory contains one folder called TeslaCam, which in turn contains three subfolders plus any manually-created top-level folders for music or USB-to-Bluetooth pairing.

• TeslaCam/RecentClips/ — a rolling buffer of recent driving. Auto-deletes the oldest clips as the drive fills up.
• TeslaCam/SentryClips/ — stores video around Sentry Mode detection events (someone bumps the car, alarm triggers, object detection). Organised into subfolders named with the event timestamp, e.g. 2026-04-17_14-30-22.
• TeslaCam/SavedClips/ — footage you explicitly tagged with the on-screen dashcam button. Preserved until you manually delete.

Each SentryClips event folder also contains an event.json sidecar file with the trigger reason, camera direction, estimated GPS, and timestamp of the event.

The filename convention

Tesla names each clip with the recording-start timestamp and the camera position:

YYYY-MM-DD_HH-MM-SS-{camera}.mp4

Example: 2026-04-17_14-30-22-front.mp4. The camera suffixes are front, back, left_repeater, right_repeater, left_pillar, and right_pillar. Recovering these filenames intact means you can tell which angle a clip was shot from at a glance, which matters enormously for insurance claims or police reports where you need to show specific directions.

exFAT and 128 KB clusters

Tesla formats USB drives as exFAT, a file system Microsoft designed for flash storage with large files. Two facts matter for anyone trying to understand their drive:

• Default cluster size is 128 KB on a Tesla-formatted drive. That means files are written in chunks of 128 KB at a time, aligned to 128 KB boundaries. A 15 MB clip occupies 120 contiguous 128 KB clusters.
• exFAT tracks file locations in a single directory table (plus a "FAT" chain for files that span multiple clusters). Quick-formatting wipes these tables without touching the actual cluster data.

Cluster alignment is why raw-sector recovery can be extremely fast on a Tesla drive — the search only needs to check one position every 128 KB instead of every byte.

Inside a Tesla MP4 file

Tesla's MP4 files follow the standard ISO base media file format but with one quirk that matters for recovery: the metadata atom (moov) is written at the end of the file, not the beginning. The internal structure is:

1. ftyp atom — the first few bytes of every MP4. Identifies it as an MP4 and specifies the brand (Tesla uses mp42).
2. mdat atom — the actual video data, the bulk of the file.
3. moov atom — metadata including duration, dimensions, codec, and the timestamp index. Tesla writes this last because the clip's total length isn't known until recording ends.

This structure is why confidence-scoring recovery tools can rate a carved clip 0–100 before you save it: parsing the ftyp tells you it's a valid MP4, parsing the mdat tells you the video data length is plausible, and parsing the moov confirms the metadata is intact.

Why all this matters when things go wrong

When a drive is formatted, corrupted, or simply full and cycling old clips, the recoverable content depends on which of the structures above survived:

• Directory table gone, cluster data intact (quick format): all clips recoverable by file carving. Camera-angle filenames may be lost depending on how recently directory entries were overwritten.
• Some clusters overwritten by newer clips (drive reused after deletion): older footage in the overwritten regions is gone; everything else is still recoverable.
• Every cluster zero-written (full format with zero-fill): the data is genuinely destroyed at the software level and can't be recovered by any file carving tool.