Newsgroup: it.comp.os.linux.sys
Titolo: Bacula, suddivisione in directory e restore diretto

Ciao,
la mia esperienza con bacula prosegue.
Sono riuscito a strutturare i backup in un
modo quasi perfetto.
Salvo un file per ciascun backup, per ciascun host.
A lungo andare, però, mi ritroverei con migliaia di
file di volume tutti nella stessa directory.
Esiste un modo per suddividerli in sottodirectory?
Ad esempio:
/var/bacula/backups/nome_client/2010/05/20100531-incr
Altra cosetta: c'è modo di ripristinare i file direttamente
sul server backuppato anzichè in locale?
Al momento se faccio un restore il file mi viene ripristinato
localmente, sicuramente a causa del job generico inerente il
restore. Non sono capace, però, a creare un job di restore
per ciascun client.
Qualche aiuto?

 directory con i file 'backuppati' alla directory finale,
Il problema è che poi devo fare la procedura inversa anche
per il restore, altrimenti il buon bacula non si trova più
i volumi.
non mi pare una gran soluzione, ma meglio che niente...
grazie comunque.

 sul server backuppato anzichè in locale?
Quando fai il restore puoi specificare il client e lo storage (sempre 
intesi come risorse bacula). E0 da un po che non faccio un restore con 
bacula ma puoi ragionare nel modo segunete: lo storage è la sorgente, 
il client è la destinazione del restore. Attento però a non fare un 
restore sovrscrivendo i dati originali (a meno che tu non voglia propio 
questo).

 questo).
Questo me lo rileggo con calma domani. :)



On 2010-06-08 00:19:04 +0200, Gandalf Corvotempesta said:






Ne ho 4 full e circa 24 tra incrementali e differenziali,
 


totale 28 file circa, 1 mese intero su per giù.




Nulla di che quindi.




Te quindi crei uno storage per ciascun client da backuppare?


Io ho fatto uno storage unico ecco il perchè della mia domanda.




Certo, mi pare di aver fatto così anche sui file di esempio che di spedii qualche tempo fa.






Questo me lo rileggo con calma domani. :)




Si penso che quando avrai preso in mano la gestione degli storage andrai via liscio ...





 spedii qualche tempo fa.
Non ci ho fatto caso, li per li.
Vedrò di spostare la sezione storage dentro ciascun client.
Meglio farlo adesso con 30 server backuppati che con 300

 spedii qualche tempo fa.
Diventa una configurazione impossibile da gestire se si
hanno parecchi host (per parecchi intendo valori
superiori al 100)
Per ogni client da backuppare dovrei creare il job, lo storage, il
device e altre cosette.
Come da suggerimento di riki, potrei creare per ciascun client
un Run Script che mi sposta i file di volume in sottodirectory.
Il problema poi sarebbe come farne il restore.
In tal caso, basterebbe fare un Run Script inverso che riporta
i volumi nella directory "standard", ora faccio delle prove, almeno
con 2 definizioni extra risolvo, senza impazzire con gli storage
differenti per ciascun host.
-- 
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito è di fare il possibile per la
salvezza degli anni nei quali viviamo,
sradicando il male dai campi che conosciamo.

 differenti per ciascun host.
Il backup funziona, riesco a spostare i volumi al posto giusto.
Stavo però testando il restore, e sembrerebbe che gli eventuali
comandi "Before Job" vengano eseguiti prima del job, ma dopo il
mount del volume.
Ed ovviamente il mount del volume non va a buon fine perchè il
file non si trova dove dovrebbe essere (viene spostato dal
mio script subito dopo il backup).
Qualche idea su come eseguire un comando subito prima del
mount del volume? Vorrei fare un link simbolico...


 
La cosa che non capisco è come fai a stabilire quale directory linkare 
all'interno del job di restore, potresti aiutarmi a capire?
Hai provato a guardare il parametro 'Mount Command' del file di 
configurazione dello Storage (che forse potrebbe esserti di aiuto anche 
in fase di backup per evitare lo spostamento successivo)?

 in fase di backup per evitare lo spostamento successivo)?
Non va bene, perchè non consente di comunicare allo script ne il
nome del client, quindi non riuscirei a sapere da quale directory
pescare il volume, ne il nome del volume, quindi non saprei nemmeno
quale file linkare.


 quale file linkare.
Secondo me, a questo punto, ti converebbe fare un script che aggiorni 
le configurazioni di bacula quando voi aggiungere un server (alla fine 
sono semplici file di testo).
Qualcosa tipo:
./bacula_add_new_server Nome_Server FileSetFile Director
Questo script si preoccuperà di creare le varie risorse (Client, File 
Set, Pool, Storage, ecc ... )
Se poi codifichi i nomi in modo opportuno e magari delimiti le varie 
sezioni con marcatori opportuni (ad esempio con commenti ad hoc), 
potrebbe diventare gestibile anche la rimozione del singolo server da 
bacula ...

 differenti per ciascun host.
Emerge un secondo problema, forse più grave:
spostando i volumi, bacula non li elimina una volta
scaduti.
Faccio fatica a credere che per suddividere in directory
si debba creare uno storage per ciascun client.
Se avessi 300 client, avrei 300 storage da gestire, 300
configurazioni di client, 300 Job....
Impossibile, per un prodotto "enterprise"


 si debba creare uno storage per ciascun client.
Bon, ho ristrutturato la configurazione per utilizzare storage
differenti, ciascuno in una directory dedicata ad un singolo
client.
Funziona, però capita una cosa singolare.
Il backup automatico, su alcuni client, da errore:
Cannot find any appendable volumes.
Please use the "label"  command to create a new Volume for:
    Storage:
"FileStorage-mioclient" (/var/bacula/backups/clients/mioclient)
    Pool:         Inc-Pool
    Media type:   File
Se però vado con bconsole ed eseguo manualmente il backup tramite
il comando "run" lui parte alla perfezione.
Che caspita può essere? Alla fin fine, "run" esegue la stessa cosa
che farebbe il sistema automatico.

 
Non ne vengo a capo.
Nella configurazione del director io ho,
per ciascun client:
Job {
   Name = "client-miocomputer"
   Client = miocomputer-fd
   JobDefs = "JobPredefinito"
   Storage = "storage-miocomputer"
}
Client {
   Name = miocomputer-fd
   Address = 172.17.0.11
   FDPort = 9102
   Catalog = Catalog
   Password = "ARm7qyF3lJSBKJ9NRICUj+Ry3PRJ3EZN92EnilHFVb8/"
   File Retention = 30 days
   Job Retention = 6 months
   AutoPrune = yes
}
Storage {
    Name = "storage-miocomputer"
    Maximum Concurrent Jobs = 20
    Address = 172.17.0.1
    Device = "FileStorage-miocomputer"
    Password = "8GGBGvyuXppCgc3YxoPe5nDiX5yYhKIO22gmITaKg"
    Media Type = "File-miocomputer"
}
Mentre nella configurazione dello storage, per ciascun client, ho:
Device {
    Name = "FileStorage-miocomputer"
    Media Type = "File-miocomputer"
    Archive Device = "/var/bacula/backups/clients/miocomputer"
    LabelMedia = yes;
    Random Access = Yes;
    AutomaticMount = yes;
    RemovableMedia = no;
    Requires Mount = no;
    AlwaysOpen = no;
}
Sembra tutto corretto.
Se eseguo manualmente un backup da bconsole, tutto funziona.
I backup schedulati però muoiono con il seguente errore:
"Cannot find any appendable volumes.
Please use the "label"  command to create a new Volume"
Come è possibile che un backup manuale funzioni mentre lo schedulato
no? La documentazione non mi è di aiuto, non riesco a capire se è
normale che le due operazioni di backup si comportino differentemente.


     Media type:   File
Scusate, ma con il LabelMedia impostato a yes dentro
un "Device", non dovrebbe fare il label in automatico?
Io ho:
Device {
    Name = "FileStorage-miocomputer"
    Media Type = "File-miocomputer"
    Archive Device = "/var/bacula/backups/clients/miocomputer"
    LabelMedia = yes;
    Random Access = Yes;
    AutomaticMount = yes;
    RemovableMedia = no;
    Requires Mount = no;
    AlwaysOpen = no;
}
Ed il LabelMedia è impostato a yes.
Poi dentro il Pool ho:
Pool {
    Name = Inc-Pool
    Pool Type = Backup
    Recycle = yes
    AutoPrune = yes
    Volume Retention = 1 month
    Maximum Volume Jobs = 1
    Label Format = "${Year}${Month:p/2/0/r}${Day:p/2/0/r}_${Hour:p/2/0/r}h
${Minute:p/2/0/r}m-incremental"
}
Dovrebbe fare il label da solo.... eppure non lo fa.
Resta in attesa.
