Hi all. thanks to recommendations on here I have been using Pika Backup to backup my machine (Fedora 42 WS) to a hard drive which I keep in a safe. Today for first time it failed, I’ve attached a screenshot below. I don’t understand the message, grateful if someone could help. thanks
I would assume that that previous backup failed in some way, and left the repo locked. In order to clean this up so successive backups can proceed, you need to remove the lock.
I use restic myself, and that would be a call to
┌─🎩 lurcher ~
├─
└─➜ restic unlock 14:43 Wed 24-Dec
repository 4670fb02 opened (version 2, compression level auto)
I assume Pika Backup has an equivalent command - should be in the man page.
Thanks for the reply but this answer is way over my head. 
I tried quitting and disconnecting, then re-connecting but it failed again immediately so I guess I have to find a way to ‘remove the lock’.
pika is just a front end for borg backup.
Apparently, to unlock a borg backup repo, you can issue borg break-lock /path/to/repository or borg break-lock /mount/point/repository from the command line
1 Like
I also note the black bar with text on the bottom of the screen that indicates the backup location may be filling up.
A quick way to check that would be to mount the device then use df to see the results.
Thanks but could you tell me what ‘repository’ means here, and how i find out the location to put into that command in terminal?
Thanks. I don’t care for incremental backups, just a one time backup will do. So IF it’s a space issue (the stupid message doesn’t display properly and doesn’t expand!) I am happy to reformat the drive and start from scratch, but not certain that will fix it and i’d rather not wipe it if i don’t know I can get a backup soon after.
When pika calls borg to backup your files they are stored in a repository and the name of that repo is whatever you plugged into pika when you set it up.
Mine, for example, is stored on my external drive (/run/media/steve/TOSHIBA EXT/), and the specific repo I’ve created on it for restic backups is named lurcher/restic/. Ergo the full name of the backup location is run/media/steve/TOSHIBA EXT/lurcher/restic/. This is what I’d pass to restic when telling it to perform a backup, or in this case, when I need to unlock it from a failed backup.
If I navigate to this location and see what’s there, I find all the files which contain my plethora of incremental backups. You can probably do the same thing with wherever you’ve actually stored your backups on your external drive.
┌─🎩 lurcher TOSHIBA EXT/lurcher/restic
├─
└─➜ pwd && ls -al 16:17 Wed 24-Dec
/run/media/steve/TOSHIBA EXT/lurcher/restic
Permissions Size User Date Modified Name
drwxrwxrwx@ - steve 2 Nov 2024 .
drwxrwxrwx@ - steve 2 Nov 2024 ..
drwxrwxrwx@ - steve 2 Nov 2024 data
drwxrwxrwx@ - steve 24 Dec 15:00 index
drwxrwxrwx@ - steve 2 Nov 2024 keys
drwxrwxrwx@ - steve 24 Dec 15:00 locks
drwxrwxrwx@ - steve 24 Dec 15:00 snapshots
.rwxrwxrwx@ 155 steve 2 Nov 2024 config
Look at your pika config panel and pull out the name of your backup, and pass this to borg with the unlock command.
Thanks. I have 2 questions.
- I see the ‘path’ - so that’s what I would insert into the command you mentioned earlier? I can do that I think
- I see it says the drive has zero bytes free. Forgive me, but I thought Pika/Borg was pretty clever. Is this seriously just a case of hard drive being full, and it breaks?! My internal SSD is 1TB, so surely it should just overwrite everything with my current data on internal SSD, shouldn’t it? Just trying to work out if this Pika app is limited (in which case I may seek another) or maybe it’s not and I actually did something wrong myself to cause this.
Thanks again for the help
I tried the borg unlock command but got this:
bash: borg: command not found...
Install package 'borgbackup' to provide command 'borg'? [N/y]
Yep - the drive is entirely full, which probably caused the previous backup to fail leaving the repos locked… or the error message is a bit crap/misleading and it’s saying it’s locked because it can’t write to the device as it’s full.
Either way you’ll need to clear some space to continue.
As for the borg command not being found, I suspect that Pika is a flatpak and thus whilst it uses borg internally to actually perform the backup, you’ll have to dig into the flatpak to locate the borg command it’s using (as it’s inside a sandbox). Alternatively, you could just install the borg command as suggested by the error message you posted - it’ll work just as well to unlock the repo if it IS locked… however, I’d be looking to clean up whatever is on that external device as whilst it’s completely full, you’re pretty knackered on doing much with it anyway.
I strongly suspect that borg/pika is performing incremental backups of your data - it’s probably not just saying, “chuck the existing backup away, and perform a full backup of this internal 1TB drive”. It’s probably performing a full backup to start with and then applying incremental backups of only changed data over the top of that baseline. As such, perhaps you can tell Pika to get rid of the oldest backup it has on the device (a “snapshot” is what it would probably be referred to as) which would free up space for this current work to be performed. Maybe setting the expiration of snapshots within Pika might be something to look at, depending on what you have it set to.
Excellent explanation, thanks very much. I’’l have a look if I can delete any ‘snapshots’ or change settings etc, failing that I’ll have to format it again and hold my breath while it backs everything up again!
I just tried the unlock command again after installing Borg. Grateful if you could decipher the error!
borg: error: argument <command>: invalid choice: 'unlock' (choose from benchmark, break-lock, check, compact, config, create, debug, delete, diff, export-tar, extract, help, info, version, init, key, list, mount, prune, recreate, rename, serve, umount, upgrade, with-lock, import-tar)
Should I try break-lock command maybe?
I was just about to reply with “accroding to borg with-lock — Borg - Deduplicating Archiver 1.4.3 documentation, you should be able to use break-lock”
Thanks,. Did that, it seemed to work as the backup tried again, then failed with ‘Local Exception’. I suppose I’ll have to risk wiping the drive.
… Actually I see now, i can see a list of archives which have the option to delete, going right back to Sept 2024. Hooray? Nope! I tried to delete but each time it fails with error :
Delete archive failed: Failed to lock repository.
Dammit! Should I try a lock command before I pull the plug and wipe the entire drive? (Not sure why I should ‘lock’ it to delete something from it?!)
It’s a repo, so it’s just a collection a files on a disk - however they are all inter-related. Some are indexes, some are data, some are metadata. Consider it to be a database, where actions have to follow ACID
With that in mind, a process must lock each part of the “database” as it modifies it. If you were dropping an entire snapshot whilst another backup process were running, the consistency may be broken and when you came to restore your backed up file, you could possibly get a steaming pile of dross back, as you changed stuff as it was being written to. Ergo, a new backup can’t start because the previous one never really completed properly (due to running out of space) and left a lock lying around.
So… before you wipe the entire thing…
- break the lock
- run a borg prune (borg prune — Borg - Deduplicating Archiver 1.4.3 documentation)
- run a borg compact (borg compact — Borg - Deduplicating Archiver 1.4.3 documentation)
- run a borg check (borg check — Borg - Deduplicating Archiver 1.4.3 documentation)
There should be no need to wipe the entire thing - you just need to clean up this little “I think I’m still running as there’s a lock present” followed by a little housekeeping.
I’ve never used borg at all, but all of these backup programs operate in pretty much the same way - if somneone else chimes in who actually has specific borg knowledge, that would be great, but this is a recoverable situation without having to wipe lots of data. These programs make it quite hard to actively lose data unles you really, REALLY try so chill out, have a little read of those links to make sure you know what they do and have a go. The very WORST that can happen is that it’s FUBAR already (or maybe has been for months) and you have to re-initialise the entire repo. DOn’t need to wipe entire disks either - it’s jsut a pile of interconnected files at the end of the day.
Thanks. I’ll read this a few times and work through those links
Ripper - if nothing else Joe, when the shit hits the fan and you NEED something back from that backup, you’ll be more comfortable in getting the right data back out, and you may well find that you don’t need to arse about with pika backup anyway as you’re a dab hand with borg at the command line, like a boss, as my nephew says.
haha. you seriously overestimate me!
I read and used those commands. The compact and check commands fail with similar errors:
Failed to create/acquire the lock ([Errno 28] No space left on device: '/[path]/lock.exclusive.volginms.tmp').
I think it’s time to wipe this disk’s ass