Discussioni sul sistema operativo Linux
 

Bacula: rimozione pool

gandalf.corvotempesta@gmail.com 29 Mag 2015 12:48
Ho un server di backup piuttosto in*****ato. 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
******* 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.
Umberto Carrara 29 Mag 2015 16:25
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

gandalf.corvotempesta@gmail.com wrote:

> Ho un server di backup piuttosto in*****ato. 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 ******* 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.
gandalf.corvotempesta@gmail.com 29 Mag 2015 16:50
Il giorno venerdì 29 maggio 2015 16:23:08 UTC+2, Umberto Carrara ha scritto:
> 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
>
[CUT]
>
> 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 ;-)

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?
Marco Gaiarin 4 Giu 2015 15:37
Mandi! gandalf.corvotempesta@gmail.com
In chel di` si favelave...

> 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)
gandalf.corvotempesta@gmail.com 9 Giu 2015 11:03
Il giorno giovedì 4 giugno 2015 22:20:08 UTC+2, Marco Gaiarin ha scritto:
> 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?

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
******* 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 ******* ma
questo è semplice, è un include nella configurazione) che scrivono su più
******* Storage per permetterne il backup simultaneo.

Mi arrendo.
Enrico Bianchi 11 Giu 2015 00:03
gandalf.corvotempesta@gmail.com wrote:

> 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
******* hi ma fatto desistere...
gandalf.corvotempesta@gmail.com 11 Giu 2015 00:13
Il giorno giovedì 11 giugno 2015 00:03:25 UTC+2, Enrico Bianchi ha scritto:
> gandalf.corvotempesta@gmail.com wrote:
> Io mi sono arreso il giorno che ho letto la documentazione di Bacula,
> 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.
Enrico Bianchi 11 Giu 2015 22:57
gandalf.corvotempesta@gmail.com wrote:

> 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 ******* 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 ******* 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 ******* su disco (e li comprime se
richiesto) e che li *****linka tra un dataset e l'altro :)

Enrico
gandalf.corvotempesta@gmail.com 12 Giu 2015 18:07
Il giorno giovedì 11 giugno 2015 22:57:32 UTC+2, Enrico Bianchi ha scritto:
> 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).

Interessante, anche solo per il supporto a Ceph o Gluster.
Ma la documentazione è ugualmente ridicola, quindi non risolverei molto.

> Personalmente, le esigenze che mi hanno portato a scrivere un applicativo di
> mia mano sono state:
>
> - Dataset "puliti", ovvero la possibilita` di avere un ******* as is, da
> prendere e copiare alla bisogna (a dirla bene applico una compressione, ma
> e` gzip).

Si, questo farebbe comodo anche a me.
Chissà perchè bacula, che tiene tutti i "metadati" salvati su DB, non utilizza
tar come struttura dati.
E' semplice, performante e se hai salvato su DB i nomi dei ******* fai anche
presto a trovarli, fai una interrogazione e trovi il volume tar corrispondente.

> - Dataset completi, ovvero la macchina x deve avere tutti i ******* necesari
> 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 ******* 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 ******* 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.
Quasimodo (at home) 13 Giu 2015 20:01
Enrico Bianchi wrote:

> gandalf.corvotempesta@gmail.com wrote:
>
>> 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 ******* hi ma fatto desistere...

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 ******* 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.
Quasimodo (at home) 14 Giu 2015 20:45
gandalf.corvotempesta@gmail.com wrote:

> Ho un server di backup piuttosto in*****ato. 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 ******* 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.

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 ******* (e dei ******* .

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 ******* archiviato supera il periodo di FileRetention, viene
cancellato da database (ma non dal volume).
Quando il ******* eseguito supera il periodo di JobRetention, viene cancellato
dal database.
Un ******* cancellato non è più ripristinabile singolarmente, ma può essere
recuperato insieme a tutto il *******

Quindi dovresti controllare i periodi di retention dei ******* dei ******* 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"
}
******* {
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"

******* Retention = 30 days # 30 days
******* 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 ******* 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 ******* più vecchi, poi metti "Recycle" ai

volumi che non hanno più *******

HTH
gandalf.corvotempesta@gmail.com 15 Giu 2015 09:57
Il giorno domenica 14 giugno 2015 20:48:02 UTC+2, Quasimodo (at ******* ha
scritto:
> Il mio sistema era abbastanza stabile, funzionava senza grossi intoppi
> tranne quando rientravamo dalle ferie.

Anche il mio lo è, il grosso dei problemi si presentano quando, ad esempio,
termina lo spazio su disco. I backup si bloccano (ovviamente) e poi divento
******* a farli ripartire, anche liberando spazio.

Inoltre, inspiegabilmente, nonostante tutti i volumi siano settati come
automount, spesso e volentieri Bacula si blocca in attesa di una mount request,
che devo eseguire manualmente da bconsole per riavviare il tutto.

Tolto questi due problemi, il backup va abbastanza bene. Ha funzionato bene per
un paio di anni, poi ha iniziato ad accartocciarsi senza apparente motivo e non
ne vengo più a capo.

> Da quanto scrivi, sembra che tu non usi i nastri, ma dei ******* quindi
> potresti avere una sezione Pool come questa:

Faccio backup su disco (1 volume per ciascun client per ciascun livello di
backup per ciascun ******* in 2 parole: 4 incrementali creano 4 *******
distinti per ciascun client)

Credo che uno dei miei problemi sia la retention dei ******* 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)
Enrico Bianchi 15 Giu 2015 11:25
gandalf.corvotempesta@gmail.com wrote:

> Chissà perchè bacula, che tiene tutti i "metadati" salvati su DB, non
> utilizza tar come struttura dati.

Presumibilmente, perche` tar non permette un sistema serio di deduplica del
dato, ovvero in ogni differenziale avresti il ******* completo e non solo i
dati cambiati. A detta di cio`, ammetto che io faccio lo stesso, ovvero
salvo l'intero ******* ma e` nell'ottica del mio sistema e di quello che
voglio

> ? Quindi non fai mai incrementali ma sempre e solo full ?

A dire il vero e` il contrario, ovvero faccio un solo full (quello iniziale)
e poi sempre e solo incrementali :)
Per farti capire, questo e` il funzionamento: dal server X scarico nel
dataset 1 i ******* pippo.txt e pluto.txt . I ******* hanno un hash (md5, che
per
questo tipo di lavoro e` perfetto) x e y. Parte il dataset 2. Per prima cosa
controllo se il ******* pippo.txt ha ancora hash x. In caso affermativo, faccio
un ******* link del ******* pippo.txt dal dataset 1 al dataset 2. In caso
negativo
lo riscarico e cosi` via per ogni ******* Il risultato e` quindi che a fine
operazione, ho sempre un dataset full, ma in realta` e` praticamente un
differenziale rispetto al dataset precedente

> Comunque sia, delle svariate soluzioni da me provate, la "migliore" e più
> semplice da configurare è BackupPC.

Lo provai, ma oggi come allora dovevi ricorrere a barbatrucchi per salvare
le ACL. Inoltre, allora come oggi, non ha un metodo semplice e pulito per
lavorare su Windows (in teoria c'e` un client, ma mi sembra un patchwork di
roba)

> Il problema è che fa uso di rsync, ed
> in caso di server con migliaia o milioni di ******* da backuppare, l'avvio
> del backup richiede svariate ore.

Ti diro`, anche io uso una (duplice) filosofia alla rsync, ma non l'ho mai
trovata cosi` lenta...

> Mi son ritrovato con alcuni log-server
> da backuppare che dopo 2 giorni erano ancora fermi in "Building ******* >
list..."

Questo non mi e` capitato, e devo dirti che la situazione con cui ero
partito per fare il mio sistema di backup era un server con gazzilioni di
******* :)

> Se BackupPC non avesse questo "problema"
> 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
gandalf.corvotempesta@gmail.com 15 Giu 2015 17:34
Il giorno lunedì 15 giugno 2015 11:25:43 UTC+2, Enrico Bianchi ha scritto:
> Presumibilmente, perche` tar non permette un sistema serio di deduplica del
> dato, ovvero in ogni differenziale avresti il ******* completo e non solo i
> dati cambiati. A detta di cio`, ammetto che io faccio lo stesso, ovvero
> salvo l'intero ******* ma e` nell'ottica del mio sistema e di quello che
> voglio

Allora non mi sono spiegato.
I differenziali/incrementali li fai con rsync, non con tar, ovviamente.
Ci pensa rsync a copiare solo i ******* variati, poi con tar unisci più archivi
e ti fai un singolo filettone facilmente trasportabile.

> Per farti capire, questo e` il funzionamento: dal server X scarico nel
> dataset 1 i ******* pippo.txt e pluto.txt . I ******* hanno un hash (md5, che
per
> questo tipo di lavoro e` perfetto) x e y. Parte il dataset 2. Per prima cosa
> controllo se il ******* pippo.txt ha ancora hash x. In caso affermativo,
faccio
> un ******* link del ******* pippo.txt dal dataset 1 al dataset 2. In caso
negativo
> lo riscarico e cosi` via per ogni ******* Il risultato e` quindi che a fine
> operazione, ho sempre un dataset full, ma in realta` e` praticamente un
> differenziale rispetto al dataset precedente

Quindi in pratica hai replicato rsnapshot che fa esattamente questa cosa.

> Questo non mi e` capitato, e devo dirti che la situazione con cui ero
> partito per fare il mio sistema di backup era un server con gazzilioni di
> ******* :)

Sarò sfigato... :)

> Secondo me AMANDA fa quello che cerchi senza troppi sbattimenti. Se poi vuoi
> 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 ?
gandalf.corvotempesta@gmail.com 15 Giu 2015 17:39
Il giorno lunedì 15 giugno 2015 11:25:43 UTC+2, Enrico Bianchi ha scritto:
> 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.
Enrico Bianchi 15 Giu 2015 21:03
gandalf.corvotempesta@gmail.com wrote:

> I differenziali/incrementali li fai con rsync, non con tar, ovviamente.
> Ci pensa rsync a copiare solo i ******* variati, poi con tar unisci più
> archivi e ti fai un singolo filettone facilmente trasportabile.

Mmm... quando parlavi di differenziali mi veniva in mente piu` il sistema di
dar, che fa un archivio di dati contenente la differenza rispetto
all'archivio full

> Quindi in pratica hai replicato rsnapshot che fa esattamente questa cosa.

A livello di storage su disco si, ho preso spunto da rsnapshot. La
differenza da esso sta nel fatto che i metadati (owner/gruppo, permessi,
ACL) li salvo su db (PostgreSQL), che il ******* di configurazione e` in stile
ini (dove ogni sezione indica una macchina) e che mi appoggio su di un
client dedicato (e non su rsync/ssh) in modo da lanciare comandi pre e post
backup (e.g. lancio un pg_dump, copio il ******* e poi faccio rm del dump
creato in precedenza)

> Per Amanda c'è un libro o un qualcosa che mi posso leggere al mare con
> calma o una documentazione "vera" ?

Da quello che vedo c'e` un capitolo intero di Backup & Recovery della
O'Reilly, che copre bene o male l'intera architettura di AMANDA sia a
livello di gestione, sia a livello di configurazione/gestione. Inoltre c'e`
il wiki, che dovrebbe riportare piu` o meno tutto quello che serve a gestire
il software e a gestire i problemi piu` comuni. Poi ovviamente ci sono i
forum ed il supporto professionale (sono gli stessi di BackupPC)

> 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 ******* 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
Jack 15 Giu 2015 23:14
Enrico Bianchi <enrico.bianchi@ymail.com> wrote:

> 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

come mai proprio il Go?

Ciao Jack
--
Yoda of Borg am I! Assimilated shall you be! Futile resistance is, hmm?
gandalf.corvotempesta@gmail.com 15 Giu 2015 23:37
Il giorno lunedì 15 giugno 2015 21:04:52 UTC+2, Enrico Bianchi ha scritto:
> Da quello che vedo c'e` un capitolo intero di Backup & Recovery della
> O'Reilly, che copre bene o male l'intera architettura di AMANDA sia a
> livello di gestione, sia a livello di configurazione/gestione.

Si ho visto.

> Inoltre c'e`
> il wiki, che dovrebbe riportare piu` o meno tutto quello che serve a gestire
> il software e a gestire i problemi piu` comuni. Poi ovviamente ci sono i
> 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....
Enrico Bianchi 15 Giu 2015 23:53
On Mon, 15 Jun 2015 14:37:24 -0700, gandalf.corvotempesta wrote:

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

Boh, all'epoca, quando lo provai, non trovai la documentazione in*****ata
(se non ricordo male mi appoggiai ad un howto/tutorial). In ogni caso,
una prova la si puo` sempre fare ;)

Enrico
Enrico Bianchi 15 Giu 2015 23:56
On Mon, 15 Jun 2015 23:14:32 +0200, Jack wrote:

> 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' fasti***** 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

Links
Giochi online
Dizionario sinonimi
Leggi e codici
Ricette
Testi
Webmatica
Hosting gratis
   
 

Discussioni sul sistema operativo Linux | Tutti i gruppi | it.comp.os.linux.sys | Notizie e discussioni linux | Linux Mobile | Servizio di consultazione news.