You are here
Nelson Hoover - Thu, 2014/08/14 - 00:16
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>
main()
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.
Forum:
Update: Today I decided to
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.
From the other report it
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.
+1 worked for me too
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!
What file did you open?
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.
/usr/bin/tklbam-backup in
/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.
Nah, must be a coincidence
Just reading that file (or even touching it) couldn't have changed anything. So this was probably just a coincidence.
I can't see any sane reason
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.
None attribute problem returns
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.
Mine's on bare metal, FWIW.
May be to do with system time
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.
Timing issues are the worst
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.
Great work, thanks for posting back
Add new comment