[debian]bacula meerdere jobs tegelijk runnen

Pagina: 1
Acties:

Acties:
  • 0 Henk 'm!

  • Boudewijn
  • Registratie: Februari 2004
  • Niet online

Boudewijn

omdat het kan

Topicstarter
Ik heb zoals bekend een bacula setup, maar krijg het niet voor elkaar om meerdere jobs tegelijk te draaien.
Het lijkt erp dat dit de performance zal verbeteren, en het moet kunnen... dus waarom niet.

Situatie nu:

ik trap 2 jobs kort achter elkaar af, en vind in de Director:
code:
1
2
3
4
5
6
7
Running Jobs:
Console connected at 07-Sep-11 19:52
 JobId Level   Name                       Status
======================================================================
   469 Increme  www2job.2011-09-07_19.52.11_04 is running
   470 Increme  sqljob.2011-09-07_19.52.13_05 is waiting on max Storage jobs
====

Jammer dat ze achter elkaar wachten.


Ik lees dat je Max Concurrent Jobs = X aan kunt geven in zowel dir, fd als sd.
Het gaat hier wat mij betreft met name om de director en de sd, omdat ik meerdere clients (fd's) tegelijk af wil laten handelen door mijn director.

bacula-dir.conf
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
Director {                            # define myself
  Name = leiden-dir
  QueryFile = "/etc/bacula/scripts/query.sql"
  WorkingDirectory = "/var/lib/bacula"
  PidDirectory = "/var/run/bacula"
  Maximum Concurrent Jobs = 50
  Password = "*"         # Console password
  Messages = Daemon
  DirAddresses = {
        ip = { addr = *; port = 9101 }
        ip = { addr = 127.0.0.1; port =9101 }
  }
}

Elke client heeft ook een JobDef, a la:
code:
1
2
3
4
5
6
7
8
9
10
11
12
JobDefs {
  Name = "www2-weekly"
  Type = Backup
  Level = Incremental
  Client =  www2
  FileSet = "Full Set"
  Schedule = "WeeklyCycle"
  Storage = leiden-filestorage
  Messages = Standard
  Pool = LeidenPool
  Priority = 10
}

Deze zijn allemaal gelijk, maar dan andere Names en Clients.
Daar hangt dan ook netjes een Job aan:
code:
1
2
3
4
5
Job {
  Name = "www2job"
  JobDefs = "www2-weekly"
  Write Bootstrap = "/var/lib/bacula/www2.bsr"
}

En een Client:
code:
1
2
3
4
5
6
7
8
9
10
Client {
  Name = www2
  Address = www2.*
  FDPort = 9102
  Catalog = MyCatalog
  Password = "*"
  File Retention = 30 days            # 30 days
  Job Retention = 6 months            # six months
  AutoPrune = yes                     # Prune expired Jobs/Files
}

En mijn bacula-sd.conf, compleet niet boeiend.
code:
1
2
3
4
5
6
7
8
9
10
Storage {                             # definition of myself
  Name = leiden-filestorage
  WorkingDirectory = "/var/lib/bacula"
  Pid Directory = "/var/run/bacula"
  Maximum Concurrent Jobs = 50
  SDAddresses = {
        ip = { addr = 192.168.1.44; port = 9103 }
        ip = { addr = 127.0.0.1; port =9103 }
  }
}


Passwords en dergelijke zijn verwijderd met een * ;).


Punt blijft, dat ondanks het lezen van de FAQ (http://www.bacula.org/fr/...ION0081818000000000000000) ik geen concurrent jobs krijg. Weet iemand wat hier fout gaat?

i3 + moederbord + geheugen kopen?


Acties:
  • 0 Henk 'm!

  • Hero of Time
  • Registratie: Oktober 2004
  • Nu online

Hero of Time

Moderator LNX

There is only one Legend

Dit wil ik zelf ook wel weten. Mijn bacula op m'n werk doet z'n taak goed, maar het is nogal irritant dat de full backup niet tegelijk loopt op alle clients. Nu wacht een grote taak op een iets kleinere die lang duurt ivm off-site (VPN verbinding tussen de locaties is geen turbo lijn :P).

Waar ik aan dacht, is dat het wellicht komt door de concurrent-jobs die bij de client in de bacula-fd.conf staat. Dus al heb je op je server in bacula-dir.conf en bacula-sd.conf staan dat er meerdere jobs tegelijk mogen lopen, de client fd.conf het uiteindelijk bepaald.
Een andere optie is dat omdat we naar bestand schrijven (al is het een aparte pool, en dus ook bestand), dat de SD een lock maakt op de storage unit en daarom maar 1 taak tegelijk afhandelt. Beetje het idee als maar 1 tape drive hebben en er met 3 clients tegelijk op proberen te schrijven. Zou je 3 tape drives hebben, 1 per client, dan wil Bacula het wel.

Dat laatste klinkt het meest aannemelijk. Wellicht dat een mailtje in de Bacula mailing list gooien meer info bied dan hier. Blijkbaar heeft iemand anders hetzelfde idee gehad: http://adsm.org/lists/htm...ers/2010-04/msg00548.html
Laat me weten hoe dit werkt :).

Commandline FTW | Tweakt met mate


Acties:
  • 0 Henk 'm!

  • Boudewijn
  • Registratie: Februari 2004
  • Niet online

Boudewijn

omdat het kan

Topicstarter
Nou ja je leest dat je meerdere SDs moet hebben, maar dat lijkt me nou net niet handig met file-based opslag.
Als in: het is wel lekker om per dag 1 file te hebben met je data, lijkt mij?

i3 + moederbord + geheugen kopen?


  • Hero of Time
  • Registratie: Oktober 2004
  • Nu online

Hero of Time

Moderator LNX

There is only one Legend

Ik heb per job een bestand. Momenteel zijn dit er een aantal. Zo heb ik voor de user homes (mijn documenten), profiles (laptop gebruikers) en tsprofiles (voor de terminal server) aparte pools met dus aparte bestanden. Dat 2x, 1 voor full backup en 1 voor incremental. Op die manier zou het veel prettiger zijn als je naar elk bestand tegelijk kan schrijven, dus homes en profiles en tsprofiles tegelijk, ipv eerst homes, dan profiles, dan tsprofiles. Voeg er een paar clients bij en je zit lekker te wachten tot alles klaar is.
Nou is het bij mij redelijk klein, maar als je wat groter bent en meer servers hebt (en dus clients), kan 't behoorlijk in de weg gaan zitten.

Commandline FTW | Tweakt met mate


Acties:
  • 0 Henk 'm!

  • Boudewijn
  • Registratie: Februari 2004
  • Niet online

Boudewijn

omdat het kan

Topicstarter
Heeft dat eigenlijk nog voor of nadelen om niet per job een file te hebben?
Als in: behalve concurrency, waarbij je dus per job een eigen file schijnt te moeten hebben.

Ik zit er over te twijfelen om dan idd maar van de grote alles-in-een files af te stappen.

i3 + moederbord + geheugen kopen?


Acties:
  • 0 Henk 'm!

  • Hero of Time
  • Registratie: Oktober 2004
  • Nu online

Hero of Time

Moderator LNX

There is only one Legend

Ik vind het persoonlijk overzichtelijker om per job/client een bestand te hebben. Zo weet je gelijk waar de bestanden vandaan komen en als je iets wilt wijzigen aan het pad of de naam, hoef je maar een paar kleine dingen aan te passen, ipv je gehele config.

Morgen ben ik weer aan het werk, na een week vakantie, en zal dan wat verder zoeken naar dit. Want momenteel loopt een full backup mis ivm het geven van een naam (wat belachelijk is, dan hij deed het een paar weken geleden prima) en is er nog 1 bezig die ergens middernacht ofzo pas klaar zal zijn (500 GB). Het schema voor zondag zal ik ook gelijk aanpassen, 10:00 is wat laat als je alles klaar wilt hebben voordat mensen weer beginnen op maandag :P.

Commandline FTW | Tweakt met mate


  • Hero of Time
  • Registratie: Oktober 2004
  • Nu online

Hero of Time

Moderator LNX

There is only one Legend

Ik heb wat leuks gezien op 't web, en danwel hier: http://www.backupcentral....m-concurrent-jobs-109210/
Er staat het volgende:
There are 5 or more places to set it depending on the concurrency you
want (client, storage ...) between bacula-dir.conf and bacula-sd.conf.

Also you have to understand that only 1 pool can be loaded at a time
for a storage device so if you want multiple jobs to run to multiple
pools concurrently you need multiple storage devices.
Omdat je alles in 1 bestand smijt, dus 1 pool, zal je nooit concurrent jobs werkend krijgen. Nog een reden om het te scheiden.
Ik lees het even nog een keer extra en begrijp dus dat je voor elke pool die je tegelijk wilt laten lopen, een aparte storage sectie moet hebben. Dus Pool1 gebruikt Storage1, Pool2 gebruikt Storage2, etc.

Ik heb mijn config aangepast zodat het bij de director, sd, en clients staat. Dit laatste had ik niet en is denk ik de oorzaak dat het bij mij niet werkt. Maar ik heb nog geen aparte storage devices opgegeven, dat doe ik morgen. Vanavond vanaf 22:00 weet ik of het daadwerkelijk nodig is, aangezien er twee jobs zijn die redelijk snel klaar zijn na elkaar. En de start time zie je gelukkig ook in de mail.

Ik ga nog verder kijken hoe dat met de storage ding zit, of het mogelijk is om meerdere file storages te hebben die naar dezelfde locatie schrijft. Anders wordt het mappen aanmaken per client/job.

Commandline FTW | Tweakt met mate


Acties:
  • 0 Henk 'm!

  • Boudewijn
  • Registratie: Februari 2004
  • Niet online

Boudewijn

omdat het kan

Topicstarter
Goed tijd voor een update, ik heb mijn backup helemaal uitgesplitst:

code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
JobDefs {
  Name = "www-weekly"
  Type = Backup
  Level = Incremental
  Client = www
  FileSet = "Full Set"
  Schedule = "WeeklyCycle"
  Storage = leiden-filestorage
  Messages = Standard
  Pool = wwwPool
  Priority = 10
}



Job {
  Name = "wwwjob"
  JobDefs = "www-weekly"
  Write Bootstrap = "/var/lib/bacula/www.bsr"
}

Client {
  Name = www
  Address = www.KNIP
  FDPort = 9102
  Catalog = MyCatalog
  Password = "KNIP"          # password for FileDaemon
  File Retention = 30 days            # 30 days
  Job Retention = 6 months            # six months
  AutoPrune = yes                     # Prune expired Jobs/Files
}


Pool {
  Name = wwwPool
  LabelFormat = "wwwVol"
  Pool Type = Backup
  Recycle = yes                       # Bacula can automatically recycle Volumes
  AutoPrune = yes                     # Prune expired volumes
  Volume Retention = 365 days         # one year
  Volume Use Duration = 23h
}

Deze wordt geinclude (met meer dezelfde configs maar dan met andere hosts/passwords) in bacula-dir.conf.

En dan mijn bacula-sd.conf:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
root@leiden:/etc/bacula# cat bacula-sd.conf  | grep -v "^#" | grep -v "^$"
Storage {                             # definition of myself
  Name = leiden-filestorage
  WorkingDirectory = "/var/lib/bacula"
  Pid Directory = "/var/run/bacula"
  Maximum Concurrent Jobs = 50
  SDAddresses = {
        ip = { addr = 192.168.1.44; port = 9103 }
        ip = { addr = 127.0.0.1; port =9103 }
  }
}
Director {
  Name = leiden-dir
  Password = "*"
}
Director {
  Name = leiden-mon
  Password = "*"
  Monitor = yes
}
Device {
  Name = leiden-filestorage
  Media Type = File
  Archive Device = /bacula
  LabelMedia = yes;                   # lets Bacula label unlabeled media
  Random Access = Yes;
  AutomaticMount = yes;               # when device opened, read it
  RemovableMedia = no;
}
 
Messages {
  Name = Standard
  director = leiden-dir = all
}



En mijn bijzonder boeiende client:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
Director {
  Name = leiden-dir
  Password = "*"
}

Director {
  Name = www.*-mon
  Password = "*"
  Monitor = yes
}

FileDaemon {                          # this is me
  Name = www.*-fd
  FDport = 9102                  # where we listen for the director
  WorkingDirectory = /var/lib/bacula
  Pid Directory = /var/run/bacula
  HeartBeat Interval = 15
  Maximum Concurrent Jobs = 20
  FDAddress = *
}

Messages {
  Name = Standard
  director = www.*-dir = all, !skipped, !restored
}


Ook weer eea weggehaald. Als ik alles goed lees zou dit voldoende moeten zijn voor concurrency, maar het wil nog steeds niet.

Ben jij verder gekomen?

i3 + moederbord + geheugen kopen?


Acties:
  • 0 Henk 'm!

  • Hero of Time
  • Registratie: Oktober 2004
  • Nu online

Hero of Time

Moderator LNX

There is only one Legend

Ja, ik ben verder gekomen. Ik had eerst maar 1 storage device, maar omdat het werkt als een tape-drive, lockt hij zichzelf als 't een bestand schrijft. Dus krijg je alsnog je jobs in serie. Ik heb per client een storage sectie gemaakt en dat per pool aangegeven (elke job heeft bij mij een eigen pool ivm aparte filesets). Zo kan ik dus elke client parallel laten lopen, waarbij de taken per client in serie gaan.
Client1 - Storage1
Client2 - Storage2
Job1 - Client1
Job2 - Client1
Job3 - Client2
Jobs 1 en 3 lopen tegelijk, jobs 1 en 2 na elkaar.

En ja, je SD en Director config wordt nogal groot hiermee omdat je dingen dubbel aan het definiëren bent. Je kan overigens wel alles in 1 map laten komen, je hoeft niet per storage een aparte map op te geven.

Commandline FTW | Tweakt met mate


Acties:
  • 0 Henk 'm!

  • Boudewijn
  • Registratie: Februari 2004
  • Niet online

Boudewijn

omdat het kan

Topicstarter
Naar aanleiding van een ander topic ben ik hier weer naar aan het kijken geslagen en inderdaad lijk je de oplossing gevonden te hebben.
Punt is wel dat ik toen afgehaakt ben omdat ik met de hand veel moet gaan instellen, namelijk per host:
  • Job
  • Pool
  • Storage
  • Client
Nu ga ik dat gewoon met puppet doen, en eens kijken hoe effectief dat wordt ;).

i3 + moederbord + geheugen kopen?

Pagina: 1