Re: [Bacula-users] Intervention needed for backup

[Donna Hofmeister]

On Thu, May 24, 2018 at 9:26 AM, Donna Hofmeister  wrote:

>
> Second interesting question -- given my "Label Format" statement, I would
> expect my files to be named something like this: 
> Vol-minerva.allegro.com-fd-File-20180517-2305-73-19.
> So why are my files named: MinervaBackup.2018-05-23_23.05.00_53?
>

To answer my own question

I think the underlying issue was I had made several changes to the "label
format" statement while I've been testing Bacula...and had inadvertantly
created this situation.

To solve this, I wiped out my bacula storage environment and all seems to
be working well.

So -- reasking my second question -- if you change the "label format"
statement, is there additional steps after that?- donna

-- 
Donna Hofmeister
Allegro Consultants, Inc.
408-252-2330
Visit us on Linkedin

Like us on Facebook 
--
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] Can I run jobs on 2 storage daemons at the same time from one director?

[Kern Sibbald]

Hello,

Please see below ...


On 05/23/2018 08:48 AM, Panayiotis Gotsis wrote:

Hello

We have a setup with two storage daemons but, up till now, I have not
really checked whether there is concurrency. We have not yet installed
v9 to see whether there is any major change, but generally speaking,
the queue handling from bacula leaves a lot to be desired.


I would be interested to know what you mean about "queue handling" -- 
technically queues are very low level items in Bacula and I doubt that 
is what you are referring to.


Bacula handles concurrency extremely well since in general all daemons 
support multiple simultaneous jobs.  However there is one place where 
Bacula does have difficulties and that is dealing with Devices (e.g. a 
tape drive).  Once a Job starts, it gets assigned a device for writing 
(also one for reading for copy like jobs).  Once the device is assigned, 
it can not change and that can create some conflicts for using volumes 
(e.g. tapes) that need to be swapped from drive to drive.  If Bacula is 
reading a device and it needs another volume, it can quite easily use a 
different device, but as just mentioned it is not currently possible for 
write enabled devices (i.e. doing a backup).


Best regards,
Kern



The point of my response however is that I should warn you of some
potential issues you may face with two storage daemons. For example,
that you cannot have two different Full/Incr/Diff schedules, one for each
storage daemon, for the same FD without some conflicts.

Just my (extra) 2c

On 18-05-22 18:22 +0200, Charles Nadeau wrote:

Good morning,

I configured my director with 2 storage daemons (one to disks, one to
tapes) on 2 different machines. They both backup without problems except
that they can't backup up simultaneously. I can have many jobs 
running on
my disks daemon but never have jobs running on both storage daemons 
at the
same time. I set "Maximum Concurrent Jobs" to 20 for my Director but 
still

I can't have both storage daemon run jobs simultaneously.

Here are relevant configuration snippets:
Server with autochanger bacula-sd.conf:
Storage { # definition of myself
 Name = superbackup-sd
 SDPort = 9103  # Director's port
 WorkingDirectory = "/var/lib/bacula"
 Pid Directory = "/run/bacula"
 Maximum Concurrent Jobs = 20
 SDAddress = 192.168.0.17
 Comm Compression = yes
}
Autochanger {
 Name = Autochanger
 Device = Drive-1
 Changer Command = "/etc/bacula/scripts/mtx-changer %c %o %S %a %d"
#  Changer Device = /dev/sg8
 Changer Device = /dev/tape/by-id/scsi-1IBM_3573-TL_00FRU780_LL0
}
Device {
 Name = Drive-1
 Media Type = LTO-3
 Device Type = Tape
#  Archive Device = /dev/nst0
 Archive Device = /dev/tape/by-id/scsi-1IBM_ULT3580-TD3_1210306523-nst
 AutomaticMount = yes   # when device opened, read it
 RequiresMount = no
 AlwaysOpen = yes
 RemovableMedia = yes
 RandomAccess = no
# Changer Command = "/etc/bacula/scripts/mtx-changer %c %o %S %a %d"
# Changer Device = /dev/sg0
 AutoChanger = yes
 Autoselect = yes
 Drive Index = 0
# Enable the Alert command only if you have the mtx package loaded
# Alert Command = "sh -c 'tapeinfo -f %c |grep TapeAlert|cat'"
#
http://www.bacula.org/9.0.x-manuals/en/main/New_Features_in_9_0_0.html#SECTION00303000 


 Alert Command = "/opt/bacula/scripts/tapealert %l"
# If you have smartctl, enable this, it has more info than tapeinfo
# Alert Command = "sh -c 'smartctl -H -l error %c'"
 Maximum Spool Size = 797GB
 Maximum Job Spool Size = 342GB
 Spool Directory = /baculatmp
 Maximum Concurrent Jobs = 1
#
https://arstechnica.com/civis/viewtopic.php?p=3554575=d6583bef7be3b1ddd26514cc6b403f86#p3554575 


 Maximum Block Size = 1024K
#
http://www.bacula.org/9.0.x-manuals/en/main/Storage_Daemon_Configuratio.html#SECTION00203 


 Maximum File Size = 8GB
#
http://www.bacula.org/9.0.x-manuals/en/problems/Testing_Your_Tape_Drive_Wit.html#SECTION0047 


 Hardware End of Medium = yes
 Fast Forward Space File = yes
}

Server with disks array bacula-sd.conf:
Storage { # definition of myself
 Name = bigzilla-sd
 SDPort = 9103  # Director's port
 WorkingDirectory = "/var/lib/bacula"
 Pid Directory = "/var/run/bacula"
 Maximum Concurrent Jobs = 20
 SDAddress = 192.168.0.53
 Comm Compression = yes
}
Device {
 Name = FileStorage3
#  Name = File3
 Media Type = File
 Device Type = File
 Archive Device = /mnt/bacula
 LabelMedia = yes;   # lets Bacula label unlabeled media
 Random Access = Yes;
 AutomaticMount = yes;   # when device opened, read it
 RemovableMedia = no;
 AlwaysOpen = no;
 Maximum Volume Size = 10G
#  Spool Directory = /baculatmp
#  Maximum Spool Size = 170 GB
#  Maximum Job Spool Size = 180 GB
 Maximum Concurrent Jobs = 3
}

Director's bacula-dir.conf:
Director {    # define myself
 Name = bigzilla-dir
 DIRport = 9101    # where we 

Re: [Bacula-users] Progressive VFull Questions

[Alfred Weintoegl]

Hello Bill, many thanks for your reply.

I'll try these very useful tips right away on our test-environment.

And if it's possible I would appreciate it very much if you can send 
some sample configs...
As Lloyd said: "...working from examples to be a good bit easier.  Also 
more likely to not only work, but work well".



Best Regards
Alfred


Am 24.05.2018 um 23:48 schrieb Bill Arlofski:

Hello Alfred,

A few things jump right out at me about your sample config...

Consider standard Full job vs an Incremental or Differential. You do not have
three different Jobs defined, each with a different level. This does not work
in the context of Bacula.  With Bacula, you define one job, and then run it at
different levels at specified times.

It is a similar case with Virtual Full jobs.

With VFulls, you define ONE Job. Then, you set up a schedule that runs
Incrementals on all the days you want, and a Virtual Full level on the day and
time you wish the Virtual Full to be triggered.

I always recommend that the Job is configured with "Level = Incremental", so
that whenever you run it manually, it will already be probably what you want.
If you need it to be a full, or Virtual Full run, then this can be changed
before submitting the job, or on the bconsole command line, for example:

* run job=someJob level=Full



If you have different pools for your normal Fulls and Incrementals, they will
both require a "NextPool = " setting where "" is the Pool you wish to
keep your Virtual Fulls in. Of course the "" will need to be the same in
the Full and Incremental pools.  Additionally, you can also set/override the
NextPool in the schedule, so it would not be required in the Pools at all.


Your schedules do not need the Accurate=yes option since it is set in your Job
already. They also do not need to specify the "Level=" except for the
VirtualFull Run line since the Level is already defined in the Job as 
Incremental.


For the schedule, it might look something simple like:
8<
Schedule {
  Name = "PVF_Schedule"
  Run = at 23:00
  Run = Level=VirtualFull Priority=12 sun at 23:30
}
8<

So, basically, what that example Schedule says is:
- Run Incrementals every day at 23:00. The Job has "Level = Incremental"
   defined, so no need to add it in the Schedule
- Run the VFull on Sunday at 23:30 with a different priority than normal
   jobs. This will ensure that the Incrementals finish before the VFull
   starts.

Additionally, you will want to add the "AllowDuplicateJobs=yes" to your Job
configuration so that if the Sunday Incremental has not finished, the Sunday
Virtual Full can be queued and it will wait. Otherwise it will be
automatically cancelled.


Also, keep in mind that since you have set "Backups To Keep = 95", this will
require that you run one Full (this will happen automatically the first time
Bacula is told to run the Job with Level=Incremental when no Full exists), and
then at least 96 Incrementals before you can run a Virtual Full.

In this case, the easiest way to do this is to simply comment out the
"Level=VirtualFull" line in the PVF_Schedule until you have the Full backup
and all the required Incrementals. If you do not do this, then, each Sunday
when the Schedule triggers the VirtualFull backup, the Job will fail with the
error "not enough backups" - until you have the required 96 jobs. :)


I think this should get you onto the right track. If real sample configs are
required, I think I can probably dig something up from my test environments,
or build some from scratch.  :)

Best regards,

Bill



--
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