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.
\nThe 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.
\nThese 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.
\nThe following paragraphs are DSE recommendations, not instructions or guarantees from the source.
\nUse 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.
\nMap 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.
\nPreserve 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.
\nProposed 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.
\nPut 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.
\nSource review completed October 28, 2026. Recheck the official documentation and deployment-specific applicability before a production change.
\n", "content_text": "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.\nSource fact: what the authority says\nThe 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.\nWhat the source does not establish\nThese 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.\nApplicability questions\n\nWhich files, owners and application requirements make metadata fidelity important for this transfer?\nWhich attributes are required, which are irrelevant, and who may accept a documented loss?\nWhat Borg version, tar implementation and destination filesystem will be used in the actual route?\nCan the proposed route be rehearsed without replacing the original archive or overwriting an active service?\n\nDSE recommendation: controlled next steps\nThe following paragraphs are DSE recommendations, not instructions or guarantees from the source.\nUse 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.\nMap 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.\nPreserve 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.\nVerification and evidence\nProposed 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.\nPut 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.\nOfficial references\n\nBorg 1.4.5 — borg import-tar — official product documentation; source version and applicability limits are stated above.\n\nSource review completed October 28, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "content_markdown": "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.\n\n## Source fact: what the authority says\n\nThe [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.\n\n## What the source does not establish\n\nThese 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.\n\n## Applicability questions\n\n- Which files, owners and application requirements make metadata fidelity important for this transfer?\n\n- Which attributes are required, which are irrelevant, and who may accept a documented loss?\n\n- What Borg version, tar implementation and destination filesystem will be used in the actual route?\n\n- Can the proposed route be rehearsed without replacing the original archive or overwriting an active service?\n\n## DSE recommendation: controlled next steps\n\nThe following paragraphs are DSE recommendations, not instructions or guarantees from the source.\n\nUse 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.\n\nMap 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.\n\nPreserve 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.\n\n## Verification and evidence\n\nProposed 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.\n\nPut 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.\n\n## Official references\n\n- [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.\n\nSource review completed October 28, 2026. Recheck the official documentation and deployment-specific applicability before a production change." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/check-metadata-loss-before-using-borg-145-tar-conversion/", "url": "https://update.dsesecurity.com/updates/check-metadata-loss-before-using-borg-145-tar-conversion/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-10-28" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/check-metadata-loss-before-using-borg-145-tar-conversion/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Business Continuity", "item": "https://update.dsesecurity.com/topic/business-continuity/" }, { "@type": "ListItem", "position": 3, "name": "Check metadata loss before using Borg 1.4.5 tar conversion", "item": "https://update.dsesecurity.com/updates/check-metadata-loss-before-using-borg-145-tar-conversion/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/check-metadata-loss-before-using-borg-145-tar-conversion/#article", "identifier": "https://update.dsesecurity.com/updates/check-metadata-loss-before-using-borg-145-tar-conversion/", "url": "https://update.dsesecurity.com/updates/check-metadata-loss-before-using-borg-145-tar-conversion/", "headline": "Check metadata loss before using Borg 1.4.5 tar conversion", "description": "Borg 1.4.5 documents lossy tar conversion; decide which metadata must survive before adopting it as an archive transfer or recovery route.", "abstract": "Borg 1.4.5 documents lossy tar conversion; decide which metadata must survive before adopting it as an archive transfer or recovery route.", "articleBody": "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.\nSource fact: what the authority says\nThe 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.\nWhat the source does not establish\nThese 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.\nApplicability questions\n\nWhich files, owners and application requirements make metadata fidelity important for this transfer?\nWhich attributes are required, which are irrelevant, and who may accept a documented loss?\nWhat Borg version, tar implementation and destination filesystem will be used in the actual route?\nCan the proposed route be rehearsed without replacing the original archive or overwriting an active service?\n\nDSE recommendation: controlled next steps\nThe following paragraphs are DSE recommendations, not instructions or guarantees from the source.\nUse 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.\nMap 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.\nPreserve 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.\nVerification and evidence\nProposed 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.\nPut 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.\nOfficial references\n\nBorg 1.4.5 — borg import-tar — official product documentation; source version and applicability limits are stated above.\n\nSource review completed October 28, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "datePublished": "2026-10-28T23:23:24+00:00", "dateModified": "2026-10-28T23:23:38+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/check-metadata-loss-before-using-borg-145-tar-conversion/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/check-metadata-loss-before-using-borg-145-tar-conversion/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Check metadata loss before using Borg 1.4.5 tar conversion" }, "articleSection": [ "Business Continuity", "IT" ], "keywords": [ "Business Continuity", "IT", "Guide", "Advisory priority" ], "genre": "Guide", "about": [ { "@type": "Thing", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "@type": "Thing", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "wordCount": 522, "timeRequired": "PT3M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "Borg 1.4.5 — borg import-tar", "url": "https://borgbackup.readthedocs.io/en/stable/usage/tar.html" } } ] } }