Ciao Mauro e grazie per la rispostaIl 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?
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).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.
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.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.
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.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.
È 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.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.
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.Inizio a pensare di concentrarmi di piu' sullo script.
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.
Un saluto.Mauro