On 2015-05-13 07:35, Alex Domoradov wrote:
> > I'd say your initial tls overhead was due to slow cipher
> it's very strange as I have a fastest CPU on both of sides
That's still not zero-cost, the question is whether your tls
implementation is clever enough to hide that cost or it'll amplify to
> I'd say your initial tls overhead was due to slow cipher
it's very strange as I have a fastest CPU on both of sides
storage: Intel Xeon CPU E3-1245 V2 @ 3.40GHz
client: Intel Core i7-4770 CPU @ 3.40GHz
And as I can see in the top output the CPU is not bottleneck at all, imho
On the storage I'm
On 05/12/2015 01:50 PM, Alex Domoradov wrote:
>> Where's 23MB/s come from?
> from bacula-web - http://i.imgur.com/pEQwCvI.png
>
>> I get 200+MB/s on disk writes to raidz zfs backed by cheap "desktop"
> drives
> It would depend on "type" of files as I understood. I have a lot (~11M) of
> small file
> Where's 23MB/s come from?
from bacula-web - http://i.imgur.com/pEQwCvI.png
> I get 200+MB/s on disk writes to raidz zfs backed by cheap "desktop"
drives
It would depend on "type" of files as I understood. I have a lot (~11M) of
small files 20-50 Kbyte. So I don't believe that you can get 200 Mb/
On 05/12/2015 01:18 PM, Dimitri Maziuk wrote:
>> No, I didn't. How can I test backup over loopback?
>
> Test 127.0.0.1. Doesn't matter since my guess about the network was wrong.
Oh, wait, "test backup". Yeah, that may take a little more work than
iperf/netcat. ;)
--
Dimitri Maziuk
Programmer/
On 05/12/2015 02:55 AM, Alex Domoradov wrote:
>> Run "openssl speed" then run with e.g. "ciphers = md2" on both
> ends and post the difference
> I have tested with RC4-MD5 cipher. The result even worse - 8 hours 30
> minutes :)
Hehe. Point is, if you let endpoints autonegotiate, you've no idea wha
> Run "openssl speed" then run with e.g. "ciphers = md2" on both
ends and post the difference
I have tested with RC4-MD5 cipher. The result even worse - 8 hours 30
minutes :)
> How did you get the 1.5hr difference? -- 23MB/s looks like your
bottleneck is the network
I don't think so
# iperf3 -c 7
On 05/11/2015 03:22 AM, Alex Domoradov wrote:
> Maybe someone would be interesting. I made test with stunnel yesterday and
> ... the results almost the same.
Run "openssl speed" then run with e.g. "ciphers = md2" on both
ends and post the difference. Repeat with e.g. "ciphers = ghash"
("ciphers =
Maybe someone would be interesting. I made test with stunnel yesterday and
got the following result
stunnel (data channel encryption)
Compression: LZO
Time: 08:06:38
Size: 653.04 GB
Files: 11,288,747
Speed: 22.90 MB/s
Compression: 0.21
No TLS
Compression: LZO
Time: 07:56:38
Size: 653.04 GB
Files:
On 05/08/2015 11:06 AM, Alex Domoradov wrote:
>> En/decrypting .7TB stream you'll notice very much.
> Do you mean 700 Gb? (653.04 GB)
653.04/1024=0.64. So I rounded the wrong way up.
> it's a requirements from our security department. All communications
> between servers on the Internet should be
> En/decrypting .7TB stream you'll notice very much.
Do you mean 700 Gb? (653.04 GB)
> If your data isn't that sensitive, you're just wasting time.
it's a requirements from our security department. All communications
between servers on the Internet should be encrypted.
Is there any point to test
On 2015-05-08 02:32, Alex Domoradov wrote:
> I made two tests yesterday. Full backup with TLS and without.
> Why difference is so big ~ 1,5 hours? Is it normal with tls enabled?
Yes. You have to encrypt everything on one end and decrypt on the other.
Despite what tls preachers tell us, encryptio
I made two tests yesterday. Full backup with TLS and without.
No TLS
Compression: LZO
Time: 07:56:38
Size: 653.04 GB
Files: 11,288,747
Speed: 23.38 MB/s
Compression: 0.21
TLS
Compression: LZO
Time: 09:31:08
Size: 653.04 GB
Files: 11,288,747
Speed: 19.51 MB/s
Compression: 0.21
Why difference is s
Thanks Bill! I appreciate the help and information. Looks like I have
some reading to do.
-craig
On Wed, May 6, 2015 at 3:07 PM, Bill Arlofski wrote:
> On 05/05/2015 10:18 PM, Craig Shiroma wrote:
> > Hi Romeo,
> >
> > Thanks! Just so I understand correctly...
> > The bacula-fd running on th
On 05/05/2015 10:18 PM, Craig Shiroma wrote:
> Hi Romeo,
>
> Thanks! Just so I understand correctly...
> The bacula-fd running on the clients communicate with the bacula server using
> the password in client's bacula-fd.conf. This authentication on the "wire" is
> actually encrypted. Is this co
Yes, it's encrypted with CRAM-MD5.
http://en.wikipedia.org/wiki/CRAM-MD5
On Tue, May 5, 2015 at 10:18 PM, Craig Shiroma
wrote:
> Hi Romeo,
>
> Thanks! Just so I understand correctly...
> The bacula-fd running on the clients communicate with the bacula server
> using the password in client's ba
Hi Romeo,
Thanks! Just so I understand correctly...
The bacula-fd running on the clients communicate with the bacula server
using the password in client's bacula-fd.conf. This authentication on the
"wire" is actually encrypted. Is this correct?
-craig
On Tue, May 5, 2015 at 3:43 PM, Romeo Th
Hi Craig,
See [1]:
You should restrict access to the Bacula configuration files, so that the
> passwords are not world-readable. The Bacula daemons are password protected
> using CRAM-MD5 (i.e. the password is not sent across the network). This
> will ensure that not everyone can access the daemo
Hello,
I was wondering...
Are all of the passwords exchanges used by Bacula (both server and client
daemons) encrypted when going over the "wire"?
Thanks in advance,
Craig Shiroma
--
One dashboard for servers and applicat
19 matches
Mail list logo
