[Box Backup] Re: client connection error

[boxbackup@fluffy.co.uk]

Chris,

> You should not need to run bbackupd with -DVT normally, and if you do that
> in the init script it will probably never terminate.
>
> Could you try running bbackupd with -kVT instead? It should go into the
> background but continue writing to your console. This may mess up the
> console a bit, but it will help to figure out why it's not working when
> you just run bbackupd normally in the background.

I ran the daemon using -kVT as you requested. I saw no difference from
running that or with -DVT, at least not on the screen output or the logs.
Does this help any? If not, I'll do whatever you need.

If needed to be done long-term, writing to the console isn't a huge
problem, but could I just send the output to /dev/null?

>> Oh, BTW, "/etc/init.d/bbstored restart" does not start the daemon back
>> up, even though the text says "restarted".
>
> Can you have a look at the initscript to see what's wrong? I'm afraid I
> didn't write it and don't have a debian box offhand to test on. Logs in
> /var/log/messages (or /var/log/box) may help to understand the problem.

I'm not very familiar with init.d scripts, although the last few minutes
of reading has been very informative. I think I've narrowed it down to the
following:

bbstored - stops and starts fine, but will not come up on a restart.
Running restart right afterwards brings the daemon back up, so it might
just need a pause inserted between the stop/start commands.

bbackupd - won't stop either on a stop or restart, and has to be killed.
Afterwards it will come up on a start or restart command.

If you need access to a Debian server, I'll offer mine up. It's a VM and I
don't have any sensitive data on it.

I honestly have no idea why they behave differently, and I've compared the
two init.d scripts. They are the same but for the bin file they execute.

>> Is there any way to run a test to see how much data will be transfered
>> after compression/encryption?
>
> I'm afraid not, but you could guess a 2:1 compression ratio unless you
> have a lot of uncompressable binary files, in which case it's likely to be
> more like 1:1.

No problem, it's just good to know how it handles encryption. Are you able
to tell me what it uses to compress the data?

>> It would also be nice to have an option (I know, you're still working on
>> it, and this is just a low-priority "convenience" request) to see the
>> items transfered in KB, MB or GB instead of bytes.
>
> I'll think about it, but probably the best option is to run a log parser
> like bbreporter.py and have that process the numbers into something more
> human-readable for you.
>
> Which specific log messages are you referring to?

*Blush* well... I was looking at the console output, and it turns out the
logs don't list the data size. My apologies. I suppose that would be
interesting, but largely unnecessary.

I also noticed that, oddly enough, I've only gotten one e-mail notice for
success/fail of the job, despite firing off a sync multiple times. Does it
only e-mail when there's a problem? If so, I should have gotten several,
as I only now got a successful backup. I didn't change that part of the
config.

I'm sorry for asking so many questions. I very much appreciate your help.

After I work all this out I'll be modifying my HowTo that I linked to you
yesterday.


Sean