Hello Olaf,
Have you checked if this address/port (tux64.home.lan:9101) is not being
used by another process? Your original bacula-dir.conf (the last post) was
configured to use locahost and not tux64.home.lan as your are trying now.
Best regards,
Ana
On Sat, Jun 27, 2015 at 4:38 AM, olx69 wrot
I wonder if the thread starter (SPQR) solved his problem.
The discussion became hot and he flew. lol
===
Heitor Medrado de Faria - LPIC-III | ITIL-F | Bacula Systems Certified
Administrator II
Do you need Bacula training?
On 6/27/2015 8:55 AM, Alex Domoradov wrote:
> FYI
>
> I have 1Gb uplinks between bacula sd and client and get the following
> results
>
> Compression: NONE
> Time: 07:16:58
> Size: 831.14 GB
> Files: 11,288,747
> Speed: 32.46 MB/s
> Compression: 0.00
>
> Compression: LZO
> Time: 07:56:38
> Size: 65
FYI
I have 1Gb uplinks between bacula sd and client and get the following
results
Compression: NONE
Time: 07:16:58
Size: 831.14 GB
Files: 11,288,747
Speed: 32.46 MB/s
Compression: 0.00
Compression: LZO
Time: 07:56:38
Size: 653.04 GB
Files: 11,288,747
Speed: 23.38 MB/s
Compression: 0.21
Compress
On 6/27/2015 5:45 AM, Dmitri Maziuk wrote:
> On 6/26/2015 7:26 AM, Josh Fisher wrote:
>
>> However, for backup devices lacking hardware compression (such as disk),
>> compression may be warranted regardless of client connection speed. This
>> is why a SD level compression feature would be useful.
On 27/06/15 10:45, Dmitri Maziuk wrote:
> Compressing data on the client means fewer bytes to send over the
> wire. Block-level compression like bzip2 tends to be completely
> cpu-bound and anything bigger than a cellphone tends to have plenty of
> cycles to spare.
Not entirely true and certainly
On 6/27/2015 1:37 AM, Andrew Noonan wrote:
> On Fri, Jun 26, 2015 at 2:17 PM, Ana Emília M. Arruda
> wrote:
>> Are you going to generate a .tar of about 250TB every day? Which will
>> be the nature of your restores? You´re going to need always the
>> restore of the whole data set or occasional
On 6/26/2015 7:26 AM, Josh Fisher wrote:
> However, for backup devices lacking hardware compression (such as disk),
> compression may be warranted regardless of client connection speed. This
> is why a SD level compression feature would be useful.
Compressing data on the client means fewer bytes
Hello Ana,
> I´m not sure about this, but I noticed something about the names for
> your storage:
>
> ---bacula-traymon.conf--
> Storage {
> Name = bacula-tux64-sd
> ...
> }
>
> bacula-dir-full.conf
> Storage {
> Name = File
>...
> }
>
> bacula-sd-full.conf-
>
>