What This Service Covers
Backup archive repair focuses on compressed archive formats that have sustained some form of structural damage, whether that is a corrupted header, a truncated data stream, mismatched checksums, or a missing volume in a multi-part set. The most common formats we work with are ZIP (including ZIP64 for large archives), TAR, TAR.GZ, TAR.BZ2, 7Z, and RAR. We also handle proprietary archive formats produced by specific hosting platforms, cPanel, and cloud storage services, provided sufficient format documentation is available.
It is worth noting what this service does not cover: if a backup archive is encrypted and the password is not available, recovery of the content is not feasible. Similarly, if a backup was generated with a broken or non-standard implementation of the format — some older cPanel versions, for example, produced non-compliant ZIP structures — the diagnostic process will identify this and set appropriate expectations before any further work is undertaken.
How Archive Corruption Presents
Archive corruption manifests in several distinct ways, and the presenting symptom gives some indication of the likely underlying cause:
- CRC mismatch errors typically indicate that the compressed data within one or more entries has been altered after the archive was created. This can happen during file transfer, storage degradation, or write interruption.
- End-of-central-directory errors suggest the archive's internal index — stored at the end of ZIP files — is absent or damaged. This is common in truncated downloads or interrupted write operations.
- Invalid signature errors occur when the magic bytes at the beginning of the file or at an entry boundary have been overwritten or are missing. This can prevent any standard extraction tool from reading the file.
- Unexpected end-of-file errors in TAR archives are almost always the result of truncation — the archive was not completed before the process stopped.
- Split archive errors in multi-volume sets typically indicate that one or more volumes are missing, have been renamed, or are themselves corrupted.
Diagnostic Process
Every archive repair engagement begins with diagnosis, not repair. This is a deliberate approach: attempting to extract or repair a damaged archive using automated tools without first understanding the damage can overwrite recoverable data or produce misleading partial outputs.
Diagnosis begins with raw file examination using a hex editor to locate header structures, identify where corruption begins, and determine whether the internal file directory is present and intact. For ZIP archives, we examine both the local file header records (located at the start of each entry) and the end-of-central-directory record (located at the end of the file). Discrepancies between these two structures are common in truncated or partially-overwritten files.
For TAR archives, we scan the 512-byte header blocks that precede each file entry, checking magic bytes, file sizes, and checksums. For GZ streams embedded in TAR archives, we also verify the GZ header and footer checksums to determine whether decompression is feasible.
Once we have a clear picture of the archive's internal state, we produce a written assessment describing what we found and what recovery options exist. This assessment is provided before any repair work is quoted or commenced.
Repair Methodology
The repair approach depends entirely on the findings of the diagnostic stage. There is no single method that works across all archive formats or all types of corruption. The following describes the approaches we use most frequently:
- Header reconstruction: For archives where the header is missing or partially corrupted, we attempt to reconstruct it from information available elsewhere in the file — either from local file records, embedded metadata, or by comparing against a known-good template for the format in question.
- Directory offset repair: ZIP archives with an incorrect end-of-central-directory offset can often be repaired by recalculating the correct offset from the local header data. This allows standard tools to locate and extract entries without error.
- Raw block extraction: Where the central directory is completely absent, we attempt raw scanning of the file for valid local file header signatures and extract entries directly from those records. This bypasses the central directory entirely and is sometimes the only viable approach for severely damaged ZIP files.
- Truncated archive handling: For TAR archives that are truncated, we extract all entries that are fully contained within the existing data stream. Partially-written final entries are excluded, as they cannot be decompressed reliably.
- Multi-volume reassembly: Where not all volumes in a split set are present, we attempt to identify and extract entries that are wholly contained within the available volumes. Entries spanning a missing volume cannot be recovered.
Verification and Reporting
After recovery, all extracted files are verified for completeness. File sizes are compared against the values recorded in the archive headers. For text-based files such as SQL dumps, configuration files, and HTML files, we perform a structural check to confirm the content is coherent and not simply a decompression of corrupted blocks.
You will receive a written report summarising the archive's condition as found, the recovery approach taken, a list of files recovered, files that could not be recovered, and any recommendations regarding the backup process that contributed to the corruption.