Quale filesystem di cui eseguire il backup è il migliore? [chiuso]

Chiuso . Questa domanda è basata sull'opinione . Al momento non accetta risposte.

Vuoi migliorare questa domanda? Aggiorna la domanda in modo che possa essere risolta con fatti e citazioni modificando questo post .

Chiuso 6 anni fa .

Ho appena acquistato un disco per eseguire il backup di tutti i miei documenti e archiviarlo separatamente e non so quale sia il filesystem sotto Linux che mi ha dato maggiore affidabilità. Forse eseguirò il backup una volta al mese e non sarà sempre connesso, ma voglio essere sicuro che i miei dati rimarranno.

Forse ext4?

filesystems backup ext4

— xabim
fonte

Nessun file system specifico farà scomparire i tuoi dati mentre il disco è disconnesso, quindi non è un requisito. (Il supporto stesso potrebbe comunque non riuscire, ma il file system non sarà di grande aiuto.) Questa domanda potrebbe rispondere se si dichiarano i propri requisiti, come la dimensione del disco di backup, la dimensione massima del file necessaria per il backup, il numero di file e tutte le funzionalità specifiche del file system necessarie (hardlink, ACL, attributi estesi, ...). Inoltre, come sottolineato , può valere la pena di considerare un file system diverso da quello sul disco principale.

— un CVn

Risposte:

La domanda è soggettiva.

EXT4 è considerato stabile e supporta l'inserimento nel journal (così come EXT3 ma non EXT2) che aiuta nella corruzione.

BTRFS è ancora sperimentale ma offre molte più funzioni.

Reiser4 , TUX3 , XFS , varie implementazioni ZFS , ecc. Ci sono molte opzioni .

Personalmente, utilizzo EXT4 su tutte le mie unità e non ho avuto problemi con FS.

Non sono a conoscenza di benchmark di stabilità (potrebbero esserci alcuni "white paper"), ma Phoronix ha benchmark di performance

Infine, questa domanda potrebbe essere un duplicato del filesystem Rock-stable per file di grandi dimensioni (backup) per Linux

— solo navigando
fonte

notare che modern (post 2012) ext4fa checksum sulla maggior parte, ma non su tutti i metadati, e purtroppo non sui dati relativi ai contenuti dei file (cosa che fa BTRFS o ZFS). Anche alcune parti della stalla (come in non cambiano più e la base di codice è ben testata) sul layout del disco di ext4sono ridondanti quando ho visualizzato unix.stackexchange.com/a/499668/24394 , ma la maggior parte dei dati non lo è. Se ext4viene utilizzato come backup, considerare di aumentarne la "recuperabilità" tramite lo e2imagestrumento!

— umanità e

Poiché il suggerimento sulle risposte ext4non fornisce né checksum né misure protettive di ridondanza aumentate per i file che archivia, sarebbe consigliabile investire per calcolare - almeno i file molto importanti nel backup fs - par2/ parchivefile, che fornirebbero verificabilità e ripetibilità (a in una certa misura) e proteggono da settori illeggibili che si verificano, aggiungendo a tali file una variabile (di default 5%) dati di ridondanza Reed-Solomon aggiuntivi. Ciò proteggerebbe dalla "corruzione silenziosa" e dal marcio "evidente" .

— umanità e

Prendo sempre un FS diverso per l'unità di backup rispetto all'unità principale solo perché se colpisco uno strano bug FS non lo colpirò sul mio supporto di backup.

— hashier
fonte

Potresti spiegare per favore a che tipo di strano bug FS stavi pensando? (Idealmente con un esempio storico che potrebbe aver influito anche su un'unità di backup)

— Martin Thoma,

Bene, normalmente non copi il file system, ma i file. Ciò significa che devi solo trasmettere i dati e che i file vengono effettivamente creati di nuovo nel file system di destinazione. In questo modo "bug FS" non svolgono alcun ruolo. Solo se esegui il backup del file system nel suo insieme (ad es. Scaricalo con dd), copierai effettivamente i tuoi "bug FS". Ma poi, normalmente non ti preoccupi del file system di destinazione e scarichi direttamente la copia sulla partizione del disco rigido.

— R Kiselev,

@RKiselev sì e no. Hai ancora alcuni vantaggi / svantaggi con diversi file system, come HFS + che viene corrotto dal nulla e altri file system che supportano il checksum dei suoi file (altri solo i metadati), quindi non è una cattiva idea avere diversi fs

— hashier

@RKiselev O APFS stanno solo perdendo i file youtube.com/watch?v=k60NvrJnNOY durante la copia. Qual è esattamente il tuo nome. C'era un altro bug solo un paio di giorni / settimane fa che il file system eseguiva i file se avevano un nome specifico. Un altro FS non lo avrebbe fatto, quindi i bug di FS sicuramente possono morderti, anche se ammetto che è molto improbabile, ma poiché il costo è quasi zero due hanno due unità con FS diversi non vedo alcun motivo per non farlo. (Altre FS diverse hanno caratteristiche diverse, pochissimo supporto FS, ad esempio verifica la somma dei file)

— hashier,

In realtà è stato utile; mi ha aiutato a valutare la situazione - lo trovo utile su Stackexchange. Il video è pertinente, mi preoccupa un po 'di più il fatto che i miei backup di Time machine in rete siano sparsebundles, anche se sono HFS +.

— Andreas,