(2.0 alpha, updates & plans)
Thomas Waldmann (@home, 2022-07)
A borg repo is a LOG.
(== stuff only gets appended at the end,
old stuff is never modified [only deleted])
A borg repo is a key/value store.
(key: chunk id = MAC(plaintext), value = ciphertext)
Low-level repo operations:
Segment files
PUT log entry structure:
Big design issue
One can not check the header only.
To check the crc32, one must read ALL: header+content
Slow if one is only interested in header values.
Correct size is important to seek to next entry.
PUT2 log entry structure:
Notable
Can check the header without reading the content.
Better error detection by stronger and super fast xxh64.
crc32 covers header+digest, digest also covers header.
Sometimes slow CRC32 impl. only used for few bytes.
These were initially intended for data migration.
--tar-format=PAX
ctime and atime support, all ts in ns resolution
could support more metadata, like xattrs, ACLs, ...,
but a lot of work to implement and test
--tar-format=BORG
Like PAX plus custom BORG.* PAX headers
for perfect round-tripping
of all borg supported fs item metadata.
Copy archive from repo1 to repo2:
borg export-tar ... repo1::A | borg import-tar ... repo2::A
Problem: no dedup, huge amount of data
borg --repo NEWREPO rcreate --other-repo OLDREPO --encryption CIDH
borg --repo NEWREPO transfer --other-repo OLDREPO [--dry-run]
Contributions are welcome!
Code, documentation, review, testing, funding, ...
Just join us on GitHub and LiberaChat IRC #borgbackup.
Donations please via LiberaPay or BountySource:
https://www.borgbackup.org/support/fund.html
tw @ waldmann-edv . de
Thomas J Waldmann @ twitter