Release 2.0.0b6, beta quality, for testing only

[ThomasWaldmann]

borgbackup 2.0.0b6 beta release - do not use this on production backup repositories.

Long changelog:
https://borgbackup.readthedocs.io/en/2.0.0b6/changes.html#version-2-0-0b6-2023-06-11

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

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

Feedback:

---

This discussion was created from the release Release 2.0.0b6, beta quality, for testing only.

[goebbe]

I know, I know, this is nothing new to the 2.0.0.b6 release, and this is more a detail than a game changer - but anyway...

While I like short command in general, I also dislike when important information is cut down to one letter. :-)
I stumbled about this, reading the following in the changelog:
borg 2 repo commands:
borg rcreate # “repo create”, was: borg init
borg rlist # “repo list”
borg rinfo # “repo info”
borg rdelete # “repo delete”

I would prefer "repo" instead of "r" in these commands. Something like:
borg repocreate
borg repolist
borg repoinfo
borg repodelete

I believe that the additional letters would be well invested, here. Easier to remember, more explicit, less error-prone.
Just my 2cts

On the other side, as a home user, i hardly ever use repo commands. :-)
Thank you very much for your work on borg backup!

[ThomasWaldmann]

No strong feelings here for the one or the other, so let's collect some opinions from other users:

• thumbs up on previous post for "repo..." commands
• thumbs down on previous post for "r..." commands
• smiley on previous post for "no preferences"

[Deric-W]

I'am currently type hinting the crypto package and noticed that hashes for file integrity are stored as str (hexdigest) and not as bytes (digest), doubling the size.
Would it be acceptable at this point in time if I change the integrity format to store them as bytes if possible?

[ThomasWaldmann]

Can you give a git tag, file and line number?

[Deric-W]

borg/src/borg/crypto/file_integrity.py

Line 190 in a5c4d0d

digest = self.hasher.hexdigest()

[ThomasWaldmann]

self.digests is later fed into json.dumps - guess that's why it is a str and not binary bytes.

this stuff is used e.g. for some index files, so using some bytes more per entry does only add a negligible amount to memory usage of borg.

[dietmargoldbeck]

borg 2.0.0b6 is running fine so far for my backups in "production" to another USB disk. All test restores worked fine so far.
What did not seem to work is borg check:

beta 6 has a problem with flushing buffers. borg check does not output anything:
`root@felsenpinguin:~# borg-2 check -v -p

`And much later all percentages come at once, when it starts archive checking.

The putput of create -v -p is also a bit strange. It overwrites the statistics line like previous versions but leaves some lines on cache transactions. The terminal looks like this on my debian system:

`dietmar@felsenpinguin:~$ borg-2 create -v -p felsenpinguin.dietmar.20230630_0456 /home/dietmar
Creating archive at "ssh://zwergpinguin-zfs/backup-tosh0gzt/borgtest/repos/home-dietmar"
Initializing cache transaction: Reading config
Initializing cache transaction: Reading chunks
Initializing cache transaction: Reading files

Saving files cache
Saving chunks cache
Saving cache config

dietmar@felsenpinguin:~$ borg-2 -V
borg-2 2.0.0b6

`

[ThomasWaldmann]

The remote log/progress messages being held back (in the queue) is already fixed in master.

In general, the progress stuff had to be simplified a bit to work with the new way how this is remoted.

[git70]

borg repocreate
borg repolist
borg repoinfo
borg repodelete

If I may vote, I personally prefer this record :)
It is more unambiguous and obvious. When I first came in contact with rcreate I had to search for what it means if it will repocreate you can guess.

But to be honest I'd rather stick with repoinit ;)
Because:

1. I "already have" a repository (I don't create it), but I initialize it
2. The power of getting used to the init word from previous 1.x versions

[git70]

I don't know if this is the place to report observations and bugs (or is it better to open a regular issue):

Attempting to use the --list and --progress options together fails with borg: error: Options --progress and --list do not play nicely together.
For version 1.2.4 it works fine.

[infectormp]

using --list together with --progress is now disallowed (except with --log-json), #7219

[git70]

Okay, sorry for the false alarm!
I did a quick github search but couldn't find the phrase "--list --progress" so I thought it was a new beta issue...

[madfusker]

I have borg installed as a qpkg on my QNAP NAS and it's doing regular backups in production. I'd like to start testing borg-2 and get used to the new syntax, but I am wondering if I can pip install borg-2 and have them work side by side. So borg-1.2.4 for my production, and borg2 for testing to another "testing repo"? Is it possible for both versions to exist on the same system given the executable looks like it's "borg-2"?

[ThomasWaldmann]

There are no special provisions in the borg git code or borg pypi packages to run borg 1 and 2 in parallel (both use borg as the name for the command, both use borg as the python package name).

So you will need to use e.g. python virtualenv / venv (and maybe symlink to borg1 and/or borg2 for the cli commands) to keep them apart.

You could also use the fat binaries we provide for intel/amd or build such for other platforms.

[madfusker]

Great! I'll look at the fat bins first as that's the easiest. Otherwise I'll just spin up a VM for testing. Thanks a lot for the quick answer, and MANY MANY thanks for all your work on borg!