[kwlug-disc] Filesystems for backups

[Remi Gauvin]

On 2019-08-16 1:57 p.m., bob+kwlug at softscape.ca wrote:
> To piggy-pack onto this somewhat with my thoughts and experiences with BTRFS,
> 
> Totally agree with the "RAID 1" setup of BTRFS. The other RAID levels had serious design (or coding?) flaws in them and the developers announced that people should STOP using them for production (or anything you cared about). So that means you are down to 50% usable capacity if you do this. I'm not sure what the current status of this is, but I have not come across anything saying RAID5/6 was ready to consider again.

Without going into technical bable, it's still not a good idea to use
Raid5/6 other than for testing.

You can use Raid 5 with metadata in Raid 1, (there's a chance of damage
to data files in the case of a disk failure, but you'll be able to tell
*what* files need restoring from backup.).. But Raid 6 would be
pointless,  (works, but if metadata is Raid 1, you don't get 2 drive
redundancy.)

However, one thing to keep in mind about BTRFS, it has zero tollerance
for data corruption.  That makes it a little fragile, (one the plus
side, there's no silent corruption that propagates to your backups.)

One thing that keeps coming up on the mailing list is people finding
combinations of hardware and block device layers, (LUKS, lvm, Bcache,
sometimes all together.) that breaks kernel Flush commands, and writes
happen out of sequence.

All that being said, I've been very happy with BTRFS and I think it's a
great option for a backup drive.  Rsync --inplace combined with Snapper
for snapshots is the perfect backup repository.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://kwlug.org/pipermail/kwlug-disc_kwlug.org/attachments/20190816/7f75a066/attachment.sig>