# Check metadata loss before using Borg 1.4.5 tar conversion > Borg 1.4.5 documents lossy tar conversion; decide which metadata must survive before adopting it as an archive transfer or recovery route. - Canonical URL: https://update.dsesecurity.com/updates/check-metadata-loss-before-using-borg-145-tar-conversion/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-10-28T23:23:24+00:00 - Modified: 2026-10-28T23:23:38+00:00 - Last reviewed by DSE: 2026-10-28 - Resource type: Guide - DSE priority: Advisory - Topics: Business Continuity, IT - Reading time: 3 minutes ## What you need to know Borg 1.4.5 documents lossy tar conversion; decide which metadata must survive before adopting it as an archive transfer or recovery route. ## Potentially affected Review scope: Borg 1.4.5 import-tar and export-tar; Borg 2 behavior and destination tar implementations are outside this draft. ## DSE recommendation DSE recommends an explicit metadata acceptance matrix and a disposable round-trip rehearsal before approving a tar interchange route. ## Article Bottom line: DSE recommendation: approve an archive interchange route against the metadata the workload needs, rather than the appearance of a familiar tar filename. Write down which properties must survive and which losses the data owner is prepared to accept before transferring valuable archives. ## Source fact: what the authority says The [Borg 1.4.5 tar reference](https://borgbackup.readthedocs.io/en/stable/usage/tar.html) says export-tar uses GNU tar format. It describes conversion as lossy: BSD flags, ACLs, extended attributes, atime and ctime are omitted. Timestamp resolution is limited to whole seconds rather than the nanosecond resolution otherwise supported by Borg. ## What the source does not establish These statements do not establish a lossless migration, a usable application restore or the behavior of Borg 2. They also do not certify the receiving filesystem or tar program. This article concerns the documented representation boundary; it is not an instruction to repair, recreate or delete an existing archive. ## Applicability questions - Which files, owners and application requirements make metadata fidelity important for this transfer? - Which attributes are required, which are irrelevant, and who may accept a documented loss? - What Borg version, tar implementation and destination filesystem will be used in the actual route? - Can the proposed route be rehearsed without replacing the original archive or overwriting an active service? ## DSE recommendation: controlled next steps The following paragraphs are DSE recommendations, not instructions or guarantees from the source. Use a hypothetical requirement, not an invented customer case: the owner wants a test file’s access-control list, a named extended attribute and subsecond modification time to survive the transfer. Ask the owner to mark each property as mandatory or optional before selecting the route. Define the observation method for each property. Map those three requirements against the documented export-tar limits above. If they are mandatory, record the conflict rather than accepting an interchange command as permission to disregard them. Ask the owner either to accept a specifically documented loss or assess another route using its own primary documentation and applicability limits. Preserve the original archive while the alternative is assessed. Keep the source archive, proposed destination, tool versions and exact acceptance properties together. Separate permission to create a test export from permission to retire an existing recovery copy. Stop when a required property cannot be evaluated with the available evidence. ## Verification and evidence Proposed verification, not a performed test: prepare disposable files carrying the agreed ACL, extended attribute and timestamp precision, using approved platform tools. Record their actual starting values. Rehearse the proposed Borg 1.4.5 export-tar route in an approved destination, then inspect the same properties after extraction. Do not report the documented losses as if they were measured test output. Put the starting and observed values beside each mandatory or optional requirement. Retain the exact tools, invocations and archive identifiers so a second reviewer can reproduce the comparison. Have the owner decide whether each difference is acceptable or requires a different documented route. Assess representative application access separately and preserve the original until the approved disposition decision. ## Official references - [Borg 1.4.5 — borg import-tar](https://borgbackup.readthedocs.io/en/stable/usage/tar.html) — official product documentation; source version and applicability limits are stated above. Source review completed October 28, 2026. Recheck the official documentation and deployment-specific applicability before a production change. ## Primary reference - Name: Borg 1.4.5 — borg import-tar - Authority: borgbackup.readthedocs.io - URL: https://borgbackup.readthedocs.io/en/stable/usage/tar.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Check metadata loss before using Borg 1.4.5 tar conversion,” DSE Security, https://update.dsesecurity.com/updates/check-metadata-loss-before-using-borg-145-tar-conversion/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved.