Release 2.0.0a4 - alpha quality, for testing only

[ThomasWaldmann]

borgbackup 2.0.0a4 alpha release - do not use this on production backup repositories.

Long changelog:
https://borgbackup.readthedocs.io/en/2.0.0a4/changes.html#version-2-0-0a4-2022-07-17

If you use pip to install this, use: pip install "borgbackup==2.0.0a4"

Docs: https://borgbackup.readthedocs.io/en/2.0.0a4/

Feedback:

• discussion: ...

---

This discussion was created from the release Release 2.0.0a4 - alpha quality, for testing only.

[ThomasWaldmann]

Guess this is the last alpha release.

#6871 is a known issue maybe some freebsd user/developer can have a look at that.

[ipha]

What is the expected behavior when transferring from 1.2 to a repo created without --other-repo?

Currently it seems like the transfer completes without error, but just leaves inaccessible data in the new repo.

[ThomasWaldmann]

What is the expected behavior when transferring from 1.2 to a repo created /without/ --other-repo?

If you do a borg init without --other-repo, the key and secret material will be random and unique.

This affects usage of this repo in 2 ways:

• chunks will be cut differently for the same files / for the same content, so future backups will not deduplicate with past backups.

• the different key material for the ID MAC key would also compute a different ID for the same chunk contents than in the old repo

If you borg init --other-repo=OLDREPO, it will just re-use the key and secret material from the old repo, so chunk cutting and ID computation works in exactly the same way. This is strongly recommended for better deduplication.

Other applications for having the same key material in multiple new "related" repos:

• redundancy: a lost chunk in one repo could very likely be retrieved from the other repo if both have approximately the same backups.
• one can efficiently transfer archives from one related repo to another related repo (also using borg transfer, but without data conversion)

Currently it seems like the transfer completes without error, but just leaves inaccessible data in the new repo.

You'ld notice the bad dedup (== no dedup) after the first new backup.

[ThomasWaldmann]

What exactly do you mean by "inaccessible data"?

[ThomasWaldmann]

Hmm, guess in that case it might fail in the assert_id call, which I just recently removed because it is not necessary any more considering the AEAD crypto authenticates the contents + the chunkid anyway now.

When not init-ing the repo with --other-repo=OLDREPO it's a bit ugly because chunkid <> ID_MAC(content).

[ipha]

list [transfered archive] works
extract fails with "Data integrity error"
check works
check --verify-data fails with "Data integrity error"

Presumably because the data is encrypted with a different key? Or is transfer supposed to decrypt and re-encrypt?

[ThomasWaldmann]

Guess there were tracebacks with these "Data integrity errors", can you post them?

[ThomasWaldmann]

BTW, if I wrote borg init that shall rather be borg rcreate (for borg2), the subcommand was renamed for better consistency.