mile al tuo, con checksum, quota, notifiche e comunicazioni.anche se piu' lentamente utilizzo il tool esterno. Ogni volta genero un file con l'elenco di tutti gli md5 piu' altre info utili come spazio occupato, spazio disponibile, numero di backup presenti.... un po' di info leggibili, insomma.Come hai implementato il checksum nel tuo script? Io sto provando a trovare una soluzione utilizzando l'md5 di rsync che si può ottenere usando l'opzione --output-format="%C e altri format per altre info". Questo è ottimo perche cmq l'hash lo calcola direttamente rsync e si risparmia un po di tempo, quindi per ogni file scaricato inserisco il rispettivo md5 in un manifest unico per il client contenente tutti i checksum dei file scaricati precedentemente. Il problema è che usando gli hardlink e utilizzando il prune, mi ritrovo a dover aggiornare una lista molto lunga ogni volta che effettuo un prune e questo richiede molto tempo. Al momento mi sono affidato a ZFS ma se non ho capito male il controllo di zfs consiste nel controllare se la copia live è cambiata rispetto a quella della parità senza che il file sia stato modificato nella copia live (anche perche se il file viene modificato nella copia live viene comunque aggiornato anche nel parity) (se sbaglio correggetemi).
Concordo. Bacula è una cosa allucinante, l'ho usato in passato con successo ma è troppo complesso e macchinoso (magari in altre realtà è la salvezza ed è necessario che sia cosi). Prima cosa è un pò confusionario il modo in cui i client vengono configurati, cioè si parte da un file di configurazione che contiene le direttive ma poi una parte delle info viene memorizzata sul database (la parte riguardante ai pool, volumi, job, file e host). Non c'è niente di male in questo ma se provi cambiare le config dei pool, volumi ecc devi cmq aggiornarle sul DB con la bconsole, se elimini un client dalla configurazione poi devi andare ad eliminare il client dal DB, idem se fai modifiche ai pool/volumi, idem se cancelli un volume o un job (esiste un tool per fare questo, o meglio un tool che si occupa di eliminare i record orfani ma non ha mai funzionato per me..sarò io). Poi ci sta il mantenimento del DB che potrebbe diventare gigante e quindi le query per vedere quale file è memorizzato in quale volume richiedo un tempo maggiore e poi ti ritrovi a fare un backup del db (di bacula) molto grande (ci sono diverse direttive per questo ma si può sempre omettere qualcosa o sbagliare il retention period). Oltre a questo non mi piace come gestisce i volumi sui backup con storage su disco e non su TAPE (su TAPE penso che sia formidabile questo approccio) ma su disco è più un problema che una soluzione. Per esempio, mi capitava che un job fallisse per un motivo ma il volume era già stato allocato e marcato come usato. Avendo il maximum volume jobs = 1, Maximum Volumes = N e le retention policy praticamente distruggeva il ciclo di backup del client perche ti trovavi con un volume in meno (praticamente non usato) ma che cmq ti sballava il ciclo. E vai a manina a cambiare il numero di pool per fargli fare il backup e poi eliminare quello vecchio. Forse lo usavo male io, ma per backup su disco non è il massimo. Poi per carità ha delle funzioni spettacolari come il migration su un secondo storage come replica, backup virtuali ecc...forniscono supporto a chi ne ha bisogno ma il gioco non vale la candela (nel mio caso). Per non parlare del caso in cui il server crepa, o il DB crepa, o i volumi corrotti. Prova a ricostruire il db dai volumi senza il bootstrap (con bscan) e vedi quanto ci mette.....Ah e ci sta anche un altro problema. Se io implemento un sistema con bacula per qualcuno, e poi non sono più il responsabile per varie ragioni, quello che dovrà far funzionare i backup dovrà impazzire per imparare bacula in un tempo ragionevole o rimpiazzare la soluzione di backup. Non che sia un mio problema ma lasciare un cliente in una situazione del genere non mi piace.
Bareos dovrebbe, almeno sulla carta, risolvere i problemi storici di Bacula. In realta', e questo l'ho capito sbattendoci le corna, i file di configurazione servono solo per generare le configurazioni vere e proprio memorizzate nei db. Sto giusto cercando di capire quanto i plugin di python possono essere utili in questo contesto.
Resta la sua complessita'. Unico passo in avanti e', almeno nella configurazione debian, l'aver esploso tutti i file di configurazioni suddividendo ogni componente in un file a se, sicuramente piu' manutenibile rispetto al file monolitico di bacula che alla fine non ci si capiva piu' nulla.
Resta un po' il discorso di come i dati vengono gestisti
fisicamente. Non ho possibilita' di usare unita' a nastro,
purtroppo, e i limiti dei file si vedono abbastanza velocemente.
Anche io sto avendo grandi soddisfazione dal mio script, proprio l'altro giorno ho fatto una cavolata e ho sovrascritto per sbaglio i file shadow e group in /etc (stavo facendo un test ma il risultato doveva essere diverso e i due file non erano interessati) e con il mio script sono riuscito a fare il restore in pochissimo tempo dal server di backup. Penso anche che una delle peculiarità di un buon backup sia il tempo di recupero e restore dei dati e in questo caso non avendo deduplicazione a blocchi (quindi non deve ricalcolare l'indice dei chunk per fornirti i file), senza compressione, senza cifratura nel software di backup riduce i tempi di restore. Che poi tutte queste cose sono gestite da ZFS in modalità trasparente è un altro discorso.
credo tu abbia toccato il punto. Avere mila copie dei dati e'
cosa buona, ma poi non riuscire a tirare fuori quello che serve è
un suicidio. Bacula/Bareos, una volta impostati, vanno bene e sono
stabili, ma riuscire poi a centrare il file giusto da recuperare
in tempi utili non è cosi' scontato. L'approccio dello script
invece e' radicalmente diverso, entro, o cerco nel file di
checksum o guardo direttamente nell'albero delle directory,
suddiviso ovviamente per data di backup e in un attimo centro
l'obbiettivo e questo mi salva. Considera che questo script lo uso
anche sui server di posta aziendali che di giga, ogni giorno, ne
macinano parecchi.
, nessun software assurdo per i backup.
Tombola. alla fine, ne esce vincente qualsiasi script (fatto bene, si intende) in grado di mettere a disposizione un disaster recovery anche parziali semplice, efficace e soprattutto veloce. VELOCE, la parola magica. Veloce che deve essere anche SEMPLICE. Posso dire a un collega: apri il server x, entra in Y, trovi una miriade di cartelle nel formato ANNO-MESE-GIORNO-ORA, entra nel penultimo e vatti a cercare quello che si sono persi. Ecco, fine del problema. Non sara' per utenti clicca-clicca, ma almeno si viaggia in efficienza.
Bareos sicuramente propone degli strumenti decisamente avanzati
(vedi il VSS in winz) ma poi, come tanti altri prodotti di alto
livello, non mi danno quella sicurezza che ricevo andando a
spippolare direttamente laddove i backup vengono memorizzati. E ci
sta, maggiore complessita' maggiore difficolta' di verifica
diretta e spicciola.
Continua la ricerca.... e intanto aggiungo funzioni allo script.
Mauro