#3596 Issue open: Unable to create rescue/backup on XFS excluding BTRFS RAID mountpoint¶
Labels: enhancement, support / question
jacollins121 opened issue at 2026-03-30 20:04:¶
Requesting support or just a question¶
Unable to create rescue/backup even while excluding BTRFS mount
Platform¶
Linux x64
Output¶
2026-03-30 16:00:17.587249859 ERROR: Mounpoint /data points to a BTRFS filesystem spanning multiple disk devices which is not yet supported. See: https://github.com/rear/rear/issues/2028
2026-03-30 16:00:17.614796288 Exiting rear mkrescue (PID 3879967) and its descendant processes ...
2026-03-30 16:00:17.676961457 rear,3879967 /usr/sbin/rear -v mkrescue
`-rear,3881596 /usr/sbin/rear -v mkrescue
`-pstree,3881597 -Aplau 3879967
2026-03-30 16:00:17.696813868 Running exit tasks
2026-03-30 16:00:17.700289565 Finished rear mkrescue in 3 seconds
2026-03-30 16:00:17.702684880 Removing build area /var/tmp/rear.6aRqZhUPtY8ttrX
2026-03-30 16:00:17.708078381 End of program 'rear' reached
Additional information¶
I am attempting to create a rear iso backup of my OS drive on my
server
that has an XFS OS drive and a BTRFS RAID1 mounted at /data.
I wish to exclude /data from the recovery image.
Error seems to persist despite excluding the mountpoint that has the BTRFS RAID devices.
local.conf
OUTPUT=ISO
OUTPUT_URL=file:///data/backups/server/
BACKUP_PROG_EXCLUDE=( ${BACKUP_PROG_EXCLUDE[@]} '/data/*' )
pcahyna commented at 2026-03-31 08:07:¶
Try excluding it from layout. Excluding it from backup does not affect filesystem handing in any way. See https://github.com/rear/rear/blob/master/doc/user-guide/06-layout-configuration.md
jsmeix commented at 2026-03-31 08:25:¶
@jacollins121
I did not test anything here so for now
only some general info which may help:
BACKUP_PROG_EXCLUDE only excludes things from
the backup.tar.gz of the files which is made
for BACKUP=NETFS usually by 'tar' - cf. the section
"Relax-and-Recover versus backup and restore" in
https://en.opensuse.org/SDB:Disaster_Recovery
But you need to exclude things from the so called "disk layout"
(disks, partitions, filesystems, logical volumes, mountpoints)
which ReaR remembers and recreates - cf. the section
"How disaster recovery with ReaR basically works" in
https://en.opensuse.org/SDB:Disaster_Recovery
In usr/share/rear/conf/default.conf see the part about
"How to exclude something ----- EXCLUDES -------"
e.g. for ReaR 2.9 online starting at
https://github.com/rear/rear/blob/rear-2.9/usr/share/rear/conf/default.conf#L3415
I think (but I did not test it for your BTRFS RAID case) that
EXCLUDE_MOUNTPOINTS+=( /data )
may "just work" for what you need.
Specifying to exclude the /data mount point alone
may not be sufficient to get automatically its underlying
BTRFS RAID things exculded by ReaR's dependency tracker.
To also exclude underlying BTRFS RAID things you may have
to explicitly specify which "disk layout components" must be
excluded, see the EXCLUDE_COMPONENTS description in
usr/share/rear/conf/default.conf - see also the current
EXCLUDE_COMPONENTS description in our GitHub master code
currently online at
https://github.com/rear/rear/blob/master/usr/share/rear/conf/default.conf#L3564
cf.
https://github.com/rear/rear/commit/626701843a32070080856c960b9e4202102b81d1
jacollins121 commented at 2026-03-31 13:07:¶
adding EXCLUDE_MOUNTPOINTS+=( /data ) in
/usr/share/rear/conf/default.conf did not work or change the error.
jacollins121 commented at 2026-03-31 15:55:¶
I was able to get a backup created by stopping all active processes using /data and unmounting it, but I would like to see if I can do this without taking containers and processes offline.
gdha commented at 2026-04-01 05:46:¶
@jacollins121 Try to use EXCLUDE_COMPONENTS+=( fs:/data )
pcahyna commented at 2026-04-01 10:06:¶
@gdha I would expect EXCLUDE_MOUNTPOINTS+=( /data ) and
EXCLUDE_COMPONENTS+=( fs:/data ) to be equivalent, no?
jacollins121 commented at 2026-04-02 15:42:¶
Same error setting both: EXCLUDE_COMPONENTS+=( fs:/data ) and
EXCLUDE_COMPONENTS=( fs:/data ) in /usr/share/rear/conf/default.conf
jsmeix commented at 2026-04-07 14:24:¶
@pcahyna
from a quick glance at the ReaR scripts I think
EXCLUDE_MOUNTPOINTS+=( /data ) and
EXCLUDE_COMPONENTS+=( fs:/data )
are not equivalent:
# find usr/sbin/rear usr/share/rear/ -type f | xargs grep -l 'EXCLUDE_MOUNTPOINTS'
usr/share/rear/conf/default.conf
usr/share/rear/restore/NBU/default/300_create_nbu_restore_fs_list.sh
usr/share/rear/layout/save/default/320_autoexclude.sh
usr/share/rear/layout/save/default/310_include_exclude.sh
usr/share/rear/backup/NETFS/default/400_create_include_exclude_files.sh
# find usr/sbin/rear usr/share/rear/ -type f | xargs grep -l 'EXCLUDE_COMPONENTS'
usr/share/rear/conf/default.conf
usr/share/rear/layout/save/default/310_include_exclude.sh
usr/share/rear/layout/save/GNU/Linux/200_partition_layout.sh
in particular because default.conf tells (excerpts)
# Exclude filesystems by specifying their mountpoints.
# Will be automatically added to the $BACKUP_PROG_EXCLUDE array during backup
# to prevent the excluded filesystems' data to be backed up.
# Examples: /tmp
# /media/bigdisk
EXCLUDE_MOUNTPOINTS=()
...
# You must also exclude the corresponding mountpoints in EXCLUDE_MOUNTPOINTS (see above)
# otherwise "rear recover" would try to recreate the filesystems onto non-existing LVs.
EXCLUDE_VG=()
and EXCLUDE_COMPONENTS does not mention EXCLUDE_MOUNTPOINTS
so I assume EXCLUDE_COMPONENTS does not automatically exclude
things from the backup when a ReaR internal backup method is used.
Cf.
https://github.com/rear/rear/issues/2772#issuecomment-1069119836
and several other same kind of issues...
pcahyna commented at 2026-04-07 14:38:¶
I assume
EXCLUDE_COMPONENTSdoes not automatically exclude
things from the backup when a ReaR internal backup method is used.
I think it does, because the excluded filesystems do not get backed up
at all in the first place. Have a look at
usr/share/rear/layout/save/default/340_generate_mountpoint_device.sh
(the file $VAR_DIR/recovery/mountpoint_device is then used by
usr/share/rear/backup/NETFS/default/400_create_include_exclude_files.sh).
Otherwise I agree, EXCLUDE_MOUNTPOINTS+=( /data ) and
EXCLUDE_COMPONENTS+=( fs:/data ) are apparently not equivalent. I now
recall seeing the comment in
usr/share/rear/layout/save/default/310_include_exclude.sh and
wondering what is the point of EXCLUDE_MOUNTPOINTS then. That's why I
did not mention EXCLUDE_MOUNTPOINTS when improving section 6 of the
guide.
pcahyna commented at 2026-04-07 14:44:¶
Regarding the original problem, I believe that the inability of
EXCLUDE_COMPONENTS and similar to work around the problem is due to
the fact that ReaR first generates a complete layout and then excludes
stuff from it, therefore it hits the error condition and exits before it
even starts excluding components.
jsmeix commented at 2026-04-07 15:04:¶
I think this Error() exit happens currently unconditioned
cf. https://github.com/rear/rear/pull/3365#issuecomment-2546066766
so none of the EXCLUDE_... settings can help against it
as far as I understand the code in
usr/share/rear/layout/save/GNU/Linux/230_filesystem_layout.sh
(excerpts)
...
supported_filesystems="ext2,ext3,ext4,vfat,xfs,reiserfs,btrfs"
...
read_filesystems_command="mount -t $supported_filesystems | cut -d ' ' -f 1,3,5,6"
...
# Begin of group command that appends its stdout to DISKLAYOUT_FILE:
{
echo "# Filesystems (only $supported_filesystems are supported)."
echo "# Format: fs <device> <mountpoint> <fstype> [uuid=<uuid>] [label=<label>] [<attributes>]"
# Read the output of the read_filesystems_command:
while read device mountpoint fstype options junk ; do
Log "Processing filesystem '$fstype' on '$device' mounted at '$mountpoint'"
...
# Output filesystem specific layout values:
case "$fstype" in
...
(btrfs)
# FIXME: Support for multi-disk BTRFS should be implemented sooner or later
# because it is the default layout for multi-disk Fedora Workstation installations.
# See: https://github.com/rear/rear/issues/2028
if grep -qE 'Total devices ([2-9]|[1-9][0-9]+) ' <(btrfs filesystem show "$mountpoint"); then
Error "Mounpoint $mountpoint points to a BTRFS filesystem spanning multiple disk devices which is not yet supported. See: https://github.com/rear/rear/issues/2028"
fi
...
esac
...
done < <( eval $read_filesystems_command )
...
} 1>>$DISKLAYOUT_FILE
# End of group command that appends its stdout to DISKLAYOUT_FILE
@jacollins121
as a test you may change in that code the current line
Error "Mounpoint $mountpoint points to a BTRFS filesystem spanning multiple disk devices which is not yet supported. See: https://github.com/rear/rear/issues/2028"
to
LogPrintError "Mounpoint $mountpoint points to a BTRFS filesystem spanning multiple disk devices which is not yet supported. See: https://github.com/rear/rear/issues/2028"
i.e. only replace Error by LogPrintError
which makes this no longer a fatal error exit
but only an error message so "rear mkrescue" will proceed
regardless that BTRFS spanning multiple block devices
is not supported.
Then you could specify appropriate EXCLUDE_... settings
to exclude this BTRFS from ReaR's disk layout.
To verify that this BTRFS and all what belongs to it
is sufficiently excluded from ReaR's disk layout
see default.conf about EXCLUDE_COMPONENTS
in our current GitHub master code
(excerpt)
https://github.com/rear/rear/blob/master/usr/share/rear/conf/default.conf#L3591
# To exclude a problematic disk with higher level storage objects on it
# its matching components may have to be specified separately for example like
# EXCLUDE_COMPONENTS+=( /dev/sdX fs:/mountpoint pv:/dev/sdXN ) or similar as needed.
# Verify that all what belongs to /dev/sdX is marked as 'done' in /var/lib/rear/layout/disktodo.conf
# and that all what belongs to /dev/sdX is commented out in /var/lib/rear/layout/disklayout.conf
# to ensure there is no recovery information left as 'todo' or not commented out
# for a disk which should be excluded from the recovery.
which means in your specific case
Verify that all what belongs to /data is marked as 'done'
in /var/lib/rear/layout/disktodo.conf
and that all what belongs to /data is commented out
in /var/lib/rear/layout/disklayout.conf
to ensure there is no recovery information left as 'todo' or
not commented out for what should be excluded from the recovery.
Because you wrote
my server ... has an XFS OS drive and a BTRFS RAID1 mounted at /data
I assume the XFS OS drive and the BTRFS RAID1 are
well separatded disks so to exclude the BTRFS RAID1
you can exclude the whole disk(s) which belong to it
and keep only the well separated XFS OS disk
which should work rather simple and straightforward
compared to if the XFS OS stuff and the BTRFS RAID1
would be mixed up on one same disk device.
jsmeix commented at 2026-04-07 15:14:¶
@jacollins121
In general I recommend to try out our latest GitHub master code
because the GitHub master code is the only place where we fix things
and if there are issues it helps when you use exactly the code
where we could fix things.
See the "QUICK START GUIDE" and "INSTALLATION" parts on
https://github.com/rear/rear
Additionally / alternatively see the section
"Testing current ReaR upstream GitHub master code" in
https://en.opensuse.org/SDB:Disaster_Recovery
how you can try out our current ReaR GitHub master code
without conflicts with your already installed ReaR version.
jsmeix commented at 2026-04-07 15:46:¶
yes,
https://github.com/rear/rear/issues/3596#issuecomment-4199837564
describes the root cause of this issue here
from a higher level point of view.
jacollins121 commented at 2026-04-09 12:49:¶
@jsmeix the workaround changing Error to LogPrintError did work in allowing it to create the backup successfully.
jsmeix commented at 2026-04-09 13:08:¶
@jacollins121
thank you for your info that the workaround actually helped you!
Could you please post here your current etc/rear/local.conf
so that we could see what EXCLUDE_... settings you needed
in practice to get your BTRFS RAID1 things excluded?
[Export of Github issue for rear/rear.]