Newsgroup: it.comp.os.linux.sys
Titolo: Bacula: rimozione pool

Ho un server di backup piuttosto incasinato. Per strani motivi, mi ritrovo molti client ad avere decine di incrementali e differenziali senza un full.
 
Ora: è corretto dire che sia incrementali che differenziali, senza full, sono inutilizzabili ? (c'è anche solo una remota possibilità di ripristinare file dal loro intero?)
 
Nel caso fossero inutilizzabili, c'è qualche modo per eliminare tutta questa schifezza (e liberare tanto, tanto spazio) in automatico? Vorrei evitare di fare uno script, nel caso esistesse qualche strumento già pronto.

Ciao,
la rimozione dei backup vecchi è un problema con cui mi sono scontrato anche 
io e non ho trovato un sistema automatizzato ma solo una serie di procedure 
da fare in sequenza, te li incollo brutalmente qui
 
echo "list volumes" | bconsole | grep "Purged" | awk {'print $4'} | wc -l
 
clients=`mysql -uroot -p -e'select Name from Client ORDER BY Name ASC;' 
bacula | tail -n+2`
 
for client in `echo $clients`; do   echo "prune files client=${client} yes" 
| bconsole; donefor f in `echo "list volume" | bconsole | grep Purged | cut 
-d ' ' -f6`; do   echo "delete volume=$f yes"; done
 
cd /backup/data
 
for i in `find . -maxdepth 1 -type f -printf "%f\n"`; do   echo "list 
volume=$i" | bconsole | if grep --quiet "No results to list"; then         
echo "$i is ready to be deleted";   fi; done
 
for f in `echo "list volume" | bconsole | grep Purged | cut -d ' ' -f6`; do   
echo "delete volume=$f yes" | bconsole; done
 
for i in `find . -maxdepth 1 -type f -printf "%f\n"`; do   echo "list 
volume=$i" | bconsole | if grep --quiet "No results to list"; then         
echo "$i is ready to be deleted";   fi; done
 
touch -t 201501010000 /tmp/timestamp
 
find . -type f ! -newer /tmp/timestamp
 
find . -type f ! -newer /tmp/timestamp -exec rm {} \;
 
non so se ho capito il tuo problema ma se c'è qualcuno che ne sa di più avrà 
la mia eterna gratitudine e una birra pagata se passa da Lucca ;-)
 
Umberto


 la mia eterna gratitudine e una birra pagata se passa da Lucca ;-)
 
E' già qualcosa, anche se in teoria Bacula dovrebbe fare il prune in automatico.
 
Però, ciò che mi serve, è poter cancellare tutti i backup inutilizzabili, ad esempio, mi ritrovo con situazioni simili:
 
1. incrementale
2. incrementale
3. differenziale
4. incrementale
5. full
6. incrementale
7. incrementale
8. differenziale
9. incrementale
 
 
I backup dal 5 al 9 vanno bene. Quelli da 1 a 4 sono tecnicamente inutilizzabili e vorrei rimuoverli, occupano spazio e non permettono il restore.
 
C'è modo di farlo in automatico? Qualcuno ha mai creato una query simile?
 

 E' già qualcosa, anche se in teoria Bacula dovrebbe fare il prune in automatico.
 
Uso Bacula in un contesto molto particolare, quindi magari non ricordo bene.
 
Ma se ricordo bene, bacula usa due ''tempi di prune'': uno è il prune dal
DB, l'altro è il prune dei media.
 
La situazione dei media è sempre ricostruibile ''a mano'' con i comandi b*,
ergo: non è che il primo prune è troppo veloce, lui fa backup correttamente
ma tu cancelli troppo presto dal db e quindi non ''vedi'' i full che
comunque ci sono?
 
-- 
  La differenza tra una dittatura e una democrazia e' che in democrazia poi
  si vedono le foto.		(Dose e Presta, Il ruggito del Coniglio)

 comunque ci sono?
 
Guarda, sarò sincero, non te lo so dire. Non ci ho mai capito più di tanto.
Ho una configurazione che è in piedi da alcuni anni e 9 volte su 10 funziona correttamente, ma quella volta che si blocca impiego giorni per venirne a capo ma senza mai risolvere il problema, quindi riparte per un po, poi si riblocca etc etc etc.
 
Voglio trovare una soluzione definitiva, qualcuno di voi ha una configurazione così composta:
 
full ogni 1° del mese
differenziale ogni domenica notte
incrementale ogni notte
 
Devo poter ripristinare fino a 15 giorni e credo sia questo il mio problema. Non so come si fa. 
La schedulazione funziona correttamente, ho anche impostato l'upgrade dei job nel caso fosse inconsistente (ad esempio, un incrementale senza full viene convertito in full) ma vorrei che bacula gestisse, in automatico, il prune di tutto ciò che è più vecchio di 15 giorni senza però compromettere i backup.
Se ad esempio mi facesse il prune del Full del 1° luglio, che il 1° di agosto avrebbe 30 giorni di vita, mi renderebbe inutilizzabili tutti i differenziali e gli incrementali successivi e di conseguenza il mio restore a 15 giorni va a farsi benedire.
 
Se qualcuno mi potesse postare una configurazione funzionante, in modo da poter fare copia-incolla, ne sarei grato. La mia sulla carta funziona, ma di tanto in tanto si inchoda e non riesco a capire un motivo.
 
Sulla carta sembra semplice, ma io ho più client (splittati per file, ma questo è semplice, è un include nella configurazione) che scrivono su più File Storage per permetterne il backup simultaneo.
 
Mi arrendo.

 Mi arrendo.
 
Io mi sono arreso il giorno che ho letto la documentazione di Bacula, 
decidendo di scrivermi un sistema di backup tutto mio[1] ;)
 
Enrico
[1] a dire il vero avrei voluto usare molto volentieri AMANDA, ma il fatto 
che il client Windows funzionasse ad minchiam e che all'epoca si basava su 
GNU Tar di Debian, che non prevedeva il salvataggio delle ACL impostate sui 
file, hi ma fatto desistere...

 decidendo di scrivermi un sistema di backup tutto mio[1] ;)
 
Quindi non sono l'unico a non capirci assolutamente niente.
Ammetto di avere un sistema che sta in piedi e non so nemmeno perchè.
 
Alternative ?
 
Se almeno ci fosse un libro o un bel tutorial con qualche esempio di utilizzo , mi fionderei a comprarlo o a leggerlo
 
Tutto ciò che ho letto spiega come backuppare pochi sistemi ed in maniera piuttosto dozzinale, che per bacula è un controsenso, è come usare un bazooka per sparare alle mosche.
 
La documentazione ufficiale è ridicola.

 Alternative ?
 
Dipende da cosa ti serve. Ad occhio, ti potrei dire di provare o AMANDA, o 
Bareos (quest'ultimo e` un fork di Bacula con qualche miglioria). 
Personalmente, le esigenze che mi hanno portato a scrivere un applicativo di 
mia mano sono state:
 
 - Dataset "puliti", ovvero la possibilita` di avere un file as is, da 
prendere e copiare alla bisogna (a dirla bene applico una compressione, ma 
e` gzip).
 - Dataset completi, ovvero la macchina x deve avere tutti i file necesari 
al restore sia sul dataset 1 che sul dataset 2.
 - Salvataggio di attributi e ACL, non su disco ma su database, e che fosse 
possibile risalire al nome reale dell'utente o del gruppo.
 - Possibilita` di lanciare comandi sul server remoto, in modo da poter 
utilizzare i tool specifici degli applicativi.
 
Il risultato e` un applicativo in due parti (client e server che comunicano 
sia in chiaro che via ssl), che salva i metadati su database (Firebird, ma 
sto passando a PostgreSQL) che salva i file su disco (e li comprime se  
richiesto) e che li hardlinka tra un dataset e l'altro :)
 
Enrico

 al restore sia sul dataset 1 che sul dataset 2.
 
? Quindi non fai mai incrementali ma sempre e solo full ?
 
Comunque sia, delle svariate soluzioni da me provate, la "migliore" e più semplice da configurare è BackupPC. Il problema è che fa uso di rsync, ed in caso di server con migliaia o milioni di file da backuppare, l'avvio del backup richiede svariate ore. Mi son ritrovato con alcuni log-server da backuppare che dopo 2 giorni erano ancora fermi in "Building file list..."
 
Altro problema è che rsync è un mattone, con bacula backuppo la stessa cosa ma il load sul server è decisamente inferiore. rsync è più lento e più pesante allo stesso tempo. Se BackupPC non avesse questo "problema" sarebbe la soluzione di backup perfetta nel mio ambito.


Io ci ho messo un po' a capire come far funzionare l'aggeggio, ma dopo 
qualche mese avevo messo su un doppio sistema disco/DAT che mi faceva 
4-6 mesi di backup e funzionava come un orologio, a patto di non 
togliere il nastro da dentro l'unità DAT, se non quando richiesto da 
Bacula (se dovevo fare un restore, poi era 100% sicuro che il nastro 
in quel momento aperto per la scrittura venisse etichettato "Error").
Quel sistema mi ha permesso:
- un full restore di un server Windows2008 e di due server Centos5 
quando il NAS che loro usavano come storage è schiattato;
- diversi restore di file singoli/directories.
 
Poi mi hanno defenestrato e tutto il mio lavoro è stato buttato alle 
ortiche...
 
Per quanto riguarda i restore, mi ricordo che il problema era 
l'interfaccia grafica: se facevo il restore da bconsole trovavo quello 
che volevo senza problemi, mentre BAT faceva un sacco di pasticci.
 
 
 
 
 


Premetto che il mio sistema Bacula è stato defenestrato insieme al 
sottoscritto da quasi un anno, quindi mi riferirò a quello che ricordo.
 
Il mio Bacula era un sistema sperimentale, volto a cambiare il sistema di 
backup dell'azienda per cui lavoravo, spendendo il meno possibile.
L'idea era quella di usare parti trovate in cantina, e poi riutilizzare 
l'unità LTO-1 che era in uso in quel momento con ntbackup.
 
Ho quindi usato un DAT DDS-4 HP, montato su un pc con Debian 6.
 
Bacula era in versione 5.2.10.
 
A giudicare da quello che scrivi, sembra che ci siano problemi nelle sezioni 
di scheduling e nei periodi di retention dei job (e dei file).
 
Il mio sistema era abbastanza stabile, funzionava senza grossi intoppi 
tranne quando rientravamo dalle ferie.
 
Io usavo questi due scheduling (bacula-dir.conf):
 
Schedule {
  Name = "WeeklyCycle"
  Run = Full 1st sun at 23:05
  Run = Differential 2nd-5th sun at 23:05
  Run = Incremental mon-sat at 23:05
}
 
Schedule {
  Name = "WeeklyCycleGiorno"
  Run = Full 1st mon at 17:45
  Run = Differential 2nd-5th sun at 12:15
  Run = Incremental mon-sat at 12:15
}
 
Nel caso la prima domenica non fosse disponibile il client, il backup andava 
in errore ed il full non veniva eseguito.
Visto che non hai full, dovresti controllare in bconsole che cosa ti dice 
quando è previsto il full.
Per la cancellazione automatica ci sono diversi parametri, i principali sono 
FileRetention e JobRetention.
Quando un file archiviato supera il periodo di FileRetention, viene 
cancellato da database (ma non dal volume).
Quando il Job eseguito supera il periodo di JobRetention, viene cancellato 
dal database.
Un file cancellato non è più ripristinabile singolarmente, ma può essere 
recuperato insieme a tutto il Job.
 
Quindi dovresti controllare i periodi di retention dei file, dei job e dei 
volumi:
 
JobDefs {
  Name = "DefaultWindowsGiorno"
  Type = Backup
  Level = Full
  Client = xp13-dev-fd
  FileSet = "Windows Disco Completo"
  Schedule = "WeeklyCycleGiorno"
  Storage = DDS-4
  Messages = Standard
  Pool = Nastro
  Priority = 10
  Write Bootstrap = "/var/lib/bacula/%c.bsr"
}
 
Job {
  Name = "BackupXP13"
  Client = xp13-dev-fd
  JobDefs = "DefaultWindowsGiorno"
  Spool Data = yes
}
 
Client {
  Name = xp13-dev-fd
  Address = 172.16.20.37
  FDPort = 9102
  Catalog = MyCatalog
  Password = "xp13-dev-skbackup"
 
  File Retention = 30 days        	# 30 days
  Job Retention = 6 months        	# six months
  AutoPrune = yes                 	# Prune expired Jobs/Files
}
 
# Default pool definition
Pool {
  Name = Nastro
  Pool Type = Backup
  Recycle = yes                   	# Bacula can automatically recycle Volumes
  AutoPrune = yes                 	# Prune expired volumes
  Volume Retention = 365 days     	# one year
}
 
Tieni presente che Bacula considera globali alcune impostazioni e se non 
specifichi espressamente, usa quelle.
Da quanto scrivi, sembra che tu non usi i nastri, ma dei file, quindi 
potresti avere una sezione Pool come questa:
 
Pool {
  Name = Disco
  Pool Type = Backup
  Recycle = yes                   	# Bacula can automatically recycle Volumes
  AutoPrune = yes                 	# Prune expired volumes
  Volume Retention = 30 days      	# one month
  Maximum Volume Bytes = 2G       	# Limit Volume size to something 
reasonable
  Maximum Volumes = 100           	# Limit number of Volumes in Pool
}
 
Se vuoi liberare spazio manualmente, puoi farlo tramite BAT, se non ricordo 
male dalla sezione "Jobs" cancelli i job più vecchi, poi metti "Recycle" ai 
volumi che non hanno più job.
 
HTH
 

 potresti avere una sezione Pool come questa:
 
Faccio backup su disco (1 volume per ciascun client per ciascun livello di backup per ciascun job: in 2 parole: 4 incrementali creano 4 file distinti per ciascun client)
 
Credo che uno dei miei problemi sia la retention dei file, al momento sto eseguendo un myisamchk sulle tabelle per liberare spazio (ho liberato quasi 1TB!) appena termina, riavvio il server e posto le retention, magari possono essere accorciate oppure vanno allungate per evitare di cancellare volumi di cui necessita bacula
 
Resta comunque il fatto che la documentazione è finta e di alcun aiuto.
BackupPC, meno potente ma comunque molto flessibile, si configura in 5 minuti e non mi ha mai dato problemi (prima di sostituirne una parte con Bacula, ha avuto in attivo 68 server backuppati tutti i giorni, ZERO problemi in 5 anni, a parte la lentezza disumana di rsync)

 sarebbe la soluzione di backup perfetta nel mio ambito.
 
Secondo me AMANDA fa quello che cerchi senza troppi sbattimenti. Se poi vuoi 
provare il mio sistema, basta chiedere ;)
 
Enrico

 provare il mio sistema, basta chiedere ;)
 
Per Amanda c'è un libro o un qualcosa che mi posso leggere al mare con calma o una documentazione "vera" ? (siamo seri, non lo leggerò mai al mare, ma dirlo mi fa sembrare molto più professionale)
 
Il tuo sistema con cosa l'hai fatto ? C? Perl ?
 

 Secondo me AMANDA fa quello che cerchi senza troppi sbattimenti.
 
Sembrerebbe faccia al caso mio, già aver letto che i dump sono sostanzialmente dei tar con eventuale compressione, mi ha fatto brillare gli occhi.
 
Ma anche in questo caso la documentazione è finta, anzi, forse è persino peggio di quella di Bacula.

 Il tuo sistema con cosa l'hai fatto ? C? Perl ?
 
Beh, da questo punto di vista ha una vita travagliata :)
Ho cominciato a scriverlo in Python 2 con Paramiko (ovvero si connetteva via 
SSH alla macchina e si scaricava i file tramite scp). Quando ho compreso che 
mi serviva un client Windows, sono passato a Java (e` attualmente la 
versione piu` completa e funzionante, ed e` veloce ;) ). Dopodiche` ho 
tentato una riscrittura in Python3, ma ho dovuto desistere a causa della 
politica di gestione delle versioni di Python da parte delle distribuzioni e 
da come gestisce la distribuzione delle applicazioni. Ora l'ho completamente 
riscritto in Go (che rispetto a Python occupa meno RAM in memoria e risolve 
drammaticamente la questione della distribuzione) e lo sto testando in 
questi giorni, ma comunque il funzionamento e la gestione rimane la stessa 
(gia` da ora mi sento di dire che funziona) :)
 
Enrico

 riscritto in Go (che rispetto a Python occupa meno RAM in memoria e risolve
 
come mai proprio il Go?
 
Ciao Jack
-- 
Yoda of Borg am I! Assimilated shall you be! Futile resistance is, hmm?

 forum ed il supporto professionale (sono gli stessi di BackupPC)
 
Se fai riferimento a questo Wiki:
http://wiki.zmanda.com/index.php/User_documentation
 
non penserai mica che io mi metta a leggere singolarmente tutte le manpages per solo capire come configurare il tutto vero? 
 
A me serve un manuale, saltare qua e la tra le manpages non è affatto divertente.
 
Ho un po di timore, andrei a sostituire un software che è composto da 3 singoli applicativi e con una documentazione finta, ma comunque lineare e scorrevole, con un altro composto da decine e decine di singoli componenti e con solo manpage da leggere senza alcun filo conduttore....

 componenti e con solo manpage da leggere senza alcun filo conduttore....
 
Boh, all'epoca, quando lo provai, non trovai la documentazione incasinata 
(se non ricordo male mi appoggiai ad un howto/tutorial). In ogni caso, 
una prova la si puo` sempre fare ;)
 
Enrico

 come mai proprio il Go?
 
Perche` e` semplice e lineare, e fa da perfetto complemento a Python. 
Personalmente, l'unica cosa che mi ha dato un po' fastidio e` che si, 
posso disabilitare il garbage collector, ma no, non posso liberare memoria 
a mano (non che sia un grosso problema, la punta massima di memoria che 
ho occupato sui client con il mio sistema e` stato 7Mb)
 
Enrico