Il 09/07/20 21:48, Mauro ha scritto:
Il 09/07/2020 15:58, Alessandro Baggi ha scritto:
Un saluto esteso a tutta la lista.
ricambio con piacere.
Per un ambiente lavorativo stavo pensado a qualcosa di più
professionale che supporti la compressione, deduplicazione (non che
sia necessaria al momento), cifratura dei backup e controllo di
integrità dei backup.
Facendo un ricerca in rete ho trovato:
1) rsnapshot: non più mantenuto in quanto lo sviluppatore principale è
passato a borgbackup.
2) dirvish: non più mantenuto dal 2014.
3) bacula: letteralmente un mostro (che ho usato in passato)
4) bareos: è il fork di bacula quindi come sopra
5) amanda: non so
6) borgbackup: tool veramente interessante ma supporta solo il push
nativamente quindi dovrei usarlo con rsync + borg in locale. Anche in
questo caso uno script bash è necessario per mantenere più client.
7) restic: simile a borgbackup
e altri.
Avete dei consigli al riguardo?
Ciao Mauro e grazie per la risposta
La mia situazione che e' un mix di robe di lavoro e personali alla fine
mi hanno portato a usare due tools (tralascio quelli per gli ambienti
misti winz):
il primo, uno script che ogni giorno cresce un po' che si basa su rsync,
simile al tuo, con checksum, quota, notifiche e comunicazioni.
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).
il secondo un bacula che sta diventando in questi giorni un bareos.
Quest'ultima soluzioni l'avevo scelta qualche anno fa perche' dovevo
lavorare in ambienti misti (linux,bsd e windows) e mi sembrava una
valida alternativa da mettere in mano con apposita interfaccia a utenti
meno smaliziati a cui, al massimo, dovevo far premere un tasto soltanto.
Effettivamente Bareos/Bacula sono di una complessita' che rasenta la
follia. Per carita' stabili, ma laddove ho thera e thera di file piccoli
(documenti office) andare a cercare qualcosa sta diventando una tortura.
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.
Lo script, invece, mi da' parecchie soddisfazioni: stabile, costante,
facile da manutenere e permette, vista propria la modalita' di
salvataggio dei file di ritrovare le cose in tempi decisamente brevi.
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.
Che dire: come te sono un po' a un bivio: uso una applicazione mostro
che pero' attraverso interfaccia decente consenta a utenti non
smaliziati di sentirsi super uomini o continuo imperterrito a usare il
mio script che decisamente mi fa dormire sonni molto piu' tranquilli.
È da un pò di tempo che mi trovo anche io al bivio, e sempre di più sono
convinto che lo script sia migliore in termini di
semplicità,flessibilità, velocità, stabilità e accesso ai dati senza
fronzoli rispetto alle altre situazioni. Se il job fallisce, riparti
semplicemente con un nuovo job. Se il server crepa basta collegare i
device su un altro server e hai la possibilità di recupero immediato in
caso di urgenza senza dover dipendere da un software specifico che
recupera i dati da un archivo con chissà quale formato che cmq non
potresti recuperare senza quel software.
Inizio a pensare di concentrarmi di piu' sullo script.
Aneddoto 1: mi è capitato tempo fa di dover recuperare dei backup di un
nas crepato che girava su XP e i backup su disco esterno sulla stessa
macchina ereditato da un altro tecnico. Non ricordo quale tool era,
aveva un primo backup full fatto nel 15/18 e poi una miriade di
incrementali tutti memorizzati in cartelle nominate per data con i file
singoli senza archivi. Tralasciando stare le modalità e il resto, sono
riuscito a recuperare i dati grazie al fatto che i file salvati erano
semplici file e non memorizzati in chissa quale archivio con chissà
quale formato. Semplicemente attaccato il disco sulla mia workstation
montato il disco, un piccolo script che iterava la dir e via.
Aneddoto 2: sempre qualche tempo fa (durante la quarantena) ho avuto la
possibilità di entrare in contatto con il responsabile che si occupava
del Cluster Pleiadi della NASA e avendo fatto un post su Reddit su
Pleaidi era contento che si parlasse di loro in particolare di Pleaidi
(va a vedere se vero ma dalla precisione con cui parlava dei sistemi che
gestiva e dei dettagli sembrava affidabile) e mi ha fornito diversi link
e risorse con tutte le specifiche dei sistemi che usano e di altri
piccoli cluster (sono cmq tutte informazioni di dominio pubblico e mi ha
detto che si possono andare a visitare i datacenter con visite guidate
organizzate da loro ma che con il COVID-19 era tutto bloccato). Al
momento usano SLES e avrebbero usato debian se non fosse stato per
Lustre (usano anche altre distro in altri settori per altri scopi). Fu
una bella discussione (in privato) e oltre a diverse cose gli ho chiesto
come approcciavano al backup dei dati in una struttura come quella e qui
sono rimasto sorpreso. Mi ha spiegato che per i dati in cluster non
fanno i backup perche sono abbastanza ridondati e che per quella
dimensione era folle effettuare dei backup, per il resto backuppabile
usano dump con una politica Grandfather-father-son (Molto simile a
3-2-1). Quindi nessun tool proprietario, nessun software assurdo per i
backup.
Mauro
Un saluto.