When I upgraded my office workstation to Fedora 32, one of the things that happened is that Amanda backups of its root filesystem stopped working. The specific complaint from Amanda was a report of:

no size line match in /usr/lib64/amanda/rundump (xfsdump) output

This happened because of Fedora bug 1830320, adequately summarized as "ext4 filesystem dumped with xfsdump instead of dump". The cause of this is that Fedora 32's Amanda RPMs are built without the venerable dump program and so do not try to use it. Instead, if you tell Amanda to back up a filesystem using the abstract program "DUMP", Amanda always uses xfsdump regardless of what the filesystem type is, and naturally xfsdump fails on extN filesystems.

I have historically used various versions of the Unix *dump family of programs because I felt that a filesystem specific tool was generally going to do the best job of fully backing up your filesystem, complete with whatever peculiar things it had (starting with holes in your files). ZFS has no zfsdump (although I wish that it did), so most of my workstation's filesystems are backed up with tar, but my root filesystem is an extN one and I used dump. Well, I used to use dump.

At first I was irritated with Fedora packaging and planned to say grumpy things about it. But then I read more, and discovered that this Amanda change is actually a good idea, because using Linux dump isn't a good idea any more. The full story is in Fedora bug 1884602, but the short version is that dump hasn't been updated to properly handle modern versions of extN filesystems and won't be, because it's unmaintained. To quote the bug:

Looking at the code it is very much outdated and will not support current ext4 features, in some cases leading to corrupted files without dump/restore even noticing any problems.

Fedora is currently planning to keep the restore program around so that you can restore any dump archives you have, which I fully support (especially since the Linux restore is actually pretty good at supporting various old dump formats from other systems, which can be handy).

I have some reflexes around using 'dump | restore' pipelines to copy extN filesystems around (eg, and also), which I now need to change. Probably tar is better than rsync for this particular purpose.

(I'll miss dump a bit, but a backup program that can silently produce corrupted backups is not a feature.)

PS: dump is a completely different thing than dumpe2fs; the former makes backups and the latter tells you details about your extN filesystem. Dumpe2fs is part of e2fsprogs and naturally remains under active development as part of extN development.