Check metadata loss before using Borg 1.4.5 tar conversion

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 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 — 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.