Newsgroup: it.comp.os.linux.sys
Titolo: sincronizzare vagonate di file

La domanda ï¿œ giï¿œ stata posta, ma non ricordo la soluzione.
Ho la necessitï¿œ di effettuare, settimanalmente, il backup
di alcuni server di backup, su dei dischi esterni.
La soluzione che stavo provando era rsync, ovvero
rsync -a --delete /var/backup /mnt/backup
Tutto molto bello, peccato che ï¿œ partito TRE GIORNI FA
ed ï¿œ ancora fermo a:
"building file list ... "
Qualche soluzione piï¿œ rapida per sincronizzare il tutto?
-- 
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito ï¿œ di fare il possibile per la
salvezza degli anni nei quali viviamo,
sradicando il male dai campi che conosciamo.

 Qualche soluzione piï¿œ rapida per sincronizzare il tutto?
Al momento mi sovvengono:
a) Copi l'intero device a blocchi sottostante, soluzione ottima specie se ï¿œ 
su LVM e puoi fare uno snapshot.
b) scegli un filesystem che sia piï¿œ rapido nell'indicizzazione dei files 
rispetto a quello che usi (IMHO in questo caso reiserfs 3.x ï¿œ il migliore)
-- 
Flavio Visentin
Scientists have finally discovered what's wrong with the female brain:
On the left side, there is nothing right, and on the right side, there
is nothing left.

 rsync -a --delete /var/backup /mnt/backup
Se sono server di backup significa che, potenzialmente, tutti i file
precedenti non ti interessano, quindi vai con un cp o dd brutale e
sovrascrivi l'intero disco esterno.
Davide

 sovrascrivi l'intero disco esterno.
Vero, verissimo, ma:
preferirei evitare di copiare 1TB ogni volta.
Con rsync copierei solo gli incrementi.
Il server di backup si va a pescare i dati dai server
di produzione. Poi, il server di backup copia se stesso
su un disco remoto, ma un conto � copiare 500MB alla
settimana (i cambiamenti) che potrei benissimo far
partire il venerd� sera in 2 ore, anzich� far partire
la copia il luned� per ritrovarmela pronta, forse, il venerd�.
-- 
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito � di fare il possibile per la


 rispetto a quello che usi (IMHO in questo caso reiserfs 3.x ï¿œ il migliore)
Ma non ï¿œ possibile, con rsync, passare un elenco di file partendo
da un file? Ad esempio
find > /tmp/lista
rsync --read-from /tmp/lista
senza fargli fare tutta l'analisi.


 senza fargli fare tutta l'analisi.
"L'analisi" consiste nel confrontare le liste "dai due lati", non nel
farne la mera lista.
Un "find" lo sa fare anche rsync da solo, non ï¿œ che ci impieghi piï¿œ di
quanto impieghi il find fatto da te...
-- 
http://bofhskull.wordpress.com/


Ma quanti file hai?
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
www.robyt.eu

 "building file list ... "
Com'è strutturata la gerarchia di directory? Tantissime directory con un 
bel po' di file dentro o un bel po' di directory con *tantissimi* file 
dentro? è tendenzialmente gerarchica o piatta?
-- 
Vide

 preferirei evitare di copiare 1TB ogni volta.
Se per copiare l'intero disco ci impiega 12 ore mentre per cercare i
soli files modificati ci impiega 3 giorni...
Davide

 Ma quanti file hai?
Vagonate ï¿œ il termine piï¿œ corretto.
Ci sono circa 40 server, ciascun server ha, in media, 15
backup di cui 2 completi.
Alcuni di questi server sono mailserver con cariole di mail
in imap, quindi molti, molti, moltissimi file da analizzare.
Occupano poco spazio perchï¿œ molti sono hard-link, ma comunque sia
il buon rsync deve analizzarli tutti.

 dentro? è tendenzialmente gerarchica o piatta?
/var/backup/pc/
1.2.3.4/XXXX/filesystem_del_server
dove XXXX è il numero di backup e 1.2.3.4 è l'ip della macchina
backuppata.
Ogni directory contiene l'intero fs del server backuppato.

 soli files modificati ci impiega 3 giorni...
Se butta male far� cos�, infatti.
Ma magari esisteva una funzione di rsync creata ad-hoc per questa
problematica.
(se con un cp ci fosse un file non leggibile mi muore tutta la copia
o viene saltato candidamente per proseguire con il file successivo?
Non mi ricordo....)

 il buon rsync deve analizzarli tutti.
Ti butto lï¿œ una soluzione da approfondire (ï¿œ solo un concept) ma abbastanza 
intrigante.
Il metodo migliore per copiare i dati in questo caso, come giï¿œ detto, ï¿œ 
certamente quello di copiare il device a blocchi, ma questo ha il problema 
di essere lungo perchï¿œ ricopi sempre tutto. D'altra parte la copia dei file 
trasferisce solo i differenziali ma ci mette una vita per via del filesystem
L'ideale sarebbe quindi quello di copiare del device a blocchi solo i 
blocchi modificati. E qui l'idea: perchï¿œ non usare per questo DRBD?
Imposti il volume del backup sul server principale come nodo primario di 
DRBD e configuri il nodo secondario sul server di "destinazione". Configuri 
poi un link dedicato al backup tra i due server.
La gestione del backup la fai ovviamente in modo diverso dal "normale", ed 
in particolare l'unica cosa che devi fare ï¿œ gestire la connettivitï¿œ tra le 
due macchine.
Il backup avverrebbe cosï¿œ:
*) in condizioni normali tieni in shut la porta ethernet di link della 
macchina secondaria, in modo che per il nodo primario essa risulti 
irraggiungibile.
*) quando vuoi fare il backup attivi la porta e automaticamente drbd 
inizierï¿œ a sincronizzare i due device, riportando tutte le modifiche occorse 
dall'ultima sincronizzazione anche sul secondo nodo.
*) in un ciclo while metti un check al minuto dello stato del device drbd e 
quando arriva allo stato consistente vuol dire che hai terminato il backup e 
rimetti in shut la porta.
Io fossi in te farei qualche prova... :-)


 Io fossi in te farei qualche prova...
Carina, come idea...

 Carina, come idea...
Effettivamente klo sembra :)
Ma come si comporterebbe su un canale con latenza alta (per esempio via 
internet+vpn)? Non che sia il caos dell'OP, eh, solo come curiosità. Non 
vale risposta "andrebbe più lento" :P
-- 
Vide

 internet+vpn)?
Fai un test...;-P

 Ogni directory contiene l'intero fs del server backuppato.
Ti chiedeva come sono le strutture dei fs da backuppare.
-- 
Bye, Lem
Ceterum censeo ISLAM esse delendum
____________________________________________________________________________
Non sprecare i cicli idle della tua CPU: 
http://boinc.berkeley.edu/index.php

 vale risposta "andrebbe più lento" :P
Puoi usare la modalità asincrona, quindi semplicemente si allungherebbe il 
tempo di backup. Ovviamente essendo comunque un sistema di sincronizzazione 
del device a blocchi devi essere sufficientemente sicuro che la 
sincronizzazione si completi prima della partenza del backup successivo, 
altrimenti il sistema potrebbe rallentare considerevolmente.


 
su un problema del genere ci ho sbattuto a lungo e ho fatto miriadi di
prove. Alla fine ho scoperto che nel mio caso a rallentarmi il backup
era l'auditing attivo, visto che per ogni file che backuppava aggiungeva
una entry nel syslog (e io avevo milioni di file piccoli). Comunque, a
parte questo che non è molto importante, ho fatto diverse prove e te
le elenco.
I tool più veloci per fare backup sono 'star', 'rsync', 'partimage', e
in rete penso che vada bene anche netcat (mi pare si chiami 'nc'). 'dd'
in alcuni casi è ottimale, ma se hai dei dischi dove lo spazio è
sottoutilizzato, 'dd' diventa molto lento (perché fa il dump anche dei
settori vuoti e ti fa perdere parecchio tempo).
partimage è il più veloce ma non è compatibile con LVM e forse nemmeno
con il RAID (riconosce solo /dev/sdxx e basta).
'rsync' chiaramente è sia iper-sofisticato sia molto performante. Nulla
da dire contro rsync.
Per quanto riguarda 'star', non è assolutamete vero ciò che riporta la
man page: "Star is a very fast tar". In realtà, avrebbero dovuto
scrivere "start is a slightly fast tar", visto che da prove eseguite, è
appena il 10% più veloce di tar.
Sai come è andata a finire? Ho usato tar.
-- 
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
  printf $i }'; echo

 il backup e rimetti in shut la porta.
Ottimo sistema, ma io non ho un server di destinazione.
E' un semplicissimo storage esterno da 2TB in raid1 che possono
diventare 4TB in raid0. E' un Western Digital MyBook World 2 con porta
ethernet.
Sul server di backup ho giï¿œ impostato un cron che ogni minuto cerca di
pingare il disco esterno. Se lo pinga per 5 secondi di fila vuol dire
che il disco ï¿œ attaccato e quindi monta tramite cifs la share del disco
e da li in poi boh, al momento ho interrotto rsync ma devo trovare
una soluzione.

 vale risposta "andrebbe più lento" :P
Secondo me andrebbe più lento....

 Ti chiedeva come sono le strutture dei fs da backuppare.
Già, ed infatti l'ho detto:
/var/backup/pc/
1.2.3.4/XXXX/filesystem_per_intero
per cui le strutture sono quelle di un intero filesystem
linux: etc, boot, var, home, opt, usr, ...

 Già, ed infatti l'ho detto:
Veramente no, non l'hai detto affatto. :)
I "molti moltissimi" file che devi backuppare come sono organizzati?
In moltissime directory con pochi file ciascuna, o in poche directory
con moltissimi file ciascuna?
*Questo* era il senso della domanda, ovviamente. :)


 considerevolmente.
L'idea è ottima, ma a trasferire 2TB limitato alla velocità dell'adsl
ricevente (facciamo conto 2mbit) mi ci vorrebbe oltre 1 anno, se non
ho fatto casino con i calcoli.
Confermate?

 Sai come è andata a finire? Ho usato tar.
Mi andrebbe benissimo, ma mi preoccupa avere un
backup "archiviato" o "compresso". Sai che sfiga se
in caso di catastrofe, magari tra 2 anni, il backup
risultasse inutilizzabile perchè il tar si è corrotto
a causa di un singolo cluster guasto?
Con i file "sfusi" un singolo cluster danneggerebbe,
molto probabilmente, solo un file.

 *Questo* era il senso della domanda, ovviamente. :)
Però poco fa l'ho detto: sono interi filesystem linux.
Una struttura "standard" linux, salvo casi particolari, ha tanti
file di piccole dimensioni in poche directory.
Basti considerare che il "grosso" dei file è posizionato in 5-6
directory (etc, bin, sbin, usr/bin/ var/lib /lib)..........

 ho fatto casino con i calcoli.
Beh, ovviamente non è cosa da fare su link geografici :-)
Comunque se puoi permetterti il fermo di un giorno del servizio puoi fare 
come si fa normalmente in questi casi, ovvero si ferma il servizio, si fa la 
copia su nastro del device, lo si porta nel sito remoto, si fa il restore 
del nastro sul device omologo e poi si assembla il drbd dicendogli che i due 
membri del mirror sono già sincronizzati. A questo punto si fa ripartire il 
servizio e da quel momento vengono trasferite solo le differenze che non 
sono certamente così tante.
Ovviamente è necessario montare il volume con noatime, ma lo do per scontato :-)


 piccole dimensioni in poche directory.
Sì, ma non parlavi di "svariati terabyte" di roba?
Perché, a parte i dati, la struttura standard di un fs di Linux occupa
al massimo pochissimi GB.
E una struttura standard che occupa pochi GB di roba la rsynchi in pochi
minuti, per esperienza personale.
Quindi la domanda è: i dati di cui parli (la stragrande maggioranza dei byte)
in che struttura di directory sono orgnizzati? Dipenderà da che dati sono,
dagli applicativi che li gestiscono, da come sono stati configurati quegli
applicativi... O no?


 minuti, per esperienza personale.
La prima volta, poi in poche decine di secondi.


 minuti, per esperienza personale.
La prima volta, poi in poche decine di secondi.


 minuti, per esperienza personale.
La prima volta, poi in poche decine di secondi.
-- 


 una soluzione.
Senza offesa, ma questa soluzione ï¿œ una puttanata. Va bene accrocchiare, ma 
con quel che costa al giorno d'oggi un serverino del menga con 4 dischi sata 
da 1TB ï¿œ veramente assurdo adottare in azienda queste "strategie" da cantinari.


 minuti, per esperienza personale.
Ti devi essere perso un pezzo di thread.
Io devo backuppare un server di backup, che backuppa almeno 30 server 
fisici. Per cui ho ALMENO 30 filesystem completi da backuppare, ovvero,
ad oggi, oltre 1tb di dati compressi.
(per non contare le altre 45 vps che dovranno finir sotto backup.
Si, da quando ho messo Xen, pochi mesi fa, ho creato 45 VPS!)

 a causa di un singolo cluster guasto?
Guarda che sono anni che esistono tool per riparare i tar e i gzip. Un 
settore danneggiato fa lo stesso danno in un gzip come in un filesystem 
standard.


 "strategie" da cantinari.
Lo porti te avanti ed indietro il serverino?
Preferisco il disco esterno da 20cm.
Lo attacco e lo stacco. Finita li.
Il server ï¿œ ingombrante, pesante, scomodo e quant'altro.
Io devo fare il backup del backup ovvero il secondo livello,
un disaster recovery che si spera di non usare mai.
Il backup vero e proprio viene fatto da un server vero.

 standard.
E sono affidabili questi tool?
Tu faresti "il backup della tua vita" compresso in gzip o archiviato in tar?

 Tu faresti "il backup della tua vita" compresso in gzip o archiviato in tar?
Assolutamente sì, e difatti è proprio quel che faccio. Ho la mia serie di 
nastri con sopra archivi tgz. Considera anche che in genere non ho mai una 
sola copia dei dati, perché il nastro archiviato del mese di settembre è al 
90% uguale al nastro archiviato di agosto, ecc.ecc. Bisogna essere molto 
sfigati perché salti il backup su disco, salti il backup su nastro e quel 
dato non ci sia nemmeno su versioni del nastro precedenti.
In ogni caso mi sento di correrlo tranquillamente quel rischio.


 In ogni caso mi sento di correrlo tranquillamente quel rischio.
Va bene capo, allora procedo con un tgz.
Quindi prima elimino il file attuale, poi creo il nuovo,
anzichè stare a sincronizzare tutto con rsync.....

 Lo attacco e lo stacco. Finita li.
Allora abbiamo una concezione profondamente diversa su come organizzare il 
backup. Per me il disco ï¿œ un target adatto esclusivamente per il backup 
"online" non per il backup offline. Per quello nella mia mente esistono solo 
ed esclusivamente i nastri.
Un'architettura in cui c'ï¿œ un server di backup che si sincronizza con il 
server principale pensavo fosse utilizzata in un sistema di disaster 
recovery, per fare in modo che nel sito secondario ci sia una copia dei dati 
del sito primario pronta su dischi per abbreviare i tempi di ripristino.
Evidentemente non ï¿œ questo il caso. :-)
Il tuo problema personalmente lo risolverei con un bel LTO4 attaccato al 
server e un bel tar delle ultime versioni dei backup. Sistema pulito, 
efficiente, affidabilissimo e semplicissimo.


 efficiente, affidabilissimo e semplicissimo.
il disco era in casa, l'lto no.......

 il disco era in casa, l'lto no.......
Investire :-)
Sono o non sono importanti quei dati?
Valgono piï¿œ o meno del costo di un LTO?


 Valgono piï¿œ o meno del costo di un LTO?
Non piï¿œ di tanto, sono il backup di un backup.
(ed io, che son furbo e conosco i miei polli, ho
comunque un ulteriore disco di backup di 8 mesi fa)
Si, la soluzione ï¿œ con un nastro, magari una piccola
o piccolissima libreria (consigli per acquisti?) ma
a me il backup serviva subito, e per subito intendo:
mi alzo dalla sedia e attivo lo script di backup collegando
il disco inutilizzato, e non dopo qualche giorno.

 o piccolissima libreria (consigli per acquisti?)
Come sai io lavoro prevalentemente con materiale IBM e per cose piccole la 
TS2900 ï¿œ veramente ficherrima. 8 nastri LTO3/4 (quindi 10TB di spazio 
nastro) in sola 1U di spazio e ad un prezzo che definirei ridicolo :-)


 nastro) in sola 1U di spazio e ad un prezzo che definirei ridicolo :-)
Uhm, deve essermi sfuggita la mail che sicuramente mi hai mandato
con un prezzo spannometrico. 2k, 5k, 10k? :-)
Almeno so di cosa parlare alla prossima riunione, la librerie DELL
costicchiano un po troppo, e 16TB quando ne uso grosso modo 1.5 ï¿œ
fin troppo.

 con un prezzo spannometrico. 2k, 5k, 10k? :-)
Non c'era il prezzo... c'era proprio il link al configuratore IBM con i 
prezzi di listino
IBM Standalone Solutions Configuration Tool
http://www-947.ibm.com/systems/support/supportsite.wss/docdisplay?lndocid=MIGR-62168&brandind=5000008
C'ï¿œ accluso un bellissimo manuale che spiega come usare il programma... :-)
Per questa volta perï¿œ ti risparmio un po' di fatica.
Codice		Descrizione					Prezzo List.
3572S4R		IBM System Storage TS2900 Tape Autoloader	4.490,00
		with LTO4 HH SAS drive and Rack Mount Kit
56Y5994		3 Year Onsite Repair 9x5 Same Business Day	1.620,00
Oppure, piï¿œ o meno allo stesso prezzo, puoi prendere una TS3100 che ï¿œ una 
libreria 2U a 22 nastri e puoi averla anche con tape SCSI LVD oppure FC 
(ovviamente un po' piï¿œ cara).
3573S4S		TS3100 Tape Library Express with Ultrium 4	6.070,00
		SAS Tape Drive and US/CAN 125V Power Cord
42V1874		3 Year Onsite Repair 9x5 Same Business Day	736,00


 ha scritto:

ma non ce l'hai un fetente RAID1 sul server? Ce l'ho io a casa e tu non
ce l'hai sul server?
Ad ogni modo, già che ci sono aggiungo la mia esperienza con 'dump' (e
già ho provato anche quello).
Potrebbe essere in assoluto il più veloce... peccato che... peccato
che.... ho fatto il restore e non è partito più il DB.
Gira, rigira, guarda intorno, guarda sotto e guarda sopra, riesco a
trovare uno dei tanti file che davano problemi. In questo caso era un
file XML. Lo apro e ci trovo dentro caratteri non ascii: mi aveva
sputtanato tutti i file!
La dimensione era identica, ma il contenuto era completamente
sputtanato.
-- 
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
  printf $i }'; echo

Gandalf Corvotempesta wrote:

FAQ di rsync
out of memory
The usual reason for "out of memory" when running rsync is that you are 
transferring a _very_ large number of files. The size of the files doesn't 
matter, only the total number of files. If memory is a problem, first try to 
use the incremental recursion mode: upgrade both sides to rsync 3.0.0 or 
newer and avoid options that disable incremental recursion (e.g., use --
delete-delay instead of --delete-after). If this is not possible, you can 
break the rsync run into smaller chunks operating on individual 
subdirectories using --relative and/or exclude rules.
Prova a fare un ciclo che sincronizzi un backup alla volta.

 Per questa volta perï¿œ ti risparmio un po' di fatica.
Prezzi di listino?
Perchï¿œ in tal caso, il listino IBM ï¿œ giï¿œ piï¿œ basso della controparte
DELL per cui potrebbe essere valutata seriamente dai capi...

 ce l'hai sul server?
Si, ho il raid, ovviamente, ma il raid non è un backup.

 costicchiano un po troppo
Uh? Se non ricordo male, una libreria Dell entry level (ovvero una
Powervault 114T) viene sulle 2800 euro (ovviamente se parliamo di una
TL2000 passiamo sulle 5000 euro e oltre)
Enrico

 rispetto a quello che usi (IMHO in questo caso reiserfs 3.x è il migliore)
Sicuro[1]? Secondo un vecchio test eseguito su Etch[2], i file system
migliori a tal proposito erano Ext3 e XFS
Enrico
[1] e con "Sicuro?" intendo "Hai esperienza diretta a tal proposito?"
(non mi interessa l'ennesimo flame sui file system)
[2] 
http://www.debian-administration.org/articles/388

 (non mi interessa l'ennesimo flame sui file system)
Sì. Ho una macchina con backuppc che fa il backup di circa 150 macchine di 
cui tengo fino a 2 full e 60 incrementali cad.
La struttura del pool di backuppc, è formata da 4 livelli di diretory e 
l'ultima è un'elenco di file con nome uguale all'hash del file, un po' come 
avviene per la cache di squid.
/backuppc/cpool/0/0/0/0000051b647049bfe16d7f99b6659fb1
...
/backuppc/cpool/0/0/0/000fff7a6c253224eee20d1a053dd2e1
...
/backuppc/cpool/f/f/f/fffffcf8b2fb5872de8eebb8aa931238
In ogni dir finale al momento ci sono tra i 2000 e i 2500 files cadauna, 
equamente distribuiti, e diversi di questi hanno oltre 1000 link.
I backup dei singoli host vengono fatti sulla loro dir, poi c'è un job 
giornaliero che verifica se ci sono files duplicati e se ci sono li 
trasforma in link fisici tra loro. questo permette di risparmiare molto 
spazio e nel mio caso si traduce in un pool di 67GB ma che corrisponde ad 
uno spazio non compresso di circa 400GB.
Quando l'ho dovuta migrare su una nuova macchina più performante ho voluto 
sperimentare se scegliendo altri filesystem le performance migliorassero, 
perché il sistema era abbastanza in crisi. Sul vecchio sistema dopo la 
migrazione ho quindi fatto un po' di test, con ext3, XFS e reiserfs, facendo 
un po' di tuning.
Con ext3 è stato peggio che andar di notte; un'occupazione di spazio 
nettamente superiore (oltre il 20% in più) e performance penose (il 
Backup_Nightly ci ha messo oltre il 50% di tempo in più per essere completato.
Con XFS le cose sono andate meglio, ma comunque ancora spazio occupato in 
più e un 10% di performance in meno.
Alla fine sono rimasto su reiserfs con l'opzione noborder.
Per rimanere IT con l'OP è stato proprio in quell'occasione che ho capito la 
differenza abissale che c'è tra salvae il device a blocchi e salvare il 
filesystem che ci sta sopra. :-)


 Si, ho il raid, ovviamente, ma il raid non è un backup.
Soprattutto non e` detto che un dato sia consistente se uno dei dischi
del RAID e` in fase morente. E` con questi presupposti che e` nato il
RAID-Z di Sun
Enrico

 TL2000 passiamo sulle 5000 euro e oltre)
La 114T � troppo piccola.
Solo 1.6TB (due nastri LTO4)
La 124T sarebbe perfetta, 8 nastri LTO4 la versione
pi� piccola, ma costa 4k base-base e si arriva facilmente
a 5k. Possibile che non esista niente da 4 nastri?
4 nastri LTO4 sarebbero 3.2TB nativi e 6.4TB compressi.
Fin troppo per me, devo backuppare 1.5TB
-- 
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito � di fare il possibile per la
salvezza degli anni nei quali viviamo,
sradicando il male dai campi che conosciamo.

 Fin troppo per me, devo backuppare 1.5TB
4 nastri � un "non-sense".
Le librerie si usano per fare il backup senza dover necessariamente 
intervenire manualmente per la sostituzione delle cassette, giornaliera o al 
riempimento. In questo caso 8 nastri � il minimo, 1 nastro al giorno + 1 
nastro di clean.


 ad uno spazio non compresso di circa 400GB.
Hai la mia stessa identica struttura, con la differenza che io
backuppo 30 server (per il momento) ed ho 1.2TB compressi.
Te come 'zzo fai ad avere 400GB non compressi su 150 server?
Lo script notturno è quello di backuppc o l'hai fatto te?
-- 
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito è di fare il possibile per la


 giorno + 1 nastro di clean.
Capito.
Ma io non voglio fare 1 nastro al giorno, a me servono tanti nastri
per 'splittare' il gzippone di backup, ovvero 4 nastri = 4*800*2GB
di dati compressi. Poi il backup sar� fatto 1 volta a settimana o
1 volta al mese, non tutti i giorni (ripeto, � il backup del backup,
il backup 'online' � fatto tutti i giorni)


 Lo script notturno è quello di backuppc o l'hai fatto te?
Standard di backuppc.


 DELL per cui potrebbe essere valutata seriamente dai capi...
su 
ebay.de
 o 
ebay.co.uk
 trovi library a partire da 250 €..
per mia esperienza (invero limitata) dlt/lto e simili non si rompono 
praticamente mai

 considerevolmente.
E se s'aggiungesse anche un po' di lvm alla ricetta? Fai uno snapshot
prima che inizi il processo e sara', poi, di questo che drbd fara' il
mirroring. Cosi' facendo non ci saranno piu' nuove scritture, benche'
asincrone, da sincronizzare ma solamente i blocchi modificati fino al
momento dello snapshot.
Il contro della soluzione drbd e' che il filesystem del dispositivo a
blocchi remoto sara' sicuramente inconsistente ed alcuni dei file che
contiene potrebbero non essere integri.
Fabio

 su 
ebay.de
 o 
ebay.co.uk
 trovi library a partire da 250 €..
Tipo questo:
http://cgi.ebay.co.uk/Tandberg-7164-StorageLoader-LTO-Tape-Library-NEW-SEALED_W0QQitemZ110422355985QQcmdZViewItemQQptZLH_DefaultDomain_0?hash=item19b5af7011
Molto interessante.
Ma fatemi capire una cosa, le librerie LTO, son compatibili
con tutti i nastri LTO-{1,2,3,4} ?
Ovvero, la libreria legge nastri LTO, poi la capacità la fa
il modello di nastro oppure ci vogliono librerie LTO4, LTO3 e
così via?
-- 
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito è di fare il possibile per la


 E se s'aggiungesse anche un po' di lvm alla ricetta?
Dovrei rifare tutto il server.
Sto provando la soluzione con un banale tar senza compressione.
tar cvf /mnt/backup/backup-$(date +%Y%m%d).tar /var/backup/*
è da ieri alle 14.30 che va, ancora non ha finito e mi pare
sia arrivato alla "c":
"/var/backup/cpool/c/d/a/cda3824774178e4ee89194ad7b43f257"
Senza diventar cretino, vedo di anticipare l'acquisto di
una libreria.
A sto punto la domanda diventa:
con una libreria a 8 slot, posso inserire 8 nastri.
Posso fare un unico file splittato sugli 8 nastri oppure
un file può stare al massimo su 1 solo nastro?
Inoltre, considerato che ci mette una cifra di tempo a fare il
tar, le probabilità che si verifichi una catastrofe durante
il termine del backup sono alte. Se, ad esempio, sto backuppando
il nastro 5 di 8 e prende fuoco il server, posso comunque
restorare i nastri 1,2,3,4 perdendo solo il 5,6,7,8 oppure in
tal caso perderei tutto?
Il tar mi pare sia una struttura sequenziale, estrae tutto finchè
non trova qualche cosa di corrotto, ovvero fino al nastro 5 dovrei
riuscire ad estrarre ugualmente.
Confermate?


 riuscire ad estrarre ugualmente.
sì.


 così via?
La libreria normalmente è solo la robotica di gestione dei nastri.
Poi al suo interno ci sono i tape drive e quelli possono essere di tipo 
LTO-{1,2,3,4}. Con LTO è garantita la lettura della versione corrente e 
delle 2 precedenti e la scrittura della versione corrente e quella 
immediatamente precedente.
Questo significa che con un LTO4 puoi leggere sicuramente gli LTO2 e LTO3 e 
puoi scrivere sui nastri LTO4 e LTO3 (nel formato leggibile dai tape LTO3).


 su più nastri.
... senza dover salvare i primi 10 file sul nastro 1 e
gli altri 10 sul nastro due?


 Prova a fare un ciclo che sincronizzi un backup alla volta.
Subscribe. :)
-- 
Bye, Lem
Ceterum censeo ISLAM esse delendum
____________________________________________________________________________
Non sprecare i cicli idle della tua CPU: 
http://boinc.berkeley.edu/index.php

 gli altri 10 sul nastro due?
Dipende dai software.


 non può eccedere le dimensioni del media che lo ospita.
Si, chiaro, ho formulato male la domanda.
Mi chiedevo se fosse possibile fare un multivolume con tar.
Ad esempio dicendogli di riempire tutto il nastro per poi
splittare e passare a quello dopo.


 
La risposta è RTFM.
Da che mondo e mondo, tar ha sempre gestito il multivolume.
(-M -L)
-- 
           |Save our planet!
    Ciao   |Save wildlife!
   roberto |For your E-MAIL use ONLY recycled Bytes  !!
           |roberto poggi   
rpo...@softhome.net

 una libreria.
A 'sto punto, perche` non provi partimage (invece di dd) o dar?
Partimage ti permetterebbe di salvare il contenuto del file system
tenendo in considerazione solo lo spazio utilizzato, mentre dar ti
permette di creare dei backup incrementali, ovviando quindi alla
sincronizzazione dell'intera struttura ogni volta
Enrico

 sincronizzazione dell'intera struttura ogni volta
Prover� anche partimage.
Dar non mi convince, cos� come non mi convincono gli altri metodi
per i backup incrementali. Quanto tempo ci mettono per fare l'analisi
di cosa copiare e cosa no? Mi ritroverei con lo stesso problema di
rsync ma su un programma diverso.
Considera che potrei avere svarati milioni di file (decine), ci sono
almeno 30 filesystem completi di server anche abbastanza grossini,
credo che qualunque programma incrementale impiegherebbe almeno 2
giorni solo per capire cosa fare....

 un programma diverso.
Guarda, il problema lo hai evidenziato perfettamente.
Soprattutto se usi ext3 (o, peggio ancora, filesystem clustered), fare la 
scansione di directory con tantissimi files porta via enorme tempo.
Un rsync non si limita a vedere se un file esiste ma fa anche altre 
operazioni:
- può confrontare la data di modifica di un file,
- se non sbaglio può confrontare il contenuto del file tramite hash
- altre cosine carine.
- preserva gli attributi e gli attributi estesi
Rsync, se ottimizzato, può diventare molto più veloce. 
Analogamente, ottimizzare il filesystem può portare a miglioramenti 
ancora maggiori (come ti hanno detto, usare reiser è sicuramente un 
vantaggio non da poco, ma capisco che migrare N servers su reiser non è 
bello - ed io in prima persona reiser non lo uso perchè non mi fido).
Una alternativa che ti posso fornire è: cerca di tuneare rsync tipo con
-I, --ignore-times          don't skip files that match size and time
    --size-only             skip files that match in size
    --modify-window=NUM     compare mod-times with reduced accuracy
Una seconda:
- usa noatime sui server che devi backuppare, spesso aiuta tantissimo, 
particolarmente sulle partizioni dove tieni i dati di eventuali siti
- usa --exclude per non analizzare e portarti dietro (sia con rsync che 
con tar) i dati inutili, log compresi che sono grossi e che se ruoti in 
maniera standardm ogni giorno ti devi portare dietro.
Un'altra: 
- prova ad utilizzare solamente TAR su SSH
- prova ad eliminare ssh ed usare netcat, se la connessione è sicura, per 
eliminare overhead inutili
Usare tar su socket non ti permette di fare in maniera diretta dei backup 
incrementali, ma se la banda non è un problema, fai la copia fisica di 
tutto il server senza problemi.
Max

 maniera standardm ogni giorno ti devi portare dietro.
Intanto grazie per il consiglio.
Ma hai perso un pezzettino: io ho un singolo server di backup, di cui
voglio fare un ulteriore backup come disaster recovery.
Non devo backuppare direttamente 30 server, per quello ci pensa una
macchina con BackupPC che funziona a meraviglia.
Io devo fare il backup della macchina backuppc.
E' un solo server, che però al suo interno ha una directory con tutti
i filesystem di tutti gli altri 30 server (milioni e milioni di file).
Per cui il problema dei log non esiste, una volta arrivati sul server di
backup i log son statici, non cariano, per cui rsync non li deve
copiare ogni volta.
Ho anche noatime (a dire il vero lo metto quasi ovunque).
Il problema è "logistico". Credo che sincronizzare 10 milioni di file
richieda tempo, ed ottimizzazioni oppure no, ci vorranno sempre giorni.
Comincio ad essere dell'idea che un backup incrementale di tutta questa
roba sia impossibile in tempi umani, basti pensare al fatto che il tar
(tar cvf /mnt/backup/backup.tar /var/backup/*) ovvero senza compressione
sta ancora andando da domenica pomeriggio alle 14-15 circa.
Se una copia diretta dei file richiede 3 giorni, qualunque sistema in
modalità incrementale ne dovrebbe richiedere almeno 4, dato che dovrà
fare un controllo in più su ogni file.

 BackupPC che funziona a meraviglia.
Se ho perso un pezzettino, allora ne aggiungo un altro:
- premeso che per backuppare tutta quella roba il tempo ci vuole e 
quello, purtroppo, non si può comprimere
- io non backuppo totalmente tutti i miei server, ma solo i dati
- di quelli che backuppo totalmente (circa 8), ho questo numero di files:
rumentaio:/var/local/backup/backups# find . -type f | wc -l
674293
Di questi ogni notte mi faccio un rsync totale, un tar incrementale e, la 
domenica, un tar completo e me li archivio e l'intero processo ci mette 
circa 2 ore (su ADSL, visto che è un backup remoto).
Scommettiamo che se fai l'rsync e i successivi tar server per server 
(ovvero per ogni $directory-che contiene-un-server, e non tutte assieme), 
migliori la situazione ? (magari l'hai già fatto)
se hai scriptato in bash, con un ciclo for dovresti risolvere in pochi 
minuti per adattare il tutto.
Max

 minuti per adattare il tutto.
No, non ho provato.
Oggi faccio partire lo script e verifico.
(per la cronaca, il tar di domenica non è ancora terminato.
L'ho appena interrotto perchè mi ha sfracellato i maroni)

 Io devo fare il backup della macchina backuppc. 
se non ricordo male backuppc ha degli script ad hoc per l'estrazione dei 
backup in singoli files tgzippati direttamente su tape ed eventualmente 
trasferimento degli stessi via rsync su host remoto
I would add RTFM ;-)
http://backuppc.sourceforge.net/faq/BackupPC.html#archive_functions

 I would add RTFM ;-)
AFAIK, quella configurazione, che già conoscevo,
serve ad un impostare un backup su tape (che non ho)
oppure in tanti piccoli file.
Non è il mio problema, io posso fare anche un file da 1.6TB,
non mi importa. Devo trovare il modo per ridurre il tempo
necessario a creare tale file, non posso impiegare 4 giorni
ogni volta.
Splittare con BackupPC su file più picolli avrebbe un solo
risultato: 4 giorni di lavoro per ritrovarmi con 160 file
anzichè 1 solo. Il problema rimane, ma si aggiungerebbe
anche la scomodità di avere vagonate di file di archivio.

 ogni volta.
Devo aver seguito poco e male il thread e probabilmente capito anche 
meno, ma se invece che lavorare a livello di filesystem lavori a livello 
di device, non riesci a ridurre i tempi? Lascio alla tua fantasia come 
fare, se con drbd (un secondario asincrono) o con altri block device di 
rete o se hai spazio e altre partizioni/dischi sulla macchina, facendo 
backup in locale del device e poi spostandolo altrove.
Andrea

 backup in locale del device e poi spostandolo altrove.
Non ho provato perchè la directory di backup non è su un filesystem
a se. Dentro c'è altra roba.

 anche la scomodità di avere vagonate di file di archivio.
Però potrebbe comunque essere una soluzione molto intelligente ed adatta 
allo scopo. Invece di salvare TUTTO il pool di backup una volta a settimana, 
salvi giornalmente solo l'ultimo backup di ogni host o di un insieme di 
host. Questo ti tutela dal caso di disastro, ti fa risparmiare spazio e 
tempo e non ti costringe a fare  i salti mortali.
Per esempio potresti salvare l'ultimo backup di 10 server al giorno cosicché 
in 3 giorni fai il backup del backup di tutte le macchine mettendo a rischio 
solo la perdita di 3 giorni di dati; tra l'altro il tar è direttamente 
utilizzabile per il ripristino dell'host, non devi rimettere in piedi un 
server backuppc e poi eseguire il restore
La creazione dei tar io la faccio con lo script allegato; da me è fatto per 
essere usato interattivamente quando devo restorare un host, perché mi copia 
il tar direttamente sul server da cui reinstallo le macchine; con pochi 
adeguamenti può comunque essere adattato al tuo scopo.
Cosa carina dello script è che mentre funziona mette in pausa BackupPC, cosa 
che ti permette di usarlo anche durante l'esecuzione dei Nightly Jobs senza 
penalizzare i tempi di restore.


 La creazione dei tar io la faccio con lo script allegato; 
E se lo allego è meglio :-)


 a se. Dentro c'è altra roba.
Pure!!!


On 20 Ott, 19:33, Gandalf Corvotempesta

Se sei disodinato, non e` colpa mia! :-)
Nel senso che se gli altri dati non ci azzeccano con questi, che ci
stanno
a fare insieme? Spostali e/o comunque creati un device per contenere
solo
quelli di backup, eventualmente ridimensionando quello su cui ci sono
gli
altri che non c'entrano.
A livello concettuale e per ridurre i tempi di backup credo sia la
cosa giusta (TM)
da fare.
In ogni caso io parlavo del source del backup, non del target.
Andrea
Se sono pochi, allora

 risparmiare spazio e tempo e non ti costringe a fare  i salti mortali.
AFAIK, ti vengono generati X file contenenti tutto il pool di backup.
Non mi pare sia scritto nella documentazione che vengono generati file
per ogni host. E' un tool utile per splittare i backup su supporti quali
cd o dvd o nastri, ovvero: devo backuppare 10GB e faccio un file da
10GB splittato in 3 parti da 4GB l'una pronte da essere copiate su dvd.

 Pure!!!
E' la var....
Ho i backup in /var/backup/...
e /var non è un filesystem separato. Non lo è mai sui miei server,
separo solo le sue sotto directory in base alle necessità
(var/log, var/lib/mysql, var/www, tutti fs separati, ma /var sta
nel fs /)
anni fa (4) quando ho fatto il server di backup non ho pensato a
separare la /var/backup perchè in origine il progetto era quello
di tenere i backup per meno tempo (pochi giorni e pochi incrementi),
poi alla fine per praticità ci siamo ritrovati a tenere anche mesi
di backup e decine di incrementali. (a dire il vero: 1 full ogni 7
giorni e 30 incrementali)

 10GB splittato in 3 parti da 4GB l'una pronte da essere copiate su dvd.
Non pensavo alla funzione di archiving, ma alla funzione di restore che ti 
permette di generare un tar del backup che ti interessa.
Leggiti il mio script che fa quello che ti ho detto. Lo invochi con:
./restorehost.sh nomehost
e ti crea il tar.bz2 dell'host nella dir indicata nello script.


 a se. Dentro c'è altra roba.
Eh? Fammi capire, hai un intero set di partizioni/LV montate a piramide
su quel server???
Enrico

 e ti crea il tar.bz2 dell'host nella dir indicata nello script.
Non ho ancora avuto un secondo di tempo per aprire l'allegato...

 su quel server???
Grossomodo, si.
Standard di BackupPC, io faccio il backup del 90% dei dati di circa 30
server (e ripeto, ne mancano altri 45, ma son VPS e son piccole)