Newsgroup: it.comp.os.linux.sys
Titolo: Velocizzare ReoBack

Ciao a tutti!
In ufficio usiamo ReoBack per fare i Backup dei nostri Server.
Il programma funziona bene e non ho motivo di lamentarmi.
L'unico problema e' che, su un Server, per fare il Backup ci mette piu' di
9 (NOVE!) ore...
La configurazione e' banale:
File: drbd0
/mnt/drbd0/
Skip: /mnt/drbd0/lost+found/
Il problema e' che /mnt/drbd0 (una delle partizioni DRBD del Cluster) ha
7.4 GB occupati e deve salvarseli tutti.
Il che non sarebbe neanche difficile, ma visto che la maggior parte dei
files sono di dimensioni estremamente ridotte (pagine HTML/PHP, E-Mails,
etc.) per fare un incrementale e capire cosa salvare e cosa no ci mette
una mezza eternita'...
Qualcuno sa dirmi se esiste un modo per velocizzare il tutto?
Pensavo anche di creare piu' files per il Backup (uno per le pagine Web,
uno per le E-Mails, etc.), ma alla fine i dati son sempre quelli e
lanciare piu' istanze di ReoBack contemporaneamente fa comunque salire il
carico del Server e non son mica sicuro che cio' porti dei benefici...
Visto che il Cluster e' di produzione, vorrei evitare gli esperimenti (ci
tengo al posto di lavoro...).
Qualcuno sa darmi qualche consiglio?
Grazie a tutti e buone feste!
Luca Bertoncello
(
luca...@lucabert.de
)
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 Grazie a tutti e buone feste!
vielen spassieren! :-)
-- 
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
  printf $i }'; echo

 7.4 GB occupati e deve salvarseli tutti.
Mi sembra particolarmente lento.
Su uno dei server dove utilizziamo Cobian:
4/9/2009 7:56:31 AM **** Il backup di "backup completo ****" è 
terminato. Sono stati copiati 262921 file(s)  (tempo impiegato: 9 ore, 
54 minuti, 12 secondi) ****
Si tratta di 62,4 GB di dati cioè quasi 9 volte i tuoi (compressi in 
22,3 GB) backuppati quasi nello stesso tempo. Il backup va su un NAS 
nella LAN.

 vielen spassieren! :-)
?!? Questa non l'ho capita...
Ciao


 tener fermo il Cluster per qualche ora mi impalano...
Non riesci a mettere su due pc di prova, replicare il cluster, metterci 
su un backup e fare qualche prova?
Comunque su un cluster che usavamo noi, con 80g di mail e backup via rete 
ci metteva al massimo una notte. Io usavo (uso ancora ma non con quella 
conf) backuppc....backup via ssh e ti fa pure il dedupe ;)
Pier

 impalano...
Se è un cluster con drbd presumo sia un cluster per ridondanza, dato
che
non usi un filesystem condiviso e di conseguenza non puoi avere i nodi
active-active.
In tal caso spegni un nodo, il cluster resta operativo sul secondo
nodo, e tu lavori sul
primo cambiando il filesystem. Quando hai fatto, riattivi il primo
nodo, stacchi il secondo
e ripeti il tutto...
Non devi tenere spento il cluster, anche perchè se così fosse, a che
ti serve il cluster scusa?
Un cluster active-passive che non fa ridondanza, non serve a nulla,
dato che non può bilanciare
nemmeno il carico di lavoro, con ext3 esportato in drbd.
Comunque sia, io con backuppc backuppo il mio server interno, circa
600GB (seicento, no 60)
in poco più di mezza giornata, quando voglio fare il backup completo.
In condizioni normali, con backup incrementale, impiego poche ore, il
backup parte alle 2 di notte
e la mattina alle 9 non è mai in esecuzione perchè già terminato.
Prova backuppc se puoi, anche perchè il programma che stai usando te,
da quel che vedo sul sito,
l'ultima versione è del 2002, ovvero 7 anni fa. una era geologica.

 wrote in message 
news:grqqms$iun$1...@news.newsland.it...


 
Non l'hai capita perché io *non* so il tedesco :-)
Volevo rispondere ai tuoi auguri di buone feste e l'ho fatto
sicuramente in modo maldestro.


 deframmenta con XFS o altro.
a proposito di "altro" che tu citi. Un restore del tar dovrebbe
deframmentare il filesystem.
Quindi si potrebbe: backup -> restore -> backup
E se dovesse funzionare: mkfs.xfs
Comunque è probabilmente un problema sul numero dei file. Perché nel mio
caso, se io dovessi fare un tar su disco di (per assurdo) un solo file
di 33 Giga, impiegherei al massimo 20 minuti. Invece con quella miriade
di file impiego 15 ore.
p.s.: non ho idea di quanti file ci siano, perché un semplice "du" ci
mette almeno 5 minuti prima di uscire, figuriamoci un find con pipe a
wc. Ma qualche volta lo lancio prima di uscire...


 l'ultima versione č del 2002, ovvero 7 anni fa. una era geologica.
Lo so... Me lo sono trovato addosso...
Provero' BackupPC, comunque! Grazie della dritta!
ciao


 sicuramente in modo maldestro.
Ach! Frohe Oster!!!


 formattare alcunche'...
se te spegni il nodo primario lo slave diventa primario e monta la
partizione. a quel
a quel punto tu lavori sul vecchio primario con cavo di rete staccato.
poi riavvii isolando il secondo server in modo da non avere due master
e fai lo stesso lavoro sul secondo server.

 Qualcuno sa darmi qualche consiglio?
Se provi a lanciare rsync sul nodo secondario, quanto ci mette?
Enrico

 a quel punto tu lavori sul vecchio primario con cavo di rete staccato.
Ecco, questo mi mancava...
Pero' la soluzione non e' percorribile in quanto il Server e' dal Provider.
E io in Sala Macchine (del Provider, ovviamente) non ci posso accedere...
Ciao


 Se provi a lanciare rsync sul nodo secondario, quanto ci mette?
secondo me impiegherà lo stesso tempo del tar. La mia ipotesi è che se i
file sono tanti, il problema è l'accesso ai file stessi.
Comunque, io non ho provato (devo dire che l'ho fermato non appena mi ha
sparato fuori il messaggio: building file list....) e magari vale la
pena di provare.


 Se provi a lanciare rsync sul nodo secondario, quanto ci mette?
come va XPN adesso? Riesce finalmente a gestire bene i gruppi grossi?
Io per il momento mi sono buttato su claws-mail e devo dire che mi sto
trovando molto bene.


 E io in Sala Macchine (del Provider, ovviamente) non ci posso accedere...
premesso che se non ti fanno accedere ai server che amministri il
problema non è più tuo ma di chi ha deciso che te non puoi lavorare
sui server, potresti sempre mandare in drop tutto il traffico sulla
ethernet connessa all'altro nodo oppure buttare giù l'interfaccia.



Pero' scusa...questa possibilita' non l'ho mai contemplata...se lascio i 
due server scollegati, poi uno deve diventare per forza il master da cui 
fare la sync...se sullo slave su cui ho formattato in xfs, quando gli 
dico che si deve sincronizzare col master su cui ho ext3, che succede?
Da quello che mi ricordo penso che drbd si incacchi un po', o no?
O ti risincronizza con ext3 e perdi xfs sullo slave.
Se mi ricordo i passaggi bene, la creazione del fs e' successiva alla 
sync dei due devices drbd.
Pier

 Pier
in effetti hai ragione. lui esporta a blocchi per cui esporta anche
il filesystem  soprastante....

 come va XPN adesso? Riesce finalmente a gestire bene i gruppi grossi?
Dipende da cosa intendi con "gruppi grossi". Personalmente tengo una
data retention di 30 giorni e su gruppi tipo questo non ho problemi
Enrico

 file sono tanti, il problema è l'accesso ai file stessi.
Potrebbe essere, pero` c'e` da considerare che rsync e` un software piu`
specifico di tar per compiti del genere e che l'OP sta usando un
software praticamente obsoleto
Enrico
P.S. tra l'altro, cosi` per scrupolo, controllerei che l'opzione
dir_index di ext3 sia abilitata

 accedere...
Fare un ifdown dell'interfaccia drbd?