Re: [ml] Data retention

Domenico Viggiani ha scritto:
[...]
> Io gestisco una situazione simile e ti preauuncio che, comunque le tratti,
> sono sempre ROGNE: non esiste filesystem che se la cavi bene con questo
> numero di file. 

Intanto grazie a tutti per i consigli, in seguito le mie considerazioni:

RAID*: non e' una soluzione, ma un livello (necessario ma non 
sufficiente) di protezione, infatti oltre alla replicazione sul disaster 
recovery, voglio essere ricuro che se brucia lo storage posso ripartire 
da un altro.

Tool che lavorano a livello di files: improponibili per il numero di 
files. Rsync, per esempio, e' andato in crisi con repository molto piu' 
piccoli, con tempi di sincronizzazione di circa 3 giorni.

Appliance vari: EMC non ha convinto molto, sono in attesa di provare 
qualcosa di NetApp e NexSan, vedremo.

Nel frattempo ho pensato di lavorare a livello di filesystem, pensavo di 
mettere tutto sotto lvm e utilizzare la funzionalità di snapshot per 
avere un filesystem bloccato su cui effettuare backup (e mirror remoto) 
tramite dd. L'eventuale restore totale verrebbe fatto sempre come dd, 
mentre il restore di un singolo file (ebbene si, accade) verrebbe fatto 
montando in loop l'immmagine complessiva del disco. Backup e restore 
vengono sempre effettuati tramite NDMP, quindi, tenendo conto che si 
parla di dimensioni contenute si dovrebbe riuscire ad avere un tempo 
ottimale. Due server in cluster gestirebbero il tutto, ed esporterebbero 
ai sistemi interessati via NFS.

Mi rimane il problema della gestione di questi files, pensavo ad un 
applicativo sulla falsa riga di beagle per l'indicizzazione, ma avrei 
bisogno anche di una funzionalità di ricerca (per data). Qualcuno e' a 
conoscenza di qualche soluzione?

Eventualmente anche un'appliance (tipo google search) sarebbe un'idea, 
sempre a patto che gestisca la cancellazione.

Andrea
--
To respect the cat is the beginning of the aesthetic sense. - Erasmus Darwin