Re: [Bacula-users] [Non-DoD Source] Re: database upgrade problem

2017-09-01 Thread Phil Stracchino 
On 09/01/17 21:50, Jerry Lowry wrote:
> 
> Okay, on the one system that I upgraded to 9.0.3 I also upgraded the
> database engine to mariadb 12.2.8.  Was still getting the error.  I then
> went back to the July email and saw that they removed the
> |STRICT_TRANS_TABLES|
> 
> from the sql_modes.  I remove this and yes it does work now.
> 
> What will this affect on the whole of Bacula though?  Will this cause
> problems down the road?

I haven't run into any other issues yet.  At least, not any
database-related ones.


-- 
  Phil Stracchino
  Babylon Communications
  ph...@caerllewys.net
  p...@co.ordinate.org
  Landline: +1.603.293.8485
  Mobile:   +1.603.998.6958

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] [Non-DoD Source] Re: database upgrade problem

2017-09-01 Thread Jerry Lowry 
Okay, on the one system that I upgraded to 9.0.3 I also upgraded the
database engine to mariadb 12.2.8.  Was still getting the error.  I then
went back to the July email and saw that they removed the
STRICT_TRANS_TABLES

from the sql_modes.  I remove this and yes it does work now.

What will this affect on the whole of Bacula though?  Will this cause
problems down the road?

thanks,

Jerry

Now on to the other system, half way to a weekend :)

On Fri, Sep 1, 2017 at 5:15 PM, Phil Stracchino 
wrote:

> On 09/01/17 19:10, Jerry Lowry wrote:
> >
> > I am running 5.6.28 on one of my updated servers.  Once I updated the
> > bacula database and got it all running.  I tried to start a job and it
> > failed with this error.  Do you know if it is 5.6 or 5.6.x where the
> > problem started?  There are no sql_modes for date specified any where in
> > the configuration.
>
> Jerry, I *thought* it was 5.7 but my memory could be in error.
>
> If in doubt, check what the global SQL_MODE is *in your running DB*.  If
> you haven't got it set explicitly in your configuration, you're running
> on the compiled-in default.
>
>
> --
>   Phil Stracchino
>   Babylon Communications
>   ph...@caerllewys.net
>   p...@co.ordinate.org
>   Landline: +1.603.293.8485
>   Mobile:   +1.603.998.6958
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] [Non-DoD Source] Re: database upgrade problem

2017-09-01 Thread Phil Stracchino 
On 09/01/17 17:28, Davide Franco wrote:
> Do you use MySQL or MariaDb ?
> 
> It is something related to default value for datetime fields.
> 
> MariaDb does not accept 0 or Null ( I don't remember). You need the
> check previous thread in this mailing list.


This is correct, it is not a MariaDB vs. MySQL issue, it is a
MariaDB/MySQL *version* issue.  MySQL 5.6 and older allowed DATETIME and
TIMESTAMP fields to have the value 0, which is technically not valid for
those datatypes.  MySQL 5.7 and MariaDB 10.2, as configured out of the
box, enforce validity of DATETIME and TIMESTAMP types, and do not allow
them to be 0 or to contain zero year, month or day fields (since there
is no year 0, month 0, or day 0).[1]


There is a simple configuration fix for this that does not require any
changes to Bacula or your Catalog:

1.  Log into your database.
2.  SELECT @@GLOBAL.SQL_MODE;
3.  SET GLOBAL SQL_MODE='new value';

...Where you get the new SQL_MODE by REMOVING the modes NO_ZERO_DATE and
NO_ZERO_IN_DATE from whatever SQL_MODE you got in step 2.  Or, you can
skip 2 and just set SQL_MODE to something reasonable like
'STRICT_ALL_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION'.

Make sure that you set this both in the running database instance and in
your configuration files, and of course do the same on any replication
slaves.  Make sure you check ALL POSSIBLE config files for the SQL_MODE
setting.  Sometimes you will find it in unexpected places like /auto.cnf.  For safety, restart your database and make certain
that after restart, SQL_MODE is set to what you want it to be.

Once you have done this, you should have no further problems with the
Bacula catalog and zero values.



[1]  Zeros in the time part are fine, because hours are 0-23, minutes
are 0-59, and seconds are 0-60 (because leap seconds).


-- 
  Phil Stracchino
  Babylon Communications
  ph...@caerllewys.net
  p...@co.ordinate.org
  Landline: +1.603.293.8485
  Mobile:   +1.603.998.6958

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] [Non-DoD Source] Re: database upgrade problem

2017-09-01 Thread Davide Franco 
Do you use MySQL or MariaDb ?

It is something related to default value for datetime fields.

MariaDb does not accept 0 or Null ( I don't remember). You need the check
previous thread in this mailing list.

To fix the problem you need to update the database schema manually, or find
someone who produce a patch.

Hope this help.

Regards

On Fri, 1 Sep 2017 at 23:04, Hicks, Daniel CTR OSD DMEA <
daniel.hicks@dmea.osd.mil> wrote:

> Davide,
>
>
>
> I am having this same issue. Can you clarify how to make sure the catalog
> upgrade is done. I did the update to tables without error but am not sure
> it is the same.
>
>
>
> Thank you
>
>
>
> Dan Hicks | 916-999-2711
>
>
>
> *From:* Davide Franco [mailto:bacula-...@dflc.ch]
> *Sent:* Friday, September 1, 2017 12:11 PM
> *To:* Jerry Lowry ;
> bacula-users@lists.sourceforge.net
> *Subject:* [Non-DoD Source] Re: [Bacula-users] database upgrade problem
>
>
>
> Hi Jerry,
>
>
>
> Make sure the catalog upgrade has been done without issue.
>
>
>
> This seems to be related to Mariadb.
>
>
>
> Good luck
>
>
>
> Davide
>
>
>
> On Fri, 1 Sep 2017 at 17:38, Jerry Lowry  wrote:
>
> Hi,
> I finally got my backup server upgraded to 9..0.3.  I have run the
> database update and it succeeded with out any errors. But I get this error
> any time I start a job:
>
> 01-Sep 00:20 kilchis-dir JobId 0: Fatal error: sql_create.c:84 Create DB
> Job record INSERT INTO Job
> (Job,Name,Type,Level,JobStatus,SchedTime,JobTDate,ClientId,Comment) VALUES
> ('BackupCatalog.2017-09-01_00.20.18_03','BackupCatalog','B','F','C','2017-09-01
> 00:20:16',1504250416,15,'') failed. ERR=Field 'StartTime' doesn't have a
> default value
>
> Does this mean the update did not work?
>
> thanks for the help!
>
> jerry
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Bacula-users mailing list
> Bacula-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bacula-users
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Bacula Verification Procedures

2017-09-01 Thread Bill Arlofski 
On 09/01/2017 12:53 PM, Bill Arlofski wrote:
> On 09/01/2017 06:36 AM, Jim Richardson wrote:
>> Bill,
>>
>> Thank you so much for the response.  This is the best possible answer I 
>> could have received.  I will put your script in play.  I will most likely 
>> make changes to have this run automagically 😊 say quarterly.  Modifications 
>> would be to pull jobs ids for those jobs and feed the script.  Unless I can 
>> somehow figure out a way with the schedule Job-overrides to assign a 
>> RunScript.  Say: (I know pie in the sky)
>>
>> Schedule {
>>   Name = "My_Cycle"
>>   Run = Level=Full feb mar may jun aug sep nov dec 1st - 5th sat at 00:00
>>   Run = Level=Full RunScript = AutoRestoreAndVerify jan apr jul oct 1st - 
>> 5th sat at 00:00
>>   Run = Level=Differential sun at 18:00
>>   Run = Level=Incremental mon at 18:00
>>   Run = Level=Differential tue at 18:00
>>   Run = Level=Incremental wed at 18:00
>>   Run = Level=Differential thu at 18:00
>>   Run = Level=Incremental fri at 18:00
>> }
>>
>> Thanks again I will update the group with my experience.
> 
> Hi Jim,
> 
> The funny thing is that I almost made a comment about this sort of thing
> (scheduling) in my previous reply, but then stopped short because I figured it
> was already getting too long. :)
> 
> This is quite simple to do just by adding a little date logic near the top of
> the script:
> 
> 8 runmons="Sep Jan Apr Jul Oct"
> now=$(date)
> day=$(echo ${now} | cut -d' ' -f1)
> mon=$(echo ${now} | cut -d' ' -f2)
> daymatch=$(echo ${rundays} | grep -i ${day})
> monmatch=$(echo ${runmons} | grep -i ${mon})
> 
> # Just print some things (for testing)
> # 
> # echo "Now: ${now}"
> # echo "rundays: ${rundays}"
> # echo "runmons: ${runmons}"
> # echo "Day: ${day}"
> # echo "Mon: ${mon}"
> # echo "DayMatch: ${daymatch}"
> # echo "MonMatch: ${monmatch}"
> 
> if [ -n "${daymatch}" ] && [ -n "${monmatch}"  ]; then
>   echo "The day is ${day}, which is in our list of days to run on: 
> \"${rundays}\""
>   echo "The month is ${mon}, which is in our list of months to run on:
> \"${runmons}\""
>   echo "Continuing with script..."
> else
>   echo "Not running since either the day or month does not match our
> specified list"
>   exit 1
> fi
> 8<
> 
> The exit 1 is not necessary really, and will be ignored by Bacula because this
> would be in a RunsWhen = after script... Bacula cannot "fail" a job based on a
> script that is run after since the job status is already written to the
> catalog before the "after" RunScript(s) are called. ;)
> 
> Hope this help!
> 
> Best regards,
> 
> Bill
> 

Arg... Stupid word wrap...:)

Also, to clarify my comment about the exit 1 not being necessary... Well, an
"exit" is necessary to break out of the script and not run it on the wrong
days... It is just that you would probably want an "exit 0" if used in the
script I submitted last night.

Best regards,

Bill



-- 
Bill Arlofski
http://www.revpol.com/bacula
-- Not responsible for anything below this line --

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] [Non-DoD Source] Re: database upgrade problem

2017-09-01 Thread Hicks, Daniel CTR OSD DMEA 
Davide,

I am having this same issue. Can you clarify how to make sure the catalog 
upgrade is done. I did the update to tables without error but am not sure it is 
the same.

Thank you

Dan Hicks | 916-999-2711

From: Davide Franco [mailto:bacula-...@dflc.ch]
Sent: Friday, September 1, 2017 12:11 PM
To: Jerry Lowry ; bacula-users@lists.sourceforge.net
Subject: [Non-DoD Source] Re: [Bacula-users] database upgrade problem

Hi Jerry,

Make sure the catalog upgrade has been done without issue.

This seems to be related to Mariadb.

Good luck

Davide

On Fri, 1 Sep 2017 at 17:38, Jerry Lowry 
mailto:michaiah2...@gmail.com>> wrote:
Hi,
I finally got my backup server upgraded to 9..0.3.  I have run the database 
update and it succeeded with out any errors. But I get this error any time I 
start a job:

01-Sep 00:20 kilchis-dir JobId 0: Fatal error: sql_create.c:84 Create DB Job 
record INSERT INTO Job 
(Job,Name,Type,Level,JobStatus,SchedTime,JobTDate,ClientId,Comment) VALUES 
('BackupCatalog.2017-09-01_00.20.18_03','BackupCatalog','B','F','C','2017-09-01 
00:20:16',1504250416,15,'') failed. ERR=Field 'StartTime' doesn't have a 
default value
Does this mean the update did not work?
thanks for the help!
jerry
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! 
http://sdm.link/slashdot___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] database upgrade problem

2017-09-01 Thread Davide Franco 
Hi Jerry,

Make sure the catalog upgrade has been done without issue.

This seems to be related to Mariadb.

Good luck

Davide

On Fri, 1 Sep 2017 at 17:38, Jerry Lowry  wrote:

> Hi,
> I finally got my backup server upgraded to 9..0.3.  I have run the
> database update and it succeeded with out any errors. But I get this error
> any time I start a job:
>
> 01-Sep 00:20 kilchis-dir JobId 0: Fatal error: sql_create.c:84 Create DB
> Job record INSERT INTO Job
> (Job,Name,Type,Level,JobStatus,SchedTime,JobTDate,ClientId,Comment) VALUES
> ('BackupCatalog.2017-09-01_00.20.18_03','BackupCatalog','B','F','C','2017-09-01
> 00:20:16',1504250416,15,'') failed. ERR=Field 'StartTime' doesn't have a
> default value
>
> Does this mean the update did not work?
>
> thanks for the help!
>
> jerry
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Bacula-users mailing list
> Bacula-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bacula-users
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Bacula Verification Procedures

2017-09-01 Thread Bill Arlofski 
On 09/01/2017 06:36 AM, Jim Richardson wrote:
> Bill,
> 
> Thank you so much for the response.  This is the best possible answer I could 
> have received.  I will put your script in play.  I will most likely make 
> changes to have this run automagically 😊 say quarterly.  Modifications would 
> be to pull jobs ids for those jobs and feed the script.  Unless I can somehow 
> figure out a way with the schedule Job-overrides to assign a RunScript.  Say: 
> (I know pie in the sky)
> 
> Schedule {
>   Name = "My_Cycle"
>   Run = Level=Full feb mar may jun aug sep nov dec 1st - 5th sat at 00:00
>   Run = Level=Full RunScript = AutoRestoreAndVerify jan apr jul oct 1st - 5th 
> sat at 00:00
>   Run = Level=Differential sun at 18:00
>   Run = Level=Incremental mon at 18:00
>   Run = Level=Differential tue at 18:00
>   Run = Level=Incremental wed at 18:00
>   Run = Level=Differential thu at 18:00
>   Run = Level=Incremental fri at 18:00
> }
> 
> Thanks again I will update the group with my experience.

Hi Jim,

The funny thing is that I almost made a comment about this sort of thing
(scheduling) in my previous reply, but then stopped short because I figured it
was already getting too long. :)

This is quite simple to do just by adding a little date logic near the top of
the script:

8

[Bacula-users] database upgrade problem

2017-09-01 Thread Jerry Lowry 
Hi,
I finally got my backup server upgraded to 9..0.3.  I have run the database
update and it succeeded with out any errors. But I get this error any time
I start a job:

01-Sep 00:20 kilchis-dir JobId 0: Fatal error: sql_create.c:84 Create DB
Job record INSERT INTO Job
(Job,Name,Type,Level,JobStatus,SchedTime,JobTDate,ClientId,Comment) VALUES
('BackupCatalog.2017-09-01_00.20.18_03','BackupCatalog','B','F','C','2017-09-01
00:20:16',1504250416,15,'') failed. ERR=Field 'StartTime' doesn't have a
default value

Does this mean the update did not work?

thanks for the help!

jerry
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Bacula Verification Procedures

2017-09-01 Thread Jim Richardson 
Bill,

Thank you so much for the response.  This is the best possible answer I could 
have received.  I will put your script in play.  I will most likely make 
changes to have this run automagically 😊 say quarterly.  Modifications would be 
to pull jobs ids for those jobs and feed the script.  Unless I can somehow 
figure out a way with the schedule Job-overrides to assign a RunScript.  Say: 
(I know pie in the sky)

Schedule {
  Name = "My_Cycle"
  Run = Level=Full feb mar may jun aug sep nov dec 1st - 5th sat at 00:00
  Run = Level=Full RunScript = AutoRestoreAndVerify jan apr jul oct 1st - 5th 
sat at 00:00
  Run = Level=Differential sun at 18:00
  Run = Level=Incremental mon at 18:00
  Run = Level=Differential tue at 18:00
  Run = Level=Incremental wed at 18:00
  Run = Level=Differential thu at 18:00
  Run = Level=Incremental fri at 18:00
}

Thanks again I will update the group with my experience.

Jim Richardson

-Original Message-
From: Bill Arlofski [mailto:waa-bac...@revpol.com]
Sent: Thursday, August 31, 2017 10:30 PM
To: bacula-users@lists.sourceforge.net
Subject: Re: [Bacula-users] Bacula Verification Procedures

On 08/30/2017 09:31 PM, Jim Richardson wrote:
> So I am looking to the community to help with the following questions
> to save me from trial and error:

Hi Jim!


>  1. Is there a verification job or a sequence of jobs “built in” to Bacula
> that can accomplish an automated restore with an automated verification of
> Volume to Restore on Disk?

No, but some of this can be scripted.

I have attached a script that I have been using here for some months, both on 
my Bacula Community environment and in my Bacula Enterprise test environments.

The idea is that in a Runscript (RunsWhen = after), this script is called which 
then does an automated restore of the current backup job, then runs 
VolumeToCatalog, DiskToCatalog, and Data verification jobs. I am sure it is not 
perfect yet, but I bet this can provide some ideas and a jumping point for you.

Of course, since it accepts a jobid, client, fileset, and jobname on the 
command line, you can run the restore, followed by the verifies on any job you 
like and it does not have to be called from a Job's RunScript stanza. (Random 
Job restore and verification tests, anyone?)


>  2. Will the VolumeToCatalog job verify Catalog files to the Tape without
> first hashing and when hardware compression is in place?

This one is "above my pay grade"™   :)

Actually, with hardware compression, that is completely transparent to Bacula.
The hashing is computed, the data is written to the drive, the drive does its
hardware compression, and writes the compressed data to the tape.   On a
read/verify, the opposite takes place, and Bacula sees the actual
(uncompressed) data, and the hashes will match.


>  3. Is there a verification job or a sequence of jobs “built in” to Bacula
> that can accomplish an automated Restore with an automated Verification of
> Tape to Restore on Disk?

This is the same as #1, just with "tape" swapped for "volume". In my mind, file 
volumes and tape volumes can be considered and treated the same in most 
scenarios.


>  4. Are there other options or best practices to accomplish both a post job
> verification of Catalog to Volume and a periodic verification of Volume
> (Tape or Disk) to Restore on Disk?

Nothing that I know of. I suspect that since (most of) the pieces are there:
RunScript{} stanzas, restore and verify jobs, custom scripts, etc. I think that 
the only "best practice" would be what you or your company requires. eg:
How often should restores take place, which jobs/volumes should be tested, 
should random jobs be tested, or should only some critical ones be 
automatically tested, etc...


>  5. Is there a Bacula Systems whitepaper that covers best practices for
> Verification and Testing of backups?

For this, I can answer a definite "no". I think it is mainly because it kind of 
falls under #4, where a company's policy would probably dictate such specific 
things.


> I have looked into DiskToCatalog this will not work.  (someone argue with me).

Nope... :)  I will only agree, and then add to your comment. :)

The issue you describe below is exactly the issue I plan on reporting 
internally as a feature request to Bacula Systems.  My idea is exactly the one 
you describe below, and I cannot see a way that this can be accomplished as 
Bacula is currently written.

>  It will compare files on the client disk to the catalog.  After 15
> hours + verification run time many files have changes - archived,
> reached retention period and deleted, etc.  Ideally, I want a complete
> restore to different location and a verification that the files in the
> Catalog and the Volume are actually the files on disk after the Restore.

I think (and I will let Kern answer for himself of course :), but I think Kern 
will tell you that if the backup Job has a "Signature = md5" (or sha1), and it 
ran

[Bacula-users] Observations on speeding-up backups by splitting jobs

2017-09-01 Thread Andreas Koch 
Hi all,

the following observations might be useful for other users looking to
speed-up their backups. It might be specific to our local system
architecture, but we hope that it might also help others to achieve shorter
backup runtimes.

Setup:
--

The file server is an EMC VNX5200 unified storage system, which we use as a
NAS NFSv4-mounted by the clients (workstations [via 1G Eth] and servers [via
multiple 10G Eth]). The NAS is attached by a dedicated 10G Ethernet link to
our backup server (Dell R630, 3.4 Ghz 6-core Xeon, 128GB memory), which
hosts all Bacula 7.4.4 daemons (DIR, SD, FD) and Postgresql as catalog DB.
We back up to a Tandberg LTO-6 StorageLoader (single drive), attached by
SAS. The Bacula spool volume consists a a single large btrfs RAID-0 volume
composed of four 800 GB Intel SSD drives. We already tuned Postgresql
performance (achieved a 3h reduction in backup time) before the experiments
described here.

Bacula configuration:
-

Backing up each of two small local and three larger NFSv4-mounted file
systems from the NAS, all in a single job, plus a final catalog backup. This
actually is a bit simplified here, there a few more clients, but they have
only very small backups that do not affect total runtime much. We use Full
and Accurate Differential backups (see table below).

Problem:


Ever since getting the VNX5200 operational, the backups worked, but they ran
excessively slowly (far from the line rate of the 10G NAS-backup server
link, see table at end). However, when doing streaming file operations
(e.g., a tar) via NFSv4 from the NAS to the backup server, the full line
rate was easily reached.

Hypothesis:
---

What leads to the slow backups is not the actual data transfer rate (which
the NAS managed with only very minor CPU load when tar'ing), but the
_latency_ incurred by the many meta-data operations (stat(), fstat() etc.)
performed during backup.

Proposed Solution:
--

To hide the latency of these operations, we split the single large backup
job into nine smaller backup jobs of roughly equal size, which were then run
_concurrently_ (setting Concurrent Jobs = 20 in bacula-dir.conf). The idea
was to saturate the 10G link with the meta-data operations from multiple
backup jobs, thus hiding their individual latency (similar to the SIMT
multi-threading on graphics cards for hiding memory latencies). Since we are
streaming to an SSD-based spool, we do not incur any seek penalties due to
mixing multiple jobs on the same spool volume.

Final Runtime Results, showing typical job sizes:
-

BackupBefore optimization  After optimization
Full: 17.5 h (3483 GB) 10.0 h (3712 GB)
Differential: 14.6 h ( 285 GB)  6.6 h ( 314 GB)
#Jobs:3 + 1 (3 small + 1 big job)   3 + 9 (12 smaller jobs)

Discussion:
---

As you can see, we achieved the largest performance increase for our
Accurate differential backup, which (we assume) performs far more meta-data
queries than the Full backups. The disadvantage, of course, is that we now
have to keep an eye on the individual sizes of our partitioned backup jobs
to make sure they are still reasonably balanced.

Future Work:


It appears that such trickery might be unnecessary if the Bacula FD could
perform something similar (hiding the latency of individual meta-data
operations) on-the-fly, e.g. by executing in a multi-threaded fashion. This
has been proposed as Item 15 in the Bacula `Projects' list since November
2005 but does not appear to have been implemented yet (?).

We hope this contribution helps other Bacula users and welcome comments on
similar experiences, or even better ways to achieve higher speed-ups on the
same hardware.

Many thanks go to Florian Stock for coming up with the idea and collecting
the data!

Best,
  Andreas Koch



signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users