search

borgbase / vorta

Desktop Backup Client for Borg Backup
https://vorta.borgbase.com
GNU General Public License v3.0
1.99k stars 132 forks source link

Update to borg 1.2.7+ and add automatic migration steps #1794

Open MartinX3 opened 1 year ago

MartinX3 commented 1 year ago

See https://github.com/borgbackup/borg/blob/1.2.6/docs/changes.rst#pre-125-archives-spoofing-vulnerability-cve-2023-36811

Or add a warning on first Vorta startup preventing a borg check without following them.

m3nu commented 1 year ago

Our release cycle isn't fast enough to address this ad-hoc. And many users will not run 1.2.6 yet. So Vorta may not be the right place to address this. We only aim to cover the most frequent commands and not 100%.

MartinX3 commented 1 year ago

But doesn't Vorta run periodic checks on the repo by default? This could kill the backups if I read the warning correctly.

It's about 1.2.6 on the client and >=1.2.4 on the server.

And these steps need to be done with the 1.2.6 client. Step 3 is impossible with 1.2.4. (And 1.2.5 needs to be avoided because of a breaking bug)

real-yfprojects commented 1 year ago

Vorta doesnbt upgrade borg. Consequently the user is responsible with following the proper upgrade steps. However we do provide a flatpak and homebrew package with bundled borg. Upgrading borg in those needs special attention.

MartinX3 commented 1 year ago

Oh, I am sorry. I just saw 1.2.4 as the borg version in vorta so I thought it was bundled. But all I need to do was to restart vorta.

real-yfprojects commented 1 year ago

Oh, I am sorry. I just saw 1.2.4 as the borg version in vorta so I thought it was bundled. But all I need to do was to restart vorta.

Yeah, the version is only checked on restart. Checking the version regularly while running wouldn't make much sense, would it.

MartinX3 commented 1 year ago

Hmmm, maybe vorta should execute the tam-signature check first before the regular borg check and give us a warning dialog which steps we should do by ourselves and before it is done denying any more borg check. Just to avoid data loss. If the repo has no problems a flag could be set showing vorta that the repo is save and prevent any further tam-signature checks.

real-yfprojects commented 1 year ago

How should Vorta know that you updated your borg version? Running the check every time Vorta starts, doesn't seem viable to me.

Hofer-Julian commented 8 months ago

For the flatpak, I keep borg pinned to 1.24 at the moment: https://github.com/flathub/com.borgbase.Vorta/blob/a08e83a9da5c34c5040d59b9b316c16c007f72b8/dependencies/borgbackup.json#L10

I assume this is still the way to go until this (or a similar) feature is implemented?

sten0 commented 8 months ago

This will affect a couple thousand users as soon as this April, when Ubuntu 22.04 is released with Borg 1.2.7, and it already affects Ubuntu 23.10 users. Yes, Debian testing or unstable users are also currently affected. It is not possible for affected users to downgrade Borg.

If "borg check" will cause data loss for some cases, then these cases should be handled so as not to cause data loss. Trust in backup software is like trust in a file system: people don't give second chances. It is better for backup software to say "sorry, you're using an unsupported version of borg" than to cause data loss. GUI users may need a borg repo upgrade wizard function to navigate this sort of issue.

real-yfprojects commented 7 months ago

@ThomasWaldmann Is there a way to determine the borg version that was last used to access a repo? Or any other way of determining that the upgrade steps in question are needed?

ThomasWaldmann commented 7 months ago
m3nu commented 7 months ago

I could add a "TAM Upgrade" button and command fairly quickly together with a link for more details. Or we only watch the logs for the relevant error and display an alert with a link for more details.

OTOH, the macOS release has included a newer Borg version since last year and I don't recall getting many questions. Also not to our support. We pointed the issue out twice in the monthly BorgBase newsletter. So it's possible this doesn't affect as many users? I believe I only had to upgrade one of my repos, which was missing the TAM for one archive only. So this case may be the most common?

If there are no tam:none archives left at this point, you can skip this step.

ramcq commented 6 months ago

I found this ticket as I use the Vorta Flatpak - I am intermittently encountering https://github.com/borgbackup/borg/issues/6687 so I was looking if I could update the Flatpak to 1.2.7 which led me here. I think Vorta could potentially aid the migration by tracking, per archive, a boolean indicating whether the migration has been carried out - for existing archives where this flag is false, it could automatically check TAM validity and flip it to true, which seems to be a common case. If the TAM is not valid it can notify the user with a warning / link to the advisory and an explicit step to do the upgrade. Once an archive has been migrated, or if it was newly created, it should simply enforce that the TAM is valid and not offer the migration path - this would avoid Vorta ever allowing the migration to be carried out more than once and any TAM invalidity can then be reported with the appropriate severity to the user.

hozza commented 6 months ago

I've run into this issue after doing an initial backup (to borgbase) with flatpak Vorta (using bundled borg 1.2.4).

I get errors when attempting to setup automated regular backups using borgmatic-collective/docker-borgmatic docker container.

It turns out the docker-borgmatic container uses borg 1.2.7, thankfully I was using an append-only ssh key so helpfully no data loss from the check run (although I'm not sure on that?). I'll disable auto backups with this until Vorta implements a "fix/upgrade repo" option or updates the bundled borg I guess?

(I use Vorta manually with a privileged ssh key on a trusted device for repo prune/management, and an append only ssh key on the actual backup client device in case of it being compromised and attempting to destroy it's own backups for ransom or whatever.)

Is this something that Borgbase should alert users about on the dashboard/by email?

_This self corrupting version issue feels a little like Captin Janeway realising a nanovirus into the central plexus of a class-4 tactical cube. 🦾_

ThomasWaldmann commented 6 months ago

@hozza The steps you should do for your repo are described at the top of the borg 1.2.7 changelog. You could just copy&paste and slightly modify these for your repo URL.

https://borgbackup.readthedocs.io/en/1.2.7/changes.html

Guess nothing bad happens, if you don't run borg check --repair until then with borg > 1.2.4.

ThomasWaldmann commented 6 months ago

I had some time and added some helper commands to simplify the upgrade steps.

I would appreciate some review and practical testing of https://github.com/borgbackup/borg/pull/8159 .

The new commands are for checking whether something needs to be done and exit with rc=0 if all looks OK and rc=1 if something TAM-related needs fixing.

Of course these new commands will only be available with borg >= 1.2.8.

github-actions[bot] commented 3 months ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

sten0 commented 3 months ago

Belated thank you @ThomasWaldmann. How is the testing going?

github-actions[bot] commented 1 week ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

ThomasWaldmann commented 1 week ago

.

m3nu commented 1 week ago

We can keep this open. But I've seen very few people with this problem and I don't feel too good about scripting this and ignoring potential edge cases. And it's one-off so the code will be redundant at some point.