Ask the Community
Groups
Corrupt header causes restore to abort with ..Directory not in proper format. - Connect IT Community | Kaseya
<main> <article class="userContent"> <h2 data-id="summary"><strong>SUMMARY</strong></h2> <p>Corrupt header causes restore to abort with ..Directory no in proper format.</p> <h2 data-id="issue"><strong>ISSUE</strong></h2> <p></p> <h3 data-id="purpose">Purpose</h3> <p>This <strong>article</strong> is to provide information why a restore may be incomplete due to a corrupt header.</p> <h3 data-id="symptoms">Symptoms</h3> <p>The restore receives a success. But after further investigation, it is found that only a few files were restored.</p> <p>Restore logs show the following:...<span style="font-size: medium;"><strong>Directory not in proper format Length.</strong></span>..</p> <h3 data-id="resolution">Resolution</h3> <p>There is unfortunately no resolution. However, to prevent backups with bad headers, you may want to use inline verification.</p> <p>The developers notes are listed below. Also, if you want to verify that the files currently on the client are not corrupt, you</p> <p>can do a quick backup and verify it with the additional instructions below.</p> <p><br>Developer's Notes:</p> <p>“ One factor here is the type of verification used when the job is run. Both<br>file-level and bit-level verification check whether the backup received by the<br>DPU match what was sent by the agent.<br><br>Inline verification adds an additional level of checking, where it ensures that<br>the backup file is not malformed with respect to the file headers within the<br>backup, as well as their sizes and locations. It essentially makes sure that<br>the files are restorable, and is better at identifying this type of corruption<br>than the other methods.”<br><br>To VERIFY YOUR BACKUP:</p> <p>We have a tool that will read through the backup and print each CTAR file header as well as the file sizes and offsets. If that tool finds a bad header, it’ll print the message “Not a Tar header!!”, and we can use this information to figure out what went wrong. Typically, the problems are:<br><br>a. Bad CTAR header checksum (so the current header is bad)<br>b. Bad file size/offset in the prior header (so the current offset isn’t even a CTAR header; we’re “lost” in the file)<br><br>To run this on a backup on our DPU, sending the output to a file for later analysis, you can do this:<br><br>/usr/bp/bin/fileDedup -R<backup #> | /usr/bp/bin/scantar - > /tmp/scantar.out<br><br>Then, you can ship /tmp/scantar.out somewhere or just look at it in-place, specifically searching for the “Not a Tar header!!” message that will tell us where the problems are.”</p> </article> </main>