I have searched but not seen related answer.

While gone traveling for 3 months my AWS account was blocked for non-payment.

Paid up and now reinstated the account.

But tklbam showing an error on my server.

> tklbam-backup
error: a previous backup is still in progress

I've waited 2 days now but nothings changed.

It seems like some kind of glitch occured when the S3 account was shut off.

The last backup showing in the hub is on 6th July.

Anyone any ideas?

Also, I've added a new tkl server to my newly reinstated AWS and thats backing up fine.

Any advise much appreciated,


Jeremy Davis's picture

Use the Hub feedback (blue button on left) to contact the devs. I suspect they'll have to do something from behind the scenes...

Hi Jeremy and thanks for pointing me where to go.

I left a message through the feedback button as you suggusted and also through an email a few days later but no responce.

I'm sorry but just a very cautious guy and afraid to touch anything case i loose everything.

I hate asking stupid questions but could you tell me if a simple reboot will safely disconnect the frozen "previous backup is still in progress" and allow me to make a new backup.

Thanks again

Jeremy Davis's picture

Normally they are pretty responsive. I suspect that they are working through a backlog of emails....

Just under a lot  of pressure from a client to make some changes.

Feel he's getting worried I'm taking so long.

But afraid to proceed without backups working again.

Alon Swartz's picture

Sorry for the terribly late reply. I just grepped TKLBAM's sourcecode for the error you mentioned:

lock = PidLock("/var/run/tklbam-backup.pid", nonblock=True)
except lock.Locked:
    fatal("a previous backup is still in progress")

I've personally never come across this, so here's some advice I can offer:

  • Get the pid per the lockfile (cat /var/run/tklbam-backup.pid)
  • Check if the process is still running (ps -A |grep $pid)
    • If it is not running, then you should be able to just delete the lockfile.
    • If it is running though, then you should kill the process (kill -9 $pid), then delete the lockfile.

If you have any issues, or aren't sure of anything, please post back.

Just made a new full backup :).

Did what you said

Found pid using                                       cat /var/run/tklbam-backup.pid

Checked if the process was running with      ps -A |grep 20396

Killed the process with                              kill -9 20396


I didn't delete any lockfile as not sure where it was.

i think the lockfile is here /var/lib/dpkg/lock.

I just launched a backup from webmin and it worked.

Do I need to delete lockfile??


Again, many, many thanks

Alon Swartz's picture

When I said lockfile I was referring to /var/run/tklbam-backup.pid - but it seems you don't need to manually delete it. Glad you're up and running again...

Bjørn Otto Vasbotten's picture

The 'cat /var/run/tklbam-backup.pid' command was very useful.


After that i could simply login to and find the process from there and kill it

L. Arnold's picture

Found pid using                                       cat /var/run/tklbam-backup.pid
Checked if the process was running with      ps -A |grep 20396
Killed the process with                              kill -9 20396

My number was 20928 rather than 20396

Worked like a charm.

L. Arnold's picture

Right now I have a Magento backup going with a huge set of Session Cookies being backed up.  I've been waiting half an hour now to plow through them.  Expect that rebooting the server would leave a Backup in progress marker, perhaps and need to be cleared.

Alternatively killing the process, killing the backup, clearing the sessions folder and starting over without restarting....  Just saying.

I really need to just exclude the Sessions folder from Backups though.

L. Arnold's picture

After an hour an a half, TKLBAM thought it was done, but the Hub said 0kb for backup size.

Deleted the backup

rm  -r session (in the magento/var folder

then went to run backup.  Got the error above (that a backup is still running)

ran the 3 steps outlined directly above to kill it

restarted the backup...  running now.  Hopefully will finish.  Sessions seem to generate like flies.  I should realistically stop Apache if I want to be most precise.


Add new comment