File system stabile per file di grandi dimensioni (backup) per Linux

Quale filesystem sarebbe meglio per i backup? Mi interessa soprattutto la stabilità (in particolare l'incorruttibilità dei file durante i riavvii difficili, ecc.) Ma è altrettanto importante quanto sia efficiente gestire file di grandi dimensioni (> 5 GB).

Inoltre, quali parametri di montaggio dovrei usare?

Il kernel è Linux> = 2.6.34.

EDIT: Io non voglio metodi di backup. Ho bisogno del filesystem per memorizzarli.

Puoi usare ext4 ma consiglierei il montaggio con la journal_datamodalità che disattiverà dealloc (allocazione ritardata) che ha causato alcuni problemi precedenti. La disabilitazione di dealloc rallenta la scrittura di nuovi dati, ma rende meno probabile la perdita di scritture in caso di interruzione dell'alimentazione. Vorrei anche menzionare che è possibile disabilitare dealloc senza utilizzare journal_dataquale ha altri vantaggi (o almeno lo ha fatto in ext3), come letture leggermente migliorate, e credo che un recupero migliore.

Le estensioni aiuteranno ancora con la frammentazione. Le estensioni rendono l'eliminazione di file di grandi dimensioni molto più veloce di ext3, un'eliminazione di dati di qualsiasi dimensione (file singolo) dovrebbe essere quasi istantanea su ext4 ma può richiedere molto tempo su ext3. (qualsiasi misura basata su FS ha questo vantaggio)

ext4 è anche fsckpiù veloce di ext3.

Un'ultima nota, ci sono state correzioni di errori in ext4 fino a 2.6.31? Fondamentalmente mi assicuro che non stai eseguendo un kernel pre 2.6.32 che è un kernel LTS.

XFS è solido come una roccia ed è stato nel kernel per secoli. Esamina strumenti come xfs_freeze e vedi se è quello che stai cercando. So che questo è altamente soggettivo ma ho usato XFS per l'archiviazione dei dati per anni senza incidenti.

Basta usare uno strumento di backup che supporti i checksum. Ad esempio Dar lo fa e supporta backup incrementali. Quindi è possibile eseguire il backup su un file system solido come ext3.

Per i backup vuoi qualcosa di solido / molto stabile. E btrfs o ZFS non sono semplicemente pronti oggi.

btrfs ha un checksum trasparente dei dati scritti su disco e una modalità di scrittura veloce ordinata che è sempre attiva (e molte altre funzionalità di backup) che lo rende attraente per i backup. Vedi https://btrfs.wiki.kernel.org/index.php/Main_Page per maggiori dettagli.

Un aspetto molto importante che non ho visto discusso nelle altre risposte è le caratteristiche di stabilità del layout su disco del filesystem (ad esempio prendere in considerazione la consultazione della documentazione di possibili candidati ext4 , btrfs )

Mentre la base di codice e la quantità di test dei driver del file system codebase sono davvero importanti come hanno mostrato altre risposte, dato che è la protezione dei dati durante la sua lettura e scrittura , il layout / formato su disco è la protezione contro i rischi per i tuoi dati a riposo, che sono forme di difetti hardware come settori illeggibili o bit bit rot .

Per quanto riguarda ext4, che si dice abbia buone caratteristiche per quanto riguarda la base di codice testata a lungo ( https://events.static.linuxfound.org/sites/events/files/slides/AFL%20filesystem%20fuzzing%2C%20Vault%202016_0. pdf mostra che ci è voluto più tempo per trovare bug in esso rispetto ad esempio nel più moderno e più complesso btrfs), ho esaminato la resistenza ext4 a riposo e ho trovato alcune carenze imho, del filesystem altrimenti elogiato.

Considererei prudente (se scelto ext4come " fs di backup solido ") migliorare la recuperabilità (anche se "rafforzandolo") utilizzando lo e2imagestrumento ext4fornito dagli sviluppatori

Il programma e2image salverà i metadati critici del file system ext2, ext3 o ext4 situati sul dispositivo in un file specificato da image-file. Il file di immagine può essere esaminato da dumpe2fs e debugfs, usando l'opzione -i per quei programmi. Questo può aiutare un esperto a recuperare file system catastroficamente corrotti. In futuro, e2fsck sarà migliorato per poter utilizzare il file immagine per aiutare a recuperare un filesystem gravemente danneggiato.

e raccomandare .

È una buona idea creare file di immagine per tutti i filesystem su un sistema e salvare il layout della partizione (che può essere generato usando il comando fdisk -l) a intervalli regolari --- all'avvio, e / o ogni settimana o così. Il file di immagine deve essere archiviato su un filesystem diverso dal filesystem di cui contiene i dati, per garantire che questi dati siano accessibili nel caso in cui il filesystem sia stato gravemente danneggiato.

Considerando che nemmeno tutti i metadati del ext4 layout del disco sono dotati di ridondanza (ovvero il superblocco viene memorizzato più volte in modo ripetuto come una copia, gli indoes sono memorizzati esattamente in 1 solo posto), il che ext4è sicuramente inferiore a btrfsquello fornirebbe almeno checksum per tutti i metadati + i dati del contenuto del file .

Per contrastare questo "difetto" di ext4e renderlo più rock-solidimportante sotto l'aspetto del layout del disco , potrebbe essere ragionevole integrare questa ridondanza e recupero per il contenuto del file tramite par2/ parchive

Nonostante la domanda richieda l'attenzione sulle soluzioni di filesystem, vorrei portare all'attenzione che la maggior parte di ciò che fornisce un filesystem (cache, riviste, recupero dello spazio allocato, allocazione di blocchi ecc.) Non è necessariamente qualcosa di cui i dati di backup trarranno beneficio molto quando viene solo scritto e letto alla rinfusa e raramente. Per questo vorrei prendere in considerazione l'utilizzo di un backup parchiveintegrativo tarcome soluzione di backup più ottimale, poiché la base di codice utilizzata nel processo è ridotta, e quindi ci sono meno bug se ci sono meno "funzionalità".