I saw it is possible to run the Array with BTRFS drives. As I'm using more BTRFS features (snapshots for backups, etc) I'd like to know if it is a viable option and if there is any risk involved migrating from XFS?

 

Right now I'm running an array with two paraties (XFS), a nvme raid 0 (BTRFS), another SSD raid 10 (BTRFS) and a backup raid 10 (BTRFS) with HDDs. My Idea would be to integrate the backup raid into the array and perform backups to the array rather then to a separate instance. Further I could stripe the SSDs to get more space there and have also backups inside the array.

 

Good Idea? Bad Idea?

9 minutes ago, Jaster said:

I'd like to know if it is a viable option and if there is any risk involved migrating from XFS?

It's viable, I use it, there's always some risk migrating or just moving a lot of data in general, also btrfs is not as robust as xfs against hardware issues, etc, so make sure you have good backups.

 

You can use snapshots for backups but since each disk is an individual filesystem it needs to be done disks by disk, that is what I do, snapshot each disk then send/receive to an identical server.

How does Parity interact with this? Can I still lose a disk and restore it?

Shares will not work across disks, but I rather have to create share by disk?...

6 minutes ago, Jaster said:

How does Parity interact with this? Can I still lose a disk and restore it?

Parity does not care what files system is in use as it works at the level of raw disk sectors and has no idea of what those sectors are actually being used for.  As a result parity works the same regardless of the file system used.

34 minutes ago, Jaster said:

Shares will not work across disks

Shares work across disks, like any other filesystem.

So the increased risk is losing the filesystem on a disk, but this can be recovered by the usual parity rebuild?

If I want to backup something from another pool, I need to create an entry point based on a disk instead of a share, right? Anything else I do not see?

 

Is there something like a "save procedure" to migrate from xfs to btrfs?

8 minutes ago, Jaster said:

So the increased risk is losing the filesystem on a disk, but this can be recovered by the usual parity rebuild?

Parity helps if you lose a disk, it can't help with filesystem corruption, any filesystem.

 

9 minutes ago, Jaster said:

If I want to backup something from another pool, I need to create an entry point based on a disk instead of a share, right?

Depends on the tool you use for the backup, if for example you use rsync you can still do it on a user share like any other filesystem, if you want to use snapshots then you can only do it disk by disk.

 

10 minutes ago, Jaster said:

Is there something like a "save procedure" to migrate from xfs to btrfs?

There's a sticky in this forum on how to migrate from resier to xfs, the same principle applies to any filesystem conversion.

Lets say I run into a filesystem corruption, can I just restore the whole disk with paraties in place?

5 minutes ago, Jaster said:

Lets say I run into a filesystem corruption, can I just restore the whole disk with paraties in place?

The parity system is used to recover from a failed hard drive, not file system corruption 

30 minutes ago, Jaster said:

Lets say I run into a filesystem corruption, can I just restore the whole disk with paraties in place?

It will "restore" the exact same corrupt filesystem on the new disk. Parity keeps track of the bits on the disk, not whether or not files exist or are corrupt or not.

 

Parity doesn't have any concept of files or filesystems or data, only what bit was recorded at what position on the disk. Organizing the bits into valid readable data isn't part of parity.

Sorry if it sounds silly, but is there a way to backup/replicate the filesystem without the actual data?

Edited December 28, 20205 yr by Jaster

2 minutes ago, Jaster said:

Sorry if it sounds silly, but is there a way to backup/replicate the filesystem without the actual data?

Why would you ever want to back up an empty file system?   You can always create an empty file system on a drive by using the format option.

I'm not talking about an empty file system. The data is protected by the parity. The Filesystem is not - so why not back it up?

11 minutes ago, Jaster said:

I'm not talking about an empty file system. The data is protected by the parity. The Filesystem is not - so why not back it up?

Sounds as if you mis-understand how parity works.   The data and the file system are integral to each other and parity has no concept of them being separate.  It is the the individual sectors on the disk that are protected by parity regardless of their contents and what they are used for.  In that sense as long as it has no corruption the file system is also backed up as it is simply the sectors on the disk that hold the file system control information about which sectors are holding the data.  If you DO get file system corruption for any reason then this would be faithfully reflected in the parity information.

 

Corruption can occur any time, so my questions is how to overcome it. Full backup of the drive, sure...

However if this is the risky part about BTRFS, I'd like to cover this with a little bit less effort (hardware wise). So... would it be possible to create a backup or an "external" RAID just for the file system? E.g. Having the array with all HDDs protected by parity, while the file system resides on a RAID 5/10 Pool of SSDs. Or just have a job that back ups the file system on an hourly/daily basis?

1 hour ago, Jaster said:

Full backup of the drive, sure...

Correct.

 

1 hour ago, Jaster said:

So... would it be possible to create a backup or an "external" RAID just for the file system? E.g. Having the array with all HDDs protected by parity, while the file system resides on a RAID 5/10 Pool of SSDs. Or just have a job that back ups the file system on an hourly/daily basis?

You create a backup of the data, not filesystem, not disks.