Newsgroup: it.comp.os.linux.sys
Titolo: Backup repository Subversion

Attualmente in produzione ho un server SVN 1.4 su cui sono ospitati una
quarantina di repository. Tutto funzionerebbe se non fosse che un backup
ci mette quasi 5 ore per terminare. Se consideriamo che la dimensione
totale del backup (ovvero l'export di tutti i repository e la creazione
di un archivio tar.bz2 con dentro i dati) e` di 5Gb, direi che il tempo
di esecuzione del backup e` dannatamente eccessivo. Googlando in giro,
sembra che il problema sia dovuto al metodo di backup che uso, ovvero
eseguo un dump tramite svnadmin che, a quanto pare, e` un metodo
giudicato alquanto lento. Come avete risolto voi? Leggendo in giro il
metodo piu` semplice e` eseguire una copia del repository tramite
l'apposito comando (svnadmin hotcopy) e poi eseguire il backup di
quella, cosa che personalmente non mi entusiasma molto (anche se non
dovrei avere problemi in quanto uso fsfs come backend). Inoltre, e`
auspicabile che un cambio di versione di SVN possa migliorare le cose?
Enrico
P.S. attualmente condivido il servizio SVN su di una macchina che ha
anche un database Oracle, dei database PostgreSQL e dei database MySQL.
Se cambio versione, dovro` necessariamente cambiare la macchina (la
macchina attuale non la posso aggiornare), che da fisica diverra`
virtuale (l'hypervisor e` KVM)

 giudicato alquanto lento. Come avete risolto voi?
tar -czvf ...
Davide
-- 
rich & ashamed beat broke & principled
http://tvtropes.org/pmwiki/pmwiki.php/Main/MoneyDearBoy

 tar -czvf ...
Quindi, mi stai dicendo che la cosa migliore e` andare di hotcopy e poi
fare un tar di tutta la struttura cosi` com'e`. Personalmente non mi
piace molto come cosa, visto che il dump era piu` portabile, ma
attualmente non ho molta scelta. Comunque, ho notato un comportamento
strano replicando i dati su di un altro server (sostanzialmente, ci
mette meno tempo), domani vedo meglio e mi regolo di conseguenza
Enrico

 mette meno tempo), domani vedo meglio e mi regolo di conseguenza
Ok, a quanto pare posso imputare i problemi di lentezza alla versione di
Subversion, alla configurazione del sistema operativo o alla macchina su
cui era installato. Replicando completamente il server SVN su di una
macchina virtuale, il backup ci mette 45 minuti circa a completare
nonostante utilizzi la stessa metodologia di backup del vecchio server
(ovvero dump dei repository, tar dei dump, bzip2 del tar).
Enrico
P.S. devo dire che comincio a pensarla come Valentino Volonghi (un
esperto Python): molto meglio un approccio alla FreeBSD, che permette di
mantenere un sistema base (adatto per i software proprietari) ed il
software aggiornato (molto utile con i software FLOSS)

 (ovvero dump dei repository, tar dei dump, bzip2 del tar).
]zac[
bz2 è pesantissimo con file di grosse dimensioni, in questo caso è tassativo
l'uso di gzip come compressione, comprime un pò di meno ma è decine di
volte più veloce sia in compressione che in scompressione.
Senza contare che bz2 consuma una mare di risorse del sistema (in confronto
a gzip).

 volte più veloce sia in compressione che in scompressione.
Lo so, pero` considerando che lo spostamento di server ha giovato alle
prestazioni e che la macchina virtuale *necessariamente* e` meno
performante della macchina fisica, mi porta a pensare che vi sia stata
qualche ottimizzazione su SVN (o su bzip2) che prima non era
disponibile. Se poi consideri che alla stessa ora sulla vecchia macchina
partiva anche il backup di tre database che occupa un totale di 20Gb e
che ci mette mediamente un'ora per eseguire (piu` o meno) gli stessi
passaggi, allora direi che e` piu` che fondato il sospetto che ho
esposto in precedenza
Enrico

 prestazioni e che la macchina virtuale *necessariamente* e` meno
Usare gzip e far fare a tar la compressione (tar -zcvf ...) è la prima cosa
da fare.

 da fare.
Quale parte di "cambiando macchina tutto funziona" non era chiara? :)
Ripeto, prendendo tutti i dati e mettendoli su di una macchina virtuale
dedicata, i tempi sono passati 5 ore ad un'ora scarsa e questo senza
cambiare alcuna metodologia nel backup. Morale della favola, perche`
avrei dovuto usare un altro metodo di compressione quando, a questo
punto, e` palese che il problema era altrove?
Enrico

 Ripeto, prendendo tutti i dati e mettendoli su di una macchina virtuale
]zac[
Quale parte di prima di tutto non è chiara? ( :P ).

 Quale parte di prima di tutto non è chiara? ( :P ).
Ti odio :P
Enrico
P.S. per essere seri, cambiare il metodo di compressione era l'ultima
spiaggia che volevo intraprendere, visto che significava rendere la
metodologia di backup di quei dati disomogenea rispetto alla metodologia
utilizzata in tutti gli altri casi. Tra l'altro, sembra che a regime sul
nuovo server il backup completo ora ci mette 5 minuti :)