# Failed: Invalid header marker

**URL:** https://forum.duplicati.com/t/failed-invalid-header-marker/2871
**Category:** Support
**Created:** [March 12, 2018, 3:32pm UTC](https://forum.duplicati.com/t/failed-invalid-header-marker/2871 "2018-03-12T15:32:32Z")
**Posts on this page:** 1
**Showing post:** 30

<div class="post-metadata">

### Author: ![ts678](https://forum.duplicati.com/letter_avatar_proxy/v4/letter/t/8491ac/32.png) [@ts678](https://forum.duplicati.com/u/ts678)
#### Post date: [November 21, 2019, 3:21pm UTC](https://forum.duplicati.com/t/failed-invalid-header-marker/2871/30 "2019-11-21T15:21:11Z")

</div>

> [@herbert](#):
>
> I do not really get which command I should use with grep

> [@herbert](#):
>
> hexdump -C duplicati-bd742daac0957402f81e85c35a5be6662.dblock.zip.aes | head

on the three known broken files becomes

```plaintext
hexdump -C duplicati-bd742daac0957402f81e85c35a5be6662.dblock.zip.aes | grep '00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00'

```

and you look to see if there are several runs of those NULs. Repeated lines of the same data show as `*`, however just searching for that might find repetitions of something else (which would be informative too).

If you have man pages installed, just type `man hexdump` if that’s easier than following the link I provided.

> [@herbert](#):
>
> especially if I need to check all my files

This is a closer look at files you already identified.

> [@herbert](#):
>
> I would need to run that in a loop.

The `find` command is the loop in the original test. The left side does search, and right side does action. You could probably adapt it to scan for runs of NULs if you wanted, but my plan was a study, not survey. Survey would be done using the verification file. If need be, we can invent another survey, but let’s wait.

> [@herbert](#):
>
> I assume also this is going take some time, especially for 1,6TB and 24020 files in it

What will take time is the duplicati-verification.json run, as it needs to read all of the files The good part about that is it’s very thorough, and will even find things like unreadable files due to low-level problems.

The affected command should be faster because it just looks in the database info. Duplicati has to keep track of what dblock files have pieces of what source files in order to do restore, so this test just looks in the other direction, starting with a dblock file, and then looking to see what source files have blocks in it.

[Disaster Recovery](https://duplicati.readthedocs.io/en/latest/08-disaster-recovery/) has a lab example of recovery from intentionally corrupting a backup. Some of that’s possibly applicable after you find how much was affected and whether it’s important or not so important.

[How the backup process works](https://duplicati.readthedocs.io/en/latest/appendix-a-how-the-backup-process-works/)  
[How the restore process works](https://duplicati.readthedocs.io/en/latest/appendix-b-how-the-restore-process-works/)  
can give some background info.

---

_[View the full topic](https://forum.duplicati.com/t/failed-invalid-header-marker/2871)._