borg create without following 1.2 upgrade recommendations

Woi commented 1 year ago

Have you checked borgbackup docs, FAQ, and open GitHub issues?

Yes

Is this a BUG / ISSUE report or a QUESTION?

Question

System information. For client/server mode post info for both machines.

Your borg version (borg -V).

1.1.17 and 1.2.x

Operating system (distribution) and version.

Fedora 35 and 36

Hardware / network configuration, and filesystems used.

Various

How much data is handled by borg?

Various

Full borg commandline that lead to the problem (leave away excludes and passwords)

borg create

Describe the problem you're observing.

Before upgrading my Fedora boxes, I usually do backups using borg from the distribution repositories. So I did backups using borg 1.1.17, upgraded Fedora and got borg 1.2.x without noticing it. About half a year later I did a backup again using the existing borg repos. This time with borg 1.2.x. Borg create seemed fine, but investigating/checking my freshly created backup took way longer then expected. After some research I found the update and compatibility notes https://github.com/borgbackup/borg/blob/1.2.3/docs/changes.rst#version-123-2022-12-24

Is there any advise what to in this situation? I know, I can use borg releases from github, so this is only about the borg side of things. Ideas that come to my mind are:

Just use borg 1.2.x to follow the advice
Use borg 1.1.x on the existing 1.2.x backups to follow the advice. Then continue with borg 1.2.x
Delete all 1.2.x backups, then follow the advice
Something else

Also, I like to suggest to add a warning to future major releases about such informations. Something like: "The given borg repository was created using an old major release of borg. Some migrations steps are recommended before using this version with existing borg repositories. See [link to documentation] for further details."

Woi commented 1 year ago

Relates to #6217

ThomasWaldmann commented 1 year ago

The upgrade notes describe a very cautious upgrade path that is good to make sure that no pre-existing issues get reported as "borg 1.2" issues just because they were noticed at or after upgrade time.

Usually one can mix borg 1.1 and 1.2 without running into issues.

You can run borg check and borg check --repair with the latest borg 1.2.x version if you want to make sure your repos are ok.

borg2 (which is the first breaking release of borg) will not "just work" with borg1 repos, so at that time, you'll have to read the upgrade notes.

Woi commented 1 year ago

Thanks for the quick replay. Your advice worked without problems.

What do you think about adding the version string of the used borg create to archives? At least it would be a nice-to-know that does no harm. But it could be useful for debugging or used for information and warning messages in the future.

ThomasWaldmann commented 1 year ago

Misc. data structures have internal version numbers, but they are usually not displayed (and have been the same since long). Guess the first time they will really change is with borg 2.

Woi commented 1 year ago

Is there a way to show it? And if it's the same for long, how would this help to figure out which version of borg was used to create an archive?

ThomasWaldmann commented 1 year ago

It doesn't matter much yet. No, the internal version numbers of datastructures are not shown on the UI.

It will start to matter with borg2 and then it'll tell you if you are using it wrong.

Woi commented 1 year ago

I'm not sure if you get me right. I thought about something like this:

$ borg --version
borg 1.2.3
$ 
$ borg info /path/to/repo::2021-07-14T11:00-srv
Archive name: 2021-07-14T11:00-srv
Archive fingerprint: b2f1beac2bd553b34e06358afa45a3c1689320d39163890c5bbbd49125f00fe5
Comment:
Hostname: myhostname
Username: root
Version: 1.1.17

If you still don't see any value the last line of output, feel free to close this issue.

ThomasWaldmann commented 1 year ago

You can read an archive from 1.1.17 also with other 1.1 versions as well as with 1.2. So having that information there is usually not useful.

There might be one exception: if a specific version had bad bugs, then it might be worth knowing which archive has been created by which version. We didn't have that case yet for archives though.

borgbackup / borg