Soluzione 1:
Opzioni per l'accesso rapido e il backup di milioni di file
Prendi in prestito da persone con problemi simili
Sembra molto simile a un tipo di problema più semplice che deve affrontare i server di notizie USENET e i proxy Web di memorizzazione nella cache:centinaia di milioni di piccoli file a cui si accede in modo casuale. Potresti prendere spunto da loro (tranne che in genere non devono mai eseguire backup).
http://devel.squid-cache.org/coss/coss-notes.txt
http://citeseer.ist.psu.edu/viewdoc/download;jsessionid=4074B50D266E72C69D6D35FEDCBBA83D?doi=10.1.1.31.4000&rep=rep1&type=pdf
Ovviamente la natura ciclica del filesystem delle notizie cicliche è irrilevante per te, ma il concetto di livello inferiore di avere più file/dispositivi su disco con immagini compresse e un indice veloce dalle informazioni che l'utente fornisce per cercare le informazioni sulla posizione è molto appropriato.
Filesystem dedicati
Naturalmente, questi sono solo concetti simili a quelli di cui parlavano le persone con la creazione di un filesystem in un file e il montaggio su loopback, tranne per il fatto che puoi scrivere il tuo codice filesystem. Ovviamente, dal momento che hai detto che il tuo sistema era principalmente letto, potresti effettivamente dedicare una partizione del disco (o partizione lvm per flessibilità nel dimensionamento) a questo scopo. Quando vuoi eseguire il backup, monta il filesystem in sola lettura e poi crea una copia dei bit della partizione.
LVM
Ho citato LVM sopra come utile per consentire il dimensionamento dinamico di una partizione in modo da non dover eseguire il backup di molto spazio vuoto. Ma, ovviamente, LVM ha altre funzionalità che potrebbero essere molto applicabili. In particolare la funzionalità "istantanea" che ti consente di congelare un filesystem in un momento. Qualsiasi rm -rf accidentale o qualunque cosa non disturberebbe l'istantanea. A seconda di cosa esattamente stai cercando di fare, potrebbe essere sufficiente per le tue esigenze di backup.
RAID-1
Sono sicuro che hai già familiarità con RAID e probabilmente lo usi già per affidabilità, ma RAID-1 può essere utilizzato anche per i backup, almeno se stai utilizzando RAID software (puoi usarlo con RAID hardware, ma in realtà offre una minore affidabilità perché potrebbe richiedere lo stesso modello/controllore di revisione per la lettura). Il concetto è che crei un gruppo RAID-1 con un disco in più rispetto a quello di cui hai effettivamente bisogno connesso per le tue normali esigenze di affidabilità (ad esempio un terzo disco se usi il software RAID-1 con due dischi, o forse un disco grande e un hardware- RAID5 con dischi più piccoli con un software RAID-1 sopra l'hardware RAID-5). Quando arriva il momento di fare un backup, installa un disco, chiedi a mdadm di aggiungere quel disco al gruppo raid, attendi fino a quando non indica la completezza, facoltativamente chiedi uno scrub di verifica, quindi rimuovi il disco. Ovviamente, a seconda delle caratteristiche delle prestazioni, puoi avere il disco installato la maggior parte del tempo e rimosso solo per scambiarlo con un disco alternativo, oppure puoi avere il disco installato solo durante i backup).
Soluzione 2:
Puoi montare un filesystem virtuale utilizzando il gestore di loopback, ma mentre questo accelererebbe il tuo processo di backup, potrebbe influire sulle normali operazioni.
Un'altra alternativa è eseguire il backup dell'intero dispositivo utilizzando dd. Ad esempio, dd if=/dev/my_device of=/path/to/backup.dd .
Soluzione 3:
Come probabilmente saprai, il tuo problema è la località. Una tipica ricerca su disco richiede circa 10 ms. Quindi solo chiamare "stat" (o open()) su 10 milioni di file posizionati in modo casuale richiede 10 milioni di ricerche, o circa 100000 secondi o 30 ore.
Quindi devi mettere i tuoi file in contenitori più grandi, in modo tale che il numero rilevante sia la larghezza di banda del tuo disco (50-100 MB/sec per un singolo disco, in genere) piuttosto che il tuo tempo di ricerca. Inoltre, puoi lanciarci un RAID, che ti consente di aumentare la larghezza di banda (ma non ridurre il tempo di ricerca).
Probabilmente non ti sto dicendo nulla che tu non sappia già, ma il mio punto è che la tua idea di "contenitore" risolverà sicuramente il problema, e qualsiasi contenitore andrà bene. Probabilmente i montaggi di loopback funzioneranno come qualsiasi altra cosa.
Soluzione 4:
Ci sono un paio di opzioni. Il più semplice, e dovrebbe funzionare con tutti i filesystem Linux, è dd copia l'intera partizione (/dev/sdb3 o /dev/mapper/Data-ImageVol ) a una singola immagine e archiviare tale immagine. In caso di ripristino di singoli file, eseguire il loopback del montaggio dell'immagine (mount -o loop /usr/path/to/file /mountpoint ) e copia i file che ti servono. Per un ripristino completo della partizione, puoi invertire la direzione del dd iniziale comando, ma hai davvero bisogno di una partizione di dimensioni identiche.
A giudicare dal tuo caso d'uso, immagino che i singoli ripristini di file siano un evento molto raro, se mai si verificano. Questo è il motivo per cui un backup basato su immagine ha davvero senso qui. Se è necessario eseguire ripristini individuali più spesso, l'utilizzo di istantanee LVM a fasi sarà molto più conveniente; ma è comunque necessario eseguire il backup basato su immagine per quei disastri critici "abbiamo perso tutto". I ripristini basati su immagini tendono a essere molti più veloce dei ripristini basati su tar semplicemente perché si tratta solo di ripristinare i blocchi, non incorre in un bel po' di operazioni sui metadati con ogni fopen/fclose e può anche essere un'operazione su disco altamente sequenziale per ulteriori aumenti di velocità.
In alternativa, come il video di Google @casey ha indicato menzioni circa a metà, XFS è un ottimo filesystem (se complesso). Una delle utility migliori con XFS è xfsdump utility, che scaricherà un intero filesystem in un singolo file, e generalmente lo fa più velocemente di tar Potere. È un'utilità specifica per il filesystem, quindi può trarre vantaggio dagli interni di fs in modi che tar non può.
Soluzione 5:
Ti suggerirei di provare prima ad aggiornare a EXT4, se non lo stai già eseguendo.
Google ha svolto molte ricerche sul motivo per cui EXT4 è una buona idea.
Dopodiché dovresti esaminare la distribuzione di un'architettura di file system distribuito. Ad esempio:
- http://www.xtreemfs.org/
- http://code.google.com/p/kosmosfs/
- http://hadoop.apache.org/hdfs/