Try mounting it with options ro,rescue=usebackuproot,nologreplay. If this works you can freshen your backups, and the data can be trusted, but check dmesg to be sure there are no new errors during the backup.
If that doesn’t work then try ro,rescue=all. If this works, you can also freshen the backups, but since data checksum is disabled, there will be no messages about any corrupt data being copied - so I would embargo this backup (flag it somehow so you know it’s maybe suspect). It’s better to have a backup than not have a backup - but you’ll have to do some extra work later to confirm whether the data is OK.
btrfs zero-log
I need to see a complete dmesg to tell you if this is indicated. Only when there are kernel messages indicating a problem with the log tree or log replay should this be used, otherwise it’s preferred to replay the log, which can’t happen if the log is deleted.
Is there any chance my data isn’t gone forever?
Pretty good chance but data recovery on btrfs is tedious if rescue=all doesn’t work. If that doesn’t work either then we need to see the results from
btrfs check --readonly /path/to/block/device
Is there any way I can grab my data and dump it to my external HDD or something to save it?
Best to try one of the rescue mount options. While it doesn’t fix the problem, good chance of getting a read only mount, and then freshen the backups.
Is there a recommended alternative to BTRFS? People keep saying this is a project “in it’s infancy,” well maybe I’d rather have an adult running my files.
Btrfs is a 15 year old project. It’s a mature file system. It’s not perfect but it has a fail rate similar to ext4 and XFS. A big issue we’ve seen over the last decade is drive firmware bugs resulting in wrong ordered writes, followed by a crash or power failure. The wrong order writes aren’t good, but won’t always cause a problem unless something else bad happens like a power loss or crash. Sounds to me like the drive doesn’t always honor flush or fua, the write order was wrong, and now the super blocks point to either an old tree that’s no longer valid or a new tree that wasn’t yet written. There’s many tests every kernel release to make sure the write order is done correctly, so while there are sometimes bugs, the typical cause for something like this is a drive firmware bug. And unfortunately this will affect any file system.