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 <martin AT lispworks DOT 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 AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users