On 8/11/2015 2:04 PM, Phil Stracchino wrote: > On 08/11/15 13:52, Andrey Tataranovich wrote: >> On Tue, 11 Aug 2015 15:47:40 +0100 >> Martin Simmons <mar...@lispworks.com> wrote: >> >>> You could use bls -j with the volume file to scan the whole volume. >>> >>> I recomend use a more secure fileserver to store your backups (RAID, >>> or ZFS). >> This error has happened on mirror raid, so maybe only filesystems >> like zfs/btrfs could solve such problem on system level. I do not >> remember if raid5/6 protect from situation when disk read operation >> return incorrect data without error. > All conventional RAID5/6 implementations that are not copy-on-write and > do not feature periodic scrubbing are potentially vulnerable to silent > disk corruption, aka the "RAID5 write hole". ZFS is the only RAID > implementation which I know to be not vulnerable to this potential > failure mode. https://btrfs.wiki.kernel.org/index.php/RAID56 confirms > that btrfs RAID5/6 is still vulnerable to the RAID5 write hole. btrfs > also cannot yet recover data from parity, and suffers badly from > fragmentation. The honest truth is that btrfs is still an experimental > filesystem that is not nearly stable enough or mature enough for > production use yet, much less for backup storage which absolutely MUST > be reliable.
At the end of the day, RAID, including all raidz levels, is never the answer for data security. Backups are. This is a good example of why multiple backups (on different media) is required. For disk backup, I prefer to use Copy jobs and/or multiple backups writing multiple jobs each to a different disk, rather than using RAID and writing a single job to multiple disks. In other words, treating the disks like tapes. ------------------------------------------------------------------------------ _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
