Newsgroup: it.comp.os.linux.sys
Titolo: Alternative a Bacula

Basta, mi ha rotto le palle.
Quando funziona, va tutto bene, ma di punto in bianco si blocca, non indica il perchè ed impiego SETTIMANE per ripristinare il tutto.
 
Voglio cambiare software.
 
Tassative come funzioni: 
 - supporto ad una libreria
 - storage su disco
 - nessuna pre-lettura dei file da copiare, come fa rsync
 
Amanda e cose simili sono esclusi, la documentazione è incomprensibile o parziale, mi ritroverei con gli stessi problemi di bacula.
 
BackupPC sarebbe perfetto, se non altro perchè usa software 'standard' ma si appoggia ad rsync che è mostruosamente lento, su almeno 4-5 server (che prima backuppavo con BackupPC) la sola fase di "Building file list" impiega dai 2 ai 3 giorni. Sono svariati milioni di piccoli file.
 
Cosa suggerite ?

 Cosa suggerite ?
 
Io me lo sono scritto, con blackjack e squillo di lusso ;)
 
Enrico
P.S. 
https://github.com/mementobackup/
 
P.P.S. seriamente, l'unica cosa che non faccio è il supporto ad una 
libreria (per quello userei tar e mt se mi decidessi ad installare la 
libreria...)

 libreria...)
 
Spiega tutto, ma proprio tutto.... :)

 Spiega tutto, ma proprio tutto.... :)
 
Semplicemente, ho un sistema client/server che:
 
 - Gestisce sia connessioni plain che connessioni SSL;
 - Gestisce quattro tipi di dataset (per ora sono indipendenti, ma
   l'intenzione è di fare check cross dataset);
 - La configurazione è quasi completamente lato server, lato client
   vengono definiti solo i parametri di connessione (porta ed indirizzo
   in ascolto, SSL);
 - Permette l'esecuzione di comandi pre e post backup;
 - Scarica i file as is, ovvero non applica modifiche al file se non
   richieste (è possibile applicare una compressione Gzip);
 - Se il file non è stato modificato, viene fatto un hard link da un
   dataset precedente;
 - Salva gli attributi e le ACL su database (uso PostgreSQL);
 - La configurazione lato server è un semplice file ini dove, a parte
   un paio di sezioni obbligate (e dai nomi facilmente intuibili), le
   sezioni aggiuntive si riferiscono alla macchina presa in esame;
 - La configurazione lato client è da linea di comando eccetto per le
   opzioni relative a SSL;
 - Il client è cross platform ;)
 
Per ora non mi trovo male, e soprattutto funziona senza troppi problemi 
(si, mancano parecchie cose, tipo il filtraggio di cosa salvare o meno, 
ma sinceramente non è troppo scomodo) :)
 
Enrico 

 ma sinceramente non è troppo scomodo) :)
 
Quindi al momento backuppi tutto ciò che trovi su disco senza poter decidere quali directory backuppare ?
 
Lato server, come e dove vengono salvati i client backuppati ? I file sono accessibili facilmente in caso di cataclisma o bisogna per forza passare dal tuo software per ricostruire l'elenco ? Nel senso, se il tuo software (o il mio server) dovesse andare a puttane, posso montare il disco da qualche parte e darci sotto di "cp /backup /nuovo_server" ?
 
Io al momento faccio 1 full al mese, 1 incrementale al giorno, 1 differenziale ogni domenica. Del differenziale mi interessa poco (sinceramente, non ho nemmeno capito come funziona), ma full ed incrementali si. Stando a ciò che hai scritto, te fai il full solo alla prima esecuzione, poi sempre e solo una sorta di incrementale hardlinkando il file al primo full ?

 primo full ?
 
Si, per fare un paragone, uso la stessa tecnica di rsnapshot eccetto che 
per i metadati (rsnapshot li riapplica al file backuppato, io li salvo su 
database)
 
Enrico

 database)
 
Ecco, appunto ciò che dicevo sopra, perchè non li riapplichi anche te direttamente sul file ?
 
Come identifichi un file variato ? Cicli tutto il client da backuppare e confronti la data di modifica? La dimensione? Un hash? Chiedo questo perchè in base a come cicli il client, possono volerci da pochi minuti a giornate intere di solo "indicizzazione", come ad esempio rsync. (che sarebbe perfetto, se non impiegasse 3 giorni a partire)

 Come identifichi un file variato ?
 
L'operatività è questa. Per ogni server:
 - Eseguo un comando pre backup (se impostato);
 - Richiedo la lista degli oggetti (file, directory, symlink);
 - Salvo i metadati su database;
 - Ricreo la struttura di directory presenti sul sistema remoto;
 - Per ogni file confronto gli hash MD5 del dataset corrente e precedente:
   - Se sono identici faccio l'hard link;
   - Se sono differenti, scarico il file;
 - Ricreo i symlink presenti sul sistema remoto;
 - Eseguo un comando post backup (se impostato).
 
Per la velocità posso dirti che un pool di 19 macchine (304Gb con un 
differenziale di 56Gb per dataset) ci mette tra le 5 e le 6 ore per notte 
(ovviamente sulla velocità incide parecchio il numero di file)
 
Enrico

 (ovviamente sulla velocità incide parecchio il numero di file)
 
Interessante.
Io da backuppare avrei il triplo di macchine e circa 11TB.
 
PROBLEMA: tra le dipendenze c'è scritto PostgreSQL. Sul serio? O posso usare MySQL? Ho dato un rapido sguardo qui:
https://github.com/mementobackup/server/blob/master/src/server/database/queries.go
 
e non mi sembra di vedere query o funzioni particolari da richiedere Postgresql

 usare MySQL?
 
Il driver ed il database che uso è PostgreSQL, in teoria dovresti migrare 
lo schema a MySQL importare la libreria ad hoc e poi far girare il 
tutto ;)
Seriamente, il vincolo al database è quanto di più irritante possa avere 
il mio applicativo, ma non riesco a trovare un modello migliore per il 
salvataggio dei metadati e per l'accesso concorrente al db (in teoria 
SQLite con WAL dovrebbe bastare, ma non mi fido molto...)
 
Enrico

 Io da backuppare avrei il triplo di macchine e circa 11TB.
 
Occhio che come ho detto il tempo di backup lo fa il numero dei dati E la 
connessione SSL (go purtroppo non ha una implementazione decente di SSL, 
forse l'avrà nella 1.6 ma è più probabile che ci vorrà la 1.7), che uso 
massivamente (non ho implementato un meccanismo di autenticazione tra 
client e server, se non il check tramite certificato SSL)
 
Enrico

Se ho tempo domani lo provo.
Peccato per il db, in effetti.
 
Mongo? Ti serve per forza relazionale? Non mi pare di aver visto relazioni.
 
Scusa il quote, sono da cellulare.

 Mongo? Ti serve per forza relazionale? Non mi pare di aver visto relazioni.
 
C'è sempre sqlite.
 
 
-- 
Andrea
 

 C'è sempre sqlite.
 
sqlite non gestisce la concorrenza.

 Cosa suggerite ?
 
Io uso dar 
http://dar.linux.free.fr/
 
 
Ciao, Mauro

 relazioni.
 
Il database non mi serve per forza relazionale (tra client e server 
scambio JSON), quello che mi serve è la concorrenza nell'accesso ai dati. 
In teoria con SQLite potrei risolvere, in quanto sul dataset precedente 
accedo solo in lettura. In effetti in passato (in un'implementazione in 
python ed in una in java) lo avevo usato, ma poi l'ho dovuto abbandonare 
a causa di un problema di stabilità (anche se era dovuta al driver). In 
effetti potrei aprire un branch e provare ad implementarlo...
 
Mongo l'ho scartato perché spesso tende ad essere parte del problema 
piuttosto che la soluzione (e.g. usa un memory mapping che tende a 
saturare la RAM del sistema, soprattutto in caso di grandi documenti). 
Altri sistemi sinceramente li ho voluti evitare, anche perché già trovo 
insopportabile la dipendenza da PostgreSQL per un progetto del genere
 
Enrico

 sqlite non gestisce la concorrenza.
 
In teoria la gestisce, ma non so come si comporta con le scritture 
concorrenti... 
https://www.sqlite.org/wal.html
 
 
Enrico

 insopportabile la dipendenza da PostgreSQL per un progetto del genere
 
Un bel CSV ? :)

 Un bel CSV ? :)
 
Non appena ho letto, mi è venuto in mente Cara Ti Amo quando gli propone 
come fare sesso -_-
 
Enrico


sulla concorrenza di sqlite ti rispondo io
In caso di scrittura il database viene messo in locked state fino a 
quanto il lock non viene sbloccato (di solito con un commit o rollback)
per le letture i lock non valgono e vengono letti i valori corretti (un 
altra transazione non legge i valori modificati fino a quando non viene 
fatto il commit)
 

 quanto il lock non viene sbloccato
 
Fermo, questo è il vecchio o il nuovo meccanismo di locking? Ovvero, su 
SQLite è stato abilitato WAL oppure no?
 
Enrico


Modalita normale,senza wal.
E poi non ho la 3.7
 


direi che, se hai molti client (e molte connessioni), ti serve un 
meccanismo di row locking, e probabilmente pure pessimistic locking ... e 
non strani meccanismi di journal, concepiti per un dbms che non è stato 
pensato per gestire grossi volumi di dati. 
 
-- 
Massimiliano Adamo


sqlite è stato pensato come sostituto di gestione file non come 
sostituto per un vero db.
Ma questo credo che Enrico lo sappia.
 

 un dbms che non è stato pensato per gestire grossi volumi di dati
 
Che io sappia, SQLite permette di gestire grosse moli di dati, tutto sta 
a come ci si deve accedere. Per il resto, comunque, sono d'accordo con 
te, vedrò di creare più file perché, nonostante in molti casi n processi 
andranno in lettura ed uno in scrittura, non ho voglia di rischiare di 
perdere tutti i dati per questa cosa (anche perché così avrò al massimo 
quattro processi che necessitano di scrivere sullo stesso database 
contemporaneamente, e può essere un rischio accettabile)

 contemporaneamente, e può essere un rischio accettabile)
 
Il "4" da dove arriva ?

 Che io sappia, SQLite permette di gestire grosse moli di dati, 
 
si, ma con quanti accessi concorrenti? (non ho risposte, ma solo un 
dubbio). 
 
p.s.: complimenti per il go :) 
Prima o poi dovrò imparare a masticarlo pure io perché in azienda andiamo 
di python e go (e ruby per i puppet facts) 
 
-- 
Massimiliano Adamo

 Il "4" da dove arriva ?
 
Sostanzialmente, se vado nella direzione multi database (che ho già 
sperimentato in passato ma che ho dovuto abbandonare), avrei una 
situazione del genere:
 
 - Un database master, contenente una sola tabella (STATUS);
 - Un database per sezione, contenente le altre due tabella (ATTRS e
   ACLS).
 
Di fatto, per tutti i database per sezione avrei un solo processo in 
scrittura e n processi in lettura, in quanto faccio il confronto con il 
dataset precedente per capire se devo andare di hard link o devo 
scaricare di nuovo il file. Per il database master, invece, avrei n 
processi in lettura e n processi in scrittura, in quanto nella tabella 
STATUS scrivo l'ultimo dataset eseguito. Pertanto, gestendo 4 tipologie di 
backup (hour, day, week, month), nel peggiore dei casi avrei 4 scritture 
contemporanee. In teoria non dovrebbe essere un problema, in pratica 
dovrei fare delle prove ;)
 
Enrico

 io perché in azienda andiamo di python e go (e ruby per i puppet facts)
 
Eh, tieni presente che questo "mostro" l'ho scritto inizialmente in 
Python (prima 2, poi 3), successivamente sono migrato a Java (che mi 
risolveva problemi di distribuzione e mi permetteva di implementare cose 
fighe tipo accesso diretto a database) ed infine sono passato a Go, che 
mi risolveva i problemi che avevo in Java (performance, risorse occupate) 
mantenendo comunque una buona pulizia di codice (per inciso, C lo evito 
come la morte perché non mi piace, sono un sostenitore di Pascal io :P )
 
Enrico

 Cosa suggerite ?
 
Mi è venuto in mente anche questo (e sinceramente non ricordo perché lo 
scartai): 
http://www.boxbackup.org/
 
 
Enrico

 
http://www.boxbackup.org/
 
 
E ci sarebbe anche questo: 
http://burp.grke.org/
 
 
Enrico

 Cosa suggerite ?
 
Una terza alternativa drastica e` zfs send/zfs receive
 
Enrico


e adesso che zfs è installabile come modulo del kernel, non è per niente 
male come soluzione. 
 
-- 
Massimiliano Adamo

 Cosa suggerite ?
 
tempo fa provai BAR (del quale non ricordo più le caratteristiche): 
http://www.kigen.de/projects/bar/#screenshots
 
 
Pro: lo sviluppo è molto attivo (puoi vedere il changelog)
Contro: è java
 
-- 
Massimiliano Adamo

 Contro: è java
 
Da quello che vedo nei sorgenti, Java serve solo per la gui, il resto è 
in C. Che potrebbe non essere male, anche se mi lascia perplesso sia 
l'uso di xdelta3 come algoritmo di compressione (wtf?), sia il fatto che 
non dice cosa salva (si, ok, i dati, ma i metadati associati?)
 
Enrico

 l'uso di xdelta3 come algoritmo di compressione (wtf?), 
 
però nei requirement io vedo questo: 
 
    • zlib library (mandatory)
    • bzip2 library (optional)
    • lzma utils (optional)
    • lzo utils (optional)
    • lz4 utils (optional)
    • xdelta library from 
http://xdelta.org
 (optional)
 
 
cioè, è opzionale. 
 
 
-- 
Massimiliano Adamo

Interessante, da quel che ho capito, backuppa in tempo reale. Qualcuno l'ha mai provato? 
 
A dire il vero ho notato che rsync dalla 3 in poi crea la lista dei file in maniera incrementale ed in background velocizzando la fase iniziale prima della copia
 
Potrei riprovare con rsnapshot o l'ottimo backuppc, il mio unico problema con rsync era la building file list (oltre al fatto che 500 volte più pesante di bacula nella copia)

 Sbaglio?
 
Se restori sullo stesso server sì. Ma non è detto che sia così. In
effetti anche rsync, se non diversamente istruito, effettua un mapping a
livello di nome simbolico, non di uid.
 
 
-- 
Flavio Visentin
 
Scientists discovered what's wrong with the female brain: on the left
side, there's nothing right, and on the right side, there's nothing left

 rsnapshot...
 
Non dirlo a me... ;)
 
Enrico

 cioè, è opzionale.
 
Si, si, mi lasciava perplesso perché xdelta lo conoscevo come libreria 
per diff, non per compressione :)
 
Enrico

 Potrei riprovare con rsnapshot o l'ottimo backuppc, il mio unico problema con rsync era la building file list (oltre al fatto che 500 volte più pesante di bacula nella copia)
 
Ne approfitto per una domanda:
scopro solo ora che rsync può sincronizzare file remoti anche senza utilizzare rsyncd, ma usando solo rsync da un lato.
 
Come fa a funzionare? Ha bisogno presumo di ssh o di qualche altro trasporto che permetta lui di leggere i file remoti, dato che non c'è il demone in ascolto.
 
Tolto ciò, in termini di performance, ci sono variazioni ?

 Tolto ciò, in termini di performance, ci sono variazioni ?
 
Probabilmente si, in quanto hai il peso della connessione SSH cifrata 
(personalmente non ricordo, uso poco rsync via remoto)
 
Enrico

 (personalmente non ricordo, uso poco rsync via remoto)
 
Ok, meglio. Tanto se devo riprendere tutti i server per sostituire bacula, posso benissimo riprenderli per aggiornare rsync alla 3.1 che dovrebbe essere più veloce.
 
Devo fare un po di test, tra rsnapshot, che già uso, ma la cui configurazione non è che sia il massimo della semplicità, e BackupPC (uso anche lui) che non ha mai dato alcun tipo di problema se non causati dalla lentezza delle vecchie versioni di rsync
 
L'unico che sta dando infiniti problemi (anche in questo momento) è proprio Bacula.

 Come fa a funzionare? Ha bisogno presumo di ssh o di qualche altro trasporto che permetta lui di leggere i file remoti, dato che non c'è il demone in ascolto.
 
Sì, di default lancia ssh e il binario rsync sul server remoto.
La qual cosa, ai fini del backup, introduce parecchio overhead e non
risulta particolarmente flessibile.
 
Personalmente quando uso rsync per fare i backup preferisco configurare
rsyncd perché il backup viaggia in rete dedicata (quindi la crittografia
non è necessaria) e nella definizione delle share rsyncd (rigorosamente
in sola lettura) posso definire in modo puntuale esclusioni, inclusioni,
script di pre-xfer e post-xfer (
p.es
. per il dump dei DB o lo stop di
servizi), lasciando più "pulita" la definizione del job di backup lato
server di backup.
Tra l'altro per abitudine faccio sempre delle share con nomi standard
(system per il sistema, home per le homedir, mysql per il DB, ecc.) in
modo tale che nel job di backup c'è solo un path senza nulla di
personalizzato.


 personalizzato.
 
Idem, ma per quanto possibile, cerco di fare una singola gigantesca share che punta a tutto il server. Quando backuppo, backuppo sempre tutto, mai in maniera certosia, quindi avere 4-5-6 share differenti, mi darebbe solo fastidio.
 
 
Voglio fare una prova: installo rsync ultima versione sia sul server di backup che su un server da backuppare, il più grosso che trovo, e verifico quanto tempo impiega a partire con le implementazioni che han fatto dalla 3.x

 Voglio fare una prova: installo rsync ultima versione sia sul server di backup che su un server da backuppare, il più grosso che trovo, e verifico quanto tempo impiega a partire con le implementazioni che han fatto dalla 3.x
 
'sticazzi, ma è IMMEDIATO. Appena eseguo il comando parte a copiare file.
 
Sbaglierò qualcosa, non può partire così a missile.

 Idem, ma per quanto possibile, cerco di fare una singola gigantesca share che punta a tutto il server. Quando backuppo, backuppo sempre tutto, mai in maniera certosia, quindi avere 4-5-6 share differenti, mi darebbe solo fastidio.
 
Io invece tento di risparmiare spazio e aumentare la retention adottando
politiche diverse per parti del sistema differenti.
Il sistema una volta a settimana, la /etc e le /home tutti i giorni,
ecc.ecc.


 ecc.ecc.
 
Se consideri che da me la / è su una partizione in media da 3-4GB, aumentare la retention per risparmiare spazio non avrebbe senso, il mio problema solo le /home, che devo backuppare ogni giorno e sono CENTINAIA di giga, così come la /var/log, mediamente 40-50GB. Il resto non fa testo.

 Sbaglierò qualcosa, non può partire così a missile.
 
Per la cronaca, in dry-run (quindi non trasferivo file, ma la scansione dell'intero server l'ha fatta) ha impiegato esattamente 25 minuti.
 
La stessa operazione con il vecchio rsync richiedeva una giornata buona di solo "Building file list", su questo server.
 
Il perchè lo ignoro. C'è troppa differenza.

 il demone in ascolto.
 
 
Esastto attraverso ssh spawna un processo demone sulla parte remota. Su 
link veloci puņ essere un collo di bottiglia rispetto alla versione 
plain con rsyncd.
 
-- 
Gabriele
 

 di solo "Building file list", su questo server.
 
Un altra milgioria che in parte può spiegare le differenti prestazioni 
è l'uso accorto della RAM. La branch 2.x di rsync teneva in memoria 
l'intera lista di file, dalla 3.0 invece tale lista è gestita in 
maniera incrementale, man mano che il processo tratta i singoli file.
 
-- 
Gabriele
 

 Quando funziona, va tutto bene, ma di punto in bianco si blocca, non indica il perchè ed impiego SETTIMANE per ripristinare il tutto.
 
Che poi, una cosa veramente assurda e priva di senso è che di punto in bianco si blocca con "is waiting for an appendable Volume"
 
Peccato che se mi collego alla console e faccio un normalissimo "mount" dello storage in questione, lui lo monta e prosegue senza indugio. E l'automount è settato, tant'è che dopo aver forzato il mount lui prosegue alcuni giorni in automatico.

 Cosa suggerite ?
 
Ciao,
a breve uscirà Veeam Backup for Linux Free. 
Maggiori info sul sito di Veeam.
 
SysAdmin

 Maggiori info sul sito di Veeam.
 
non mi convince affatto, non vorrei ritrovarmi di nuovo con un prodotto che salva file inutilizzabili senza passare dal prodotto stesso.
 
Già Bacula mi sta altamente sui maroni, che senza passare da lui (o da bextract) i file sono inutilizzabili, Veeam oltretutto è proprietario quindi persino peggio.
 
Per come la vedo io, un backup deve essere utilizzabile sopratutto quando va tutto in vacca, e se va tutto in vacca molto probabilmente non hai ne il software che ha creato il backup, ne la sua configurazione originale.
Un backup fatto con memento, backuppc (o altro analogo software basato su rsync) è ripristinabile da chiunque, da ovunque, con qualunque linux, basta avere tar (e c'è ovunque) o eventualmente gzip in caso di compressioni (ed anche gzip c'è ovunque), perchè alla fine tutto è salvato come file nudo e crudo senza strane manipolazioni da parte del software


 
 
lavoro per il GLORIOSO zfs !

Personalmente a me basta che il software che fa il backup mi dia la possibilità di fare un bare metal restore e la possibilità di recuperare eventuali file. Non vedo la necessità di avere la disponibilità dei file senza tool quando il software di backup te li fornisce.

 quando il software di backup te li fornisce.
 
Che intendi?
 
-- 
Andrea
 


esattamente quel che ha detto, niente di più e niente di meno ^_^ 
 
-- 
Massimiliano Adamo


Colpa mia, il reader era in modalità online e pensavo si stesse 
parlando di ZFS. Ora ho letto le osservazioni su bacula.
 
Certo un po' di quoting fatto in modo appropriato aiuta a seguire la 
discussione.
 
-- 
Andrea
 

 discussione.
 
su questo ti posso dare solo ragione :) 
E trovo odioso il fatto che google groups abbia rotto la regola dei 72 
caratteri per linea. 
 
-- 
Massimiliano Adamo

 
 
Hai perfettamente ragione, chiedo scusa a tutti, ma da smartphone non ho ancora capito come fare.
 
--
SysAdmin

 libreria...)
 
Ciao Enrico,
intanto grazie per la condivisione, sistema interessante :D
 
Ho provato ad installarlo sia su linux che su windows ( ho fatto il porting da linux e funziona ), i client stanno a servizio e il server viene chiamato da un crontab giusto? credo di si non mi semra ci sia uno scheduler, la domanda è tu lo hai usato su windows e se si come lo hai messo a servizio?
 
Grazie
 
Umberto

 Personalmente a me basta che il software che fa il backup mi dia la possibilità di fare un bare metal restore e la possibilità di recuperare eventuali file. Non vedo la necessità di avere la disponibilità dei file senza tool quando il software di backup te li fornisce.
 
Il problema è appunto quando non hai il software di backup che ha creato il backup stesso.
 
Se backuppi su un file in formato proprietario, lo ripristini solo con quel software, magari quella precisa versione perchè la "successiva" non è retrocompatibile.
 
Stai pur certo che se tutto va in vacca per bene, il software usato per backuppare non è più rimediabile, non è compatibile con il tuo nuovo server dove hai spostato i dischi contenenti l'archivio e l'unica versione compatibile ed installabile non è retrocompatibile con i tuoi file.
 
Io preferisco stare sul sicuro, ad esempio tar e gzip sono due formati eccezionali, si ripristinano da pressochè ogni sistema (tra cui windows) ed il tar, se butta proprio male, lo estrai anche a mano considerata la struttura semplicissima che ha.
 
Per come la vedo io non serve inventarsi un ulteriore formato proprietario.

 Il perchè lo ignoro. C'è troppa differenza.
 
Sto testando una installazione con BackupPC v4 configurato per backuppare il server di cui sopra, quello che in dry-run scansionava tutti i file in 25 minuti.
 
La copia, full, ha richiesto 24 ore e 40 minuti.
La stessa operazione, con Bacula, terminava in 16 ore e 45.
 
Questa notte dovrebbe partire in automatico il primo incrementale con BackupPC, in modo da valutare le tempistiche "normali" (che il full richieda anche 24 ore mi "potrebbe" star bene)
 
Secondo voi cosa porta backuppc ad essere così tanto più lento di Bacula? Posso migliorare qualcosa ?

 la domanda è tu lo hai usato su windows e se si come lo hai messo a servizio?
 
Per creare il servizio Windows uso 
https://nssm.cc/
 . Per il servizio Linux,
uso banalmente uno script che richiama nohup (non ho voglia di creare lo script
completo... ;) )
 
Enrico

 scambio JSON), quello che mi serve è la concorrenza nell'accesso ai dati. 
 
Alla fine, dopo parecchio tempo a pensarci, ho deciso di dare una botta al
cerchio ed una alla botte. In altre parole, per il salvataggio dei metadati,
oltre a PostgreSQL implementerò il supporto anche a MySQL e a Firebird. Le
motivazioni sono queste:
 
 - Firebird è il più semplice di tutti, ovvero lo installi, crei il database
   (un file) e dici all'applicazione dove si trova (seriamente, è tutto qui).
   Il contro è che, nonostante sia parecchio affidabile (è un fork di Borland
   Interbase 6), è poco diffuso e quindi poco documentato (anche se c'è da dire
   che la documentazione ufficiale è una delle più belle che abbia mai visto).
   Per inciso, Firebird era la mia prima scelta, poi ho preferito cambiare per
   i motivi che ho riportato.
 - PostgreSQL perché lo ritengo dannatamente affidabile ed ha una
   documentazione sterminata.
 - MySQL perché è il più diffuso.
 
Se volete, non appena faccio queste modifiche, invio un post sul gruppo
 
Enrico

 oltre a PostgreSQL implementerò il supporto anche a MySQL e a Firebird.
 
Ma parli di un supporto attivo? Non puoi semplicemente "throw an ORM at 
it" e dimenticarti del particolare tipo di dbms sotto?
 
 
-- 
Andrea
 

 motivazioni sono queste:
 
perche' non anche sqlite gia' che ci sei?
non devi neanche installarlo, importi la libreria nell'applicativo e poi e' un file.
 
Ciao Jack

 perche' non anche sqlite gia' che ci sei?
 
In teoria userei *esclusivamente* sqlite, in pratica non mi è fattibile perché
mi serve una gestione concorrente delle scritture su database e non mi fido a
fare sharing della connessione su più thread/processi/quellochesono
 
Enrico

 it" e dimenticarti del particolare tipo di dbms sotto?
 
Supporto attivo, alla fine per quelle due query in croce che ho (come faceva
notare Gandalf non faccio nemmeno una join) un ORM è un overkill inutile
 
Enrico

 thread/processi/quellochesono
 
Sei saggio.
 
Posso raccontarti quando vuoi una storia di guerra che coinvolge l'uso di
un loschissimo task queue manager noto come "RQ" (Ruby Queue). Il coso usa
SQLite per sincronizzare i processi... [wait for it...] su un filesystem
condiviso.
 
Si noti come SQLite *da documentazione* non supporta scritture
concorrenti. Figuriamoci su processi separati. Figuriamoci su *host*
separati.

     (un file) e dici all'applicazione dove si trova (seriamente, è tutto qui).
 
che sia sotto ups pero'.
non so le ultime versioni ma fino alla 2.x era molto poco resistente 
alle interruzioni "anomale" e si corrompeva facilmente.
 

 concorrenti.
 
Oddio, in teoria su questo punto la documentazione è discordante. Sempre in
teoria, ed in base ad uno stupido test fatto da me (banalmente, apro due
terminali, sui due terminali apro lo stesso database SQLite, comincio la
transazione su tutti e due i terminali e poi vado di insert), se abiliti il WAL
anche SQLite riesce a gestire le scritture concorrenti.Solo che, come ho detto
prima, non mi fido ad usarlo in questo modo (ho sistemi pensati e testati
giorno per giorno per fare questa cosa, perché dovrei usare qualcosa che
sembra un surrogato?)
 
Enrico

 dovrei usare qualcosa che sembra un surrogato?)
 
Sacrosanto. Ogni problema ha i suoi tool.
 
La storia di RQ risale a un po' meno di 3 anni fa, quando sono stato
assunto da quella che al tempo era $Startup, ed ora è cresciuta in
$SmallCompany. Ma il gruppo era originariamente una ghenga di ricercatori
ed avanzi di accademia.
 
Questa gente faceva (allora come oggi) delle cose con Java, e ne
verificava i risultati a colpi di esecuzioni simulate. Per sveltire la
cosa utilizzavano un cluster basato appunto su questo dannato RQ[0], e
c'era un brutto brutto accrocchio che parametrizzava il tutto mandando dei
"batch" di comandi sh (pesanti assunzioni sul layout del filesystem). 
C'era poi una interfaccia in ncurses che doveva essere un helper, ma
rendeva il tutto dannatamente complicato.  La peggio cosa è che il
concetto di "namespace" non era chiaro allo sviluppatroto. Perciò il tutto
si risolveva con mille mila directory che come nome avevano l'output di
`date +%s`. Questo per dare il contesto. 
 
[0]: 
https://github.com/pjotrp/rq
 
 
Mi fu detto di migliorare l'usabilità di questa cosa, e successivamente di
migrarla dal cluster dell'università ad un cluster analogo sull'azzurro
cloud di Microslot. Scelta che poi ha avuto effetti imprevisti, ma questa
è un'altra storia orrida. Dopo aver deciso che l'interfaccia curses era
una gran caciotta a livello strutturale quanto a livello esteriore, ho
buttato tutto via, e mantenuto solo il gestore di task RQ.
 
Come menzionato, questo coso usa un bel SQLite su un filesystem condiviso
per gestire la sincronizzazione. Ma uno può naturalmente ignorare questo
fatto, visto che la cosa è celata dietro le quinte. Almeno fino a quando
non ci sbatti il muso. Ci costruisco sopra un layer di astrazione che mi
permette di chiamare il coso da Python (a colpi di subprocess), e
costruisco da zero il resto.
 
Tutto sembra funzionare per qualche tempo: giorni, settimane... Ma quando
il sistema inizia ad essere usato un po' più seriamente, ed ecco che
alcuni processi tardano a produrre risultati, anzi non finiscono più. SSH
sul worker del caso, ps aux | grep java, il processo ha finito. Uhm...  cd
/path/to/results; ls, i dati ci sono. WTF?
 
Per farla breve, il worker mette una flag nel database per dire che
l'esecuzione è terminata e RQ riporta quest'informazione. Ma in
determinate situazioni il reporting non funziona perché la flag viene
settata, ma poi sovrascritto da una race-condition. Pialla il db e
ripartiamo.
 
Questa cosa succede una volta, due, tre ...finché decido che non è una
cosa così casuale. E scopro così che esiste in RQ un comando "recover". La
documentazione recita:
 
    it is possible that a hardware failure might corrupt an rq database.
    [...] this has been reported only a handful of times, nevertheless,
    this command wraps sqlite recovery to get you rolling again
 
Quindi qui i casi sono due: o chi ha scritto quest'affare *pensa* che sia
un problema hardware ma ha sbagliato a fare i conti (possibile), oppure
questo coso è pensato per avere master e workers *sulla stessa macchina*,
e il tizio che ha messo in piedi il cluster non ha capito una fava
(probabile).
 
Vado dunque dal CL in questione e gli chiedo se ha visto ancora un
problema analogo. CL risponde: "si, succedeva a volte quel che dici.
Ma ho pensato che qualcuno fosse *stufo di avere il cluster occupato*
e uccidesse i tasks". Così CL semlicemente faceva ripartire i tasks e
si fregiava del ruolo di babysitter, in barba alla legge.
 
È andata a finire che ho potuto rimpiazzare RQ con qualcosa di più solido
(Python Celery prima, e Pyhton Huey dopo ancora, per questioni atroci
legate ad Azure, che ho accennato prima). Purtroppo sono stato tordo, e
non pur avendo astratto abbastanza bene l'accesso alla task queue, il
design del master è stato vagamente influenzato da come RQ gestisce lo
scheduling.
 
Ho molto sofferto nel risolvere il debito tecnico, ma ne sono uscito.
Forse non *più forte*, ma di sicuro *meno ona*.
 
 
Saluti

 alle interruzioni "anomale" e si corrompeva facilmente.
 
Uhm, ho appena provato con una 2.5.5 e non ho avuto problemi del genere
(fondamentalmente, mentre scrivevo una grossa transazione ho spento la macchina
virtuale su cui Firebird girava)...
 
Enrico

 virtuale su cui Firebird girava)...
 
buono a sapersi... ho ricontrollato il mio storico e in realta' parlo di 
fb 1.0, 1.5 e poco 2.0 quindi di anni ne sono passati.

 Enrico
 
ok.
 
Ciao Jack

 La stessa operazione, con Bacula, terminava in 16 ore e 45.
 
Ok, ricapitolo.
Scarto BackupPC, il 4 non funziona. Sono 2 settimane che mi fa bestemmiare e puntualmente per non si sa quale motivo, mi cancella dei backup facendomi perdere dei punti di ripristino.
 
La v3 è paurosamente lenta, l'avevo scartata anni fa per questo motivo. Avendo una versione perl di rsync, non gestisce la lista file incrementale, il che mi porta via molte, molte, molte ore di solo building file list (cosa che nella v4, facendo uso di rsync 'vero') impiega 1 millisecondo)
 
rdiff-backup è valido, ma mi obbliga ad installarlo su tutti i server ed è un protocollo proprietario (per quanto open). I file sono ripristinabili in maniera diretta solo dall'ultimo backup (che 9 volte su 10 è quello che serve), tutti gli altri sono salvati come delta e richiedono rdiff per essere ripristianti. Non mi fido.
 
rsnapshot salva tutto in chiaro. Lo uso già su un server per backupparne altri 10 in una configurazione fortemente custom. E' valido, validissimo. Ma:
 
Devo prima fare il "sync", il quale tira giù tutto dal server remoto. Gli altri comandi (daily, weekly, etc etc) non fanno altro che ruotare i file.
Come faccio a sapere quando il sync è terminato per eseguire tutti gli altri comandi, visto che vanno schedulati tutti manualmente da cron?  Non vorrei eseguire la rotazione prima che il sync sia terminato.
 
Backuppare X host è un calvario, non è supportato da rsnapshot, quindi sono costretto a fare un po di script qua e la per dinamicizzare la configurazione e richiamarla ogni volta per ciascun server tramite il parametro "-c"
 
Qualche suggerimento ?

 Qualche suggerimento ?
 
Provare Bareos? Per il discorso "attendo che il backup precedente sia finito",
è interessante, ma non mi viene in mente come implementarlo, ovvero cosa fare
in caso il precedente backup non abbia ancora finito
 
Enrico

 in caso il precedente backup non abbia ancora finito
 
Se parli di rsnapshot, con 4 righe di configurazione per ciascun server, sono riuscito a backuppare, volendo anche in parallelo, tutti gli host che mi servono.
 
Ora non mi resta che:
1) capire, tramite script, come poter eseguire in parallelo X comandi, partendo magari da un lista di host (ad esempio, ho 15 host, voglio eseguire un determinato comando a blocchi di 5 alla volta: "for host in $listaDa15; do parallelizzane5 ....; done"
 
2) non credo di aver afferrato il funzionamento delle rotazioni, ho paura di fare errori grossolani. Magari qualcuno può spiegarmelo diversamente. Lui prima sincronizza (rsnapshot sync), poi ruota l'intervallo più breve (nel mio caso il daily) In caso di sync separato (come è giusto che sia), il daily non viene ruotato, questo evita di ruotare giorni con potenziali backup non andati a buon fine, considerato che le rotazioni son soggette a retention, si richierebbe di ruotare, e quindi prima o poi eliminare, backup buoni a fronte di un backup non riuscito. Questo per il daily. Ma per tutti gli altri ? La rotazione avviene indipendentemente dal sync, se mi ritrovassi con giorni interi di backup falliti, la settimanale comunque avverrebbe..........
 
In pratica lui lavora in quest'ordine temporale:
 
yearly
monthly
weekly
sync && daily
 
il daily lo esegue solo se il sync va a buon fine, per i citati motivi.
 
Ma tutte le altre no, se avessi retention del weekly pari a 1 e mi ritrovassi con 7 giorni di backup non andati a buon fine, lui ruota il settimanale, mi cancella un backup buono (quello di 1 settimana fa) e me lo rimpiazza con uno non andato a buon fine (quello di oggi)
 
 
Qualcosa non torna, credo di non aver capito qualche dettaglio.
 
(spero di essermi spiegato in questo lungo pippone)

 ha scritto:


 ha scritto:


 2) non credo di aver afferrato il funzionamento delle rotazioni, ho paura di fare errori grossolani. Magari qualcuno può spiegarmelo diversamente. Lui prima sincronizza (rsnapshot sync), poi ruota l'intervallo più breve (nel mio caso il daily) In caso di sync separato (come è giusto che sia), il daily non viene ruotato, questo evita di ruotare giorni con potenziali backup non andati a buon fine, considerato che le rotazioni son soggette a retention, si richierebbe di ruotare, e quindi prima o poi eliminare, backup buoni a fronte di un backup non riuscito. Questo per il daily. Ma per tutti gli altri ? La rotazione avviene indipendentemente dal sync, se mi ritrovassi con giorni interi di backup falliti, la settimanale comunque avverrebbe..........
 
Forse ho capito.
Lui ruota l'ultimo intervallo inferiore, quindi per fare il weekly, ruota l'ultimo daily in base alla retention. Se il daily manca perchè il sync non è stato eseguito, la rotazione del weekly non avviene, come da log:
 
 
echo 27538 > /var/run/rsnapshot/mioserver.pid 
/var/backups/rsnapshot/mioserver/daily.6 not present (yet), nothing to copy

[…]
 
Ossignore del quoting…
 
 
-- 
Andrea
 

 mi servono.
 
Veramente intendevo che non mi viene in mente come implementare un controllo
del genere sul mio software di backup ;)
 
Enrico