restic: unable to create lock in backend: repository is already locked

Output of `restic version`

restic 0.8.0
compiled with go1.9 on linux/amd64

How did you run restic exactly?

restic -r /path/to/repository/external/drive backup "/path/to/source"
# crash after errors
restic -r /path/to/repository/external/drive backup "/path/to/source"
# success
restic -r /path/to/repository/external/drive check
# unable to create lock
restic -r /path/to/repository/external/drive check --no-lock
# Fatal: repository contains errors

What backend/server/service did you use to store the repository?

local to an external usb drive

Expected behavior

Restic to have error handling and correct previous backup. After new successfully backup, no message of “unable to create lock in backend: repository is already locked by PID…” A way to repair errors output by check --no-lock

Actual behavior

“unable to create lock in backend: repository is already locked by PID 11327”
“Fatal: repository contains errors”

Steps to reproduce the behavior

I ran a backup with:

restic -r /path/to/repository/external/drive backup "/path/to/source"

The backup failed (external drive seemed to be disconnected), so I ran the same command again, then it finished without errors. Now when I check the repository I get: “unable to create lock in backend: repository is already locked by PID 11327” There is no PID 11327 according to ps aux | grep 11327

restic -r /path/to/repository/external/drive check

If running check --no-lock there are some not referenced in any indexentries and Fatal: repository contains errors

restic -r /path/to/repository/external/drive check --no-lock

When I run

restic -r /path/to/repository/external/drive prune
restic -r /path/to/repository/external/drive rebuild-index

Both commands output “unable to create lock in backend: repository is already locked by PID 11327”

Do you have any idea what may have caused this?

Errors when first run backup?

Do you have an idea how to solve the issue?

About this issue

Original URL
State: closed
Created 7 years ago
Comments: 19 (6 by maintainers)

Commits related to this issue

https://github.com/restic/restic/issues/1450 — committed to bananocraft/bananocraft-deploy by satoshinnakamoto 2 years ago
https://github.com/restic/restic/issues/1450 — committed to bananocraft/bananocraft-deploy by satoshinnakamoto 2 years ago

Most upvoted comments

prune took care of remain “not referenced in any index” when check. To sum up:

restic -r /path/to/repository/external/drive unlock
# release previous lock
restic -r /path/to/repository/external/drive check
# Return some "not referenced in any index"
restic -r /path/to/repository/external/drive rebuild-index
# rebuild index 
restic -r /path/to/repository/external/drive check
# return a few  "not referenced in any index"
restic -r /path/to/repository/external/drive prune
# remove those few incomplete packs
restic -r /path/to/repository/external/drive check
# no errors were found

+37

jobcespedes on Nov 28, 2017

Hi,

I didn’t know about unlock. After using it, I could run check, rebuild-index and prune. Maybe it is a good idea to have it in the doc. I still don’t know how to proceed with check errors. Should I forget the snapshot and run a backup again (150GB)?

When I run rebuild-index I still get errors when check

enter password for repository: 
password is correct
create exclusive lock for repository
load indexes
check all packs
pack 15e08d547c2e7c08f68500a8a9b1a9a19d56af4e5b1495a085fc0c7fa90e89bc: not referenced in any index
pack 3f500081f7b1d065db2c62c4326d4b2e2f7ad784761cf04dfa6b1b50d28fdc8e: not referenced in any index
pack 7c2e9c4cd4d0650b103e033f3b46a23d5ba3622b80ce5cce099e891ce00a3fb8: not referenced in any index
pack 7c5f29c0a52e365bb04501ed979df8affce55e39a417e80425af7d17a37fc7ba: not referenced in any index
pack d67fe6313fb94a299984afd54b4eaacdd49e2d58ddbc38a05619b7289f17df1b: not referenced in any index
pack edb04c119017a7aee442221dd8dc6ab5348f26a06dea1efdbb5491258e50d29f: not referenced in any index
check snapshots, trees and blobs
Fatal: repository contains errors

jobcespedes on Nov 28, 2017

restic -r /path/to/repository/external/drive unlock restic -r /path/to/repository/external/drive rebuild-index restic -r /path/to/repository/external/drive prune restic -r /path/to/repository/external/drive check

Worked for me, however I have no idea how is it possible that a process locked that repo without unlocking it afterwards, because I didn’t interrupt restic or anything :

I made a backup, everything went fine
I ran check and it was ok, I then safely unmounted the drive and did something else
A few hours later my RAM decided to die which triggered nasty kernel panic. When I finally found out that was the issue, I replaced the RAM and everything went back to normal
When I tried to make a new backup a few hours later I got this issue of lock over the repo and applied above workaround which worked

I am sure of that because my RAM issue (totally unrelated to restic of course) happened something like 7-9 hours after the previous successfull backup, so I have no doubt that no call to restic has been made in the meantime, no upgrade of the pacman package neither, no cronjob nor external drive being plugged-in…

Is that possible that when calling backup command, restic might lock, “forget to unlock”, and then try to lock again ? Which would explain how you can get a lonely lock without having interrupted restic beforehand.

SasquatchYuja on Jan 14, 2020