Verify a backup in layers: compare its hash, inspect the tracks, decode the whole file, check it in the intended player, then restore a copy. A matching hash answers whether a copy matches its reference. It cannot tell you whether that reference was already damaged or contains the right recording.
This workflow is for readable MKV or MP4 files from your own or authorized media. It is not a disc-decryption procedure or an ISO/BDMV menu validator. For whole-disc structures, use the separate ISO backup checklist as well.
Decide what the backup must contain
Before testing, record the source and destination paths, file size, expected recording and duration, required audio/subtitle tracks, and the date and tool versions. Keep the source available. A file can decode without errors while containing the wrong title or a valid but incomplete recording.
Use the following checks for different questions:
| Check | Useful evidence | Still unresolved |
|---|---|---|
| SHA-256 against a reference | The copied file matches the reference bytes | Whether those bytes were good in the first place |
| Stream inventory | Detected container, duration and track information | Whether every frame can be decoded |
| Decode through the file | Errors reported by this tool while processing the mapped audio/video | Correct title, subtitles, menus, visual quality and device support |
| Target-player check | Behavior in the player and scenes actually checked | Untested scenes or other devices |
| Restore from a separate backup | A copy can be retrieved and checked now | Future readability or a substitute for keeping multiple copies |
The personal-media archiving guide explains where these checks fit into a wider backup plan.
1. Compare an unchanged copy with its reference
In PowerShell, replace both paths with files you intend to compare:
Get-FileHash -LiteralPath 'D:\Source\home-video.mkv', 'E:\Backup\home-video.mkv' -Algorithm SHA256 |
Format-List Path, Algorithm, HashCompare the full hash values using the same algorithm. Microsoft documents this content comparison; the Library of Congress describes checking against an earlier fixity value.
This is a comparison for an unchanged file copy. Remuxing or transcoding creates a different file and can change its hash. Assess that output separately and establish a new baseline. If a plain copy differs, preserve both files, check the copy process and storage, and repeat the comparison before treating it as accepted. See large-file USB copying if the transfer itself failed.
2. Read the stream inventory
The commands below require ffmpeg and ffprobe to be available in your terminal. Record ffmpeg -version and ffprobe -version; builds can differ in supported codecs. Save logs in a separate working directory, using new names for each run.
ffprobe -v error -show_format -show_streams -of json 'E:\Backup\home-video.mkv' > inventory.json
$LASTEXITCODEThe ffprobe documentation describes the format and stream reports. Compare their duration, codecs and track list with your expectations. Missing language tags require listening or viewing to identify the track. A successful inventory is not a successful full decode: headers may remain readable while media data is damaged.
3. Decode the file’s video and audio to null
Run this against the backup, not just the source:
ffmpeg -hide_banner -v error -xerror -i 'E:\Backup\home-video.mkv' -map '0:v?' -map '0:a?' -f null - 2> decode-errors.log
$decodeExit = $LASTEXITCODE
$decodeExit
Get-Content -LiteralPath decode-errors.logThe explicit maps select matching video and audio streams. The question marks allow an absent stream type, so check that every track you expected actually exists. These maps do not test subtitles, attachments or disc menus. -xerror stops on an error; a stopped run has not inspected the rest of the file. -v error records errors and more severe messages, not all warnings. See the FFmpeg options.
The null output discards the decoded output rather than saving another movie. It leaves the input unchanged. Do not add -c copy: packet copying skips decoding. Do not use a short -t scan and call it a whole-file check.
Let the command finish normally without interruption. An exit code of zero with no reported error means this run found no error within its decoding checks. It is not proof that all possible damage is detectable. An unsupported decoder, invalid option or inaccessible file also causes failure; read the log before calling the media corrupt. A file with a valid early ending may pass, so compare the expected duration and final scene with the source.
What our synthetic test actually showed
On October 23, 2026, we generated a three-second H.264/AAC MKV and changed a length field in its first video packet. We used the existing FFmpeg/ffprobe build N-100410-gcd821c18dc; this was an older local build, not a claim about the latest release.
| Synthetic file | SHA-256 compared with its own unchanged copy | ffprobe inventory | Full audio/video decode |
|---|---|---|---|
| Healthy generated file | Matched | H.264 and AAC listed; exit 0 | Exit 0 |
| File with a deliberately invalid video-packet length | Matched | H.264 and AAC still listed; exit 0 | Exit 1, invalid NAL size error |
Both files were 184,913 bytes. The damaged file and its copy matched each other, not the healthy reference. This demonstrates why matching hashes and readable metadata are insufficient on their own. It does not measure corruption-detection rates, Blu-ray drive reliability or player compatibility. No physical disc or playback hardware was tested.
4. Check the content in the intended player
Open the backup from its destination location in the player you plan to use. Check the beginning, middle and end, seeking and chapter jumps, sound synchronization, and each required audio track. Check selectable subtitles and a scene that needs forced subtitles; the decode command above did not test them. The audio and subtitle retention guide provides that checklist.
Sampling is a practical check of those scenes, not a guarantee about every frame. For irreplaceable recordings, review the full content against the source when possible. A technically valid file with the wrong ending or missing family footage still fails your acceptance criteria.
5. Restore a separate copy before relying on it
Retrieve the file from an independent backup into a new temporary directory without overwriting the original. Compare its SHA-256 with the baseline recorded for the accepted file, then open and check the restored file. Record the location, date, result and any unresolved issue. This tests retrieval rather than merely the existence of a backup entry.
If a hash differs, decoding stops, expected content is missing or restoration fails, keep the source and investigate. If all checks pass, record exactly what passed and retain multiple copies. No single pass authorizes deleting the only remaining original, and today’s verification does not guarantee future storage health.
Start with one recording. A useful result is a file you can identify, decode, use and restore—with the limits of each check written down.