Nelson Hoover's picture

I've installed the fileserver appliance (13.0) to a server and am trying to do a backup to a locally mounted file location. I have the API entered and tklbam seemed to initialize OK.

When I run:

tklbam-backup --address file:///mnt/tklbam/backup

I promptly get this:

Traceback (most recent call last):
  File "/usr/bin/tklbam-backup", line 452, in <module>
  File "/usr/bin/tklbam-backup", line 351, in main
    backup_id = registry.hbr.backup_id
AttributeError: 'NoneType' object has no attribute 'backup_id'

What am I doing wrong?

Thanks in advance for any ideas or help.


Nelson Hoover's picture


Today I decided to make a valiant attempt at trying to figure out what/where the problem is by going through the source code and trying to figure out what it's trying to do when it crashes.

I opened the file mentioned in the exception message, looked around a bit, closed it without saving, then ran the backup command again because I wanted to see again which line it was crashing on. This time it worked! I'm pretty sure nothing changed on my server that would have made any difference.

Anyway, I guess the problem is gone now.

Liraz Siri's picture

From the other report it looks like something you did as part of the investigation (e.g., change the timestamp on the file) actually fixed whatever the problem was. In which case, it should be an easy fix. I need more information though to fix this.

Tony Goodwin's picture

Being trying to understand the problem for about a week. And then I see your post.

Simple vi and save. - Problem gone away for now at least



Liraz Siri's picture

It sounds like you touched the file, which would have changed the timestamp, which might have helped somehow though I can't tell how yet because I don't know how to replicate this so I haven't isolated what the issue is. If we can corner this beast I promise to slay it.

Nelson Hoover's picture

/usr/bin/tklbam-backup  in nano. I can't remember, but unlike the comment just after mine, I'm pretty sure I hadn't even saved it when I closed it.

Not sure if it was coincidence with something else or why that made any difference. I hadn't been tweaking anything else at all.

Liraz Siri's picture

Just reading that file (or even touching it) couldn't have changed anything. So this was probably just a coincidence.

Nelson Hoover's picture

I can't see any sane reason it would make a difference. Funny it seems to have worked for Tony too though.

If I have time, I may try to recreate the problem and see if I can get any more info for you.

Tony Goodwin's picture

Just to note that I have a few VMs trying to setup, and problem has returned.

as with other user, editing /usr/bin/tklbam-backup

wonder if anything to do with system time as I'm having a nightmare getting it to work properly. Working in BST

(though think issue is to do with vmware tools updating time and not debian - have to wait until later to restart the VMs to see if thats the issue though)





Nelson Hoover's picture

Mine's on bare metal, FWIW.

Tony Goodwin's picture

Add in my observations

Yes I did edit/save the script tklbam-backup

And would concur - highly unlikely to have an effect.

Indeed while the script editing was going on, I was also trying to sort the system time out with the VM.

Subsequent test backups while this was in progress also produced the above error among others relating to system time and server time being too far out of sync for S3.

So finally I found the solution to the system time problem (casued by VMware tools resetting the time every few minutes). So in my estimation I was getting lucky as the save(s) that suceeded was a very short one.

Now since I have installed webmin-time, removed the VMware tools synchronizing of time, my backups on all boxes are running fine, so the issue MAY be related to a change of time during run or out of sync times?

Hope this is of some use.




Liraz Siri's picture

Timing related bugs are the worst. For what it's worth there's a hook in TKLBAM to sync the time because S3 storage depends on that. If for some reason the clock in your VM is so unreliable that you can't use it (that happens sometimes) you may want to try sending off TKLBAM storage to a different backend with the --address option. By default it just all goes to autoconfigured addresses on S3.

If a bug relies on your clock then it can be very hard to track down. Our brains are wired to translate correlations into cause and effect so whatever your attention happens to be focused on will seem like it might have something to do with any variance of the bug's behavior.

Jeremy Davis's picture

Thanks for posting back. No doubt others will find that useful. Out of interest which version of TKLBAM are you using?
apt-cache policy tklbam | grep Installed

Add new comment