TKLBAM error doing local backup on fileserver appliance - 'NoneType' object has no attribute 'backup_id'

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.

Update: 

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.

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.

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

Thanks!

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.

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

/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.

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)

Mine's on bare metal, FWIW.

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.

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.

apt-cache policy tklbam | grep Installed