Closed Byolock closed 3 months ago
garethgeorge
commented
3 months ago Hmm, that shouldn't be happening. I'll start by adding a test covering this to see what might be going on.
A few questions: are you indexing snapshots created by another Backrest install? Or are these being created by an external script? (both are supported use cases)
Byolock
commented
3 months ago They are created by another Backrest install.
garethgeorge
commented
3 months ago What version of backrest is running on the other install? Any other info about the setup you can provide? I'm not able to reproduce this either for manually created backups or by resetting my operation log on my test install
Byolock
commented
3 months ago Sorry was about to answer earlier but got a busy week.
Both are running 1.4.0 , the broken one Using systemd with the install script, the working one uses a cronjob.
The one making problems was updated from 0.3 to 1.4 and then downgraded to 1.0 because I forgot you can't update directly. After setting the ID I updated again to 1.4. The other system was also on 0.3 most of the time but got updated way earlier to 1.2 or something like that (also including a downgrade to 1.0 und then upgrading again).
I just noticed another bug I got with that system :
You can see I have got multiple Entrys with "PBS-Backupcloud" and then system and 2024-08-16 below that.Only the last three should exist, all the others are "fake". Im actually able to create these fake entrys, as many as I like. At the top of the screenshot there is the entry "2024-07-03" it is not collapsed but looks empty. Anytime I open or close that entry a new set of "PBS-Backupcloud", system and "2024-08-16" appears. These new entrys can not be opened, If i click on them nothing happens. I guess it may be related.
However If you haven't got a new Idea, I would like to try to do this:
by resetting my operation log
Is there documentation how to do that? If that does not help I think it would be the best to just make a clean reinstall. I have not looked much at the architecture of how backrest works, but I think it has stored corrupted data somewhere locally I need to get rid of? It does not seem to be related to the repository as the other install works just fine with the same repository.
garethgeorge
commented
3 months ago Hey -- yes that looks badly broken. Sorry you're running into this!
Definitely sounds likely that some sort of failed migration / oplog corruption is at play. In particular, the experience of failed updates to 1.4.0 and then having to go through the pre-1.0.0 -> 1.0.0 -> 1.4.0 path is risky and not great. I'll track a task to have backrest refuse to start if it detects a "too old to migrate" storage version, and suggests the last compatible version.
I've been making an effort to ensure I add migrations for each change to the storage schema, but I don't have a good testing story around it at the moment -- which is especially apparent around the 1.0.0 change which was a very significant migration. That's probably something I'll need to think about if I make another significant schema change in the future.
Re: resetting your operation log, that's as easy as removing oplog.bbolt in your data directory. If you're using install.sh that's $HOME/.local/share/backrest/oplog.bbolt by default. Once you've done that, pull up the UI and use Index Snapshots to re-import everything -- just your operation history will be lost.
Byolock
commented
3 months ago Deleting the operation log fixed everything. Thank you for backrest and your help with this issue.
I have two systems, one truenas and one proxmox, which backup using backrest into one S3 repository. I just noticed that the proxmox system fails to read the "created-by" tag from the snapshots created by the truenas.
This is how an example Snapshot looks like using the restic cli :
The same snapshot viewed in backrest from my second (proxmox) system:
I already tried to "Index Snapshots" but this did not change anything.
Screenshots If applicable, add screenshots to help explain your problem.
Platform Info