sbiewald373444dBtrfs and LVM don't contradict each other...
nitwhiz1144344dHehe you said "easier to manage" and "LVM" in the same sentence, i got the joke
Backup a database using LVM only seems like a __bad__ idea.
BTRFS is afaik CoW. As such - usage > 80 % - performance bye bye.
I think BTRFS has become better, at least when you don't use RAID mode.
I'd choose LVM over BTRFS - simply because LVM isn't a filesystem.
I dislike complex filesystems for a simple reason: because they're complex.
There are myriads of combinations which might lead to problems - mostly bound to specific kernel versions.
I don't hate ZFS or BTRFS - but I wouldn't run a database on it.
Coming back to first statement: using only LVM / FS snapshots is a bad idea... Since there are running transactions and you end up with an unclean backup in most cases.
Most databases provide an backup / read lock, when used in tandem you can be sure that the backup is clean.
Another reason I'd stay away from CoW filesystems is the fragmentation issue and possible lock contention.
LVM might be slower (depending on configuration/type) than BTRFS, but you'll have fewer nightmares and especially less maintenance work.
@IntrusionCM I simplified just so that I did not have to describe it all. Yes, I am aware that a simple snapshot and of a running DB is a terrible idea and the days would never be consistent.
When doing such backup, I flush all tables with a readlock, then create the snapshot and release the lock. That way data is always consistent.
And finally mount the snapshot and back its contents up, then remove it, keeping the snapshot around would just lead into it filling up and invalidating.