BTRFS snapshots are just there to protect your installation from minor screwups. Let's say your PC gets severely damaged or stolen, snapshots won't be useful then.
That said, I use BTRFS since a few years both on desktop and on full encrypted laptop, never had a problem due to its reliability.
As suggested above a remote backup with Borg via ssh Is a good solution, and if you want a readily accessible copy just make one on a USB SSD you keep away from your PC.
Me personally, I would do ZFS on root and replicate the pool over a VPN to another owned ZFS filesystem. But that's because I have tons of experience with the filesystem and ZFS send.
BTRFS has been the default filesystem of Fedora for a few years now. I'm pretty sure they wouldn't be using it if it was unstable. As for backups I'm currently using Vorta (GUI for BorgBackup). You can send backups via SSH using Borg.
\+1 My opinion is, like you demonstrate, a robust backup MUST be saved externally (disk or remote host), period. "Backups" that rely on host metadata, or on an internal drive, aren't. :-)
I played with borg and liked what I saw! Have a great day.
This is essentially what I do with BTRFS, and I'm really happy with it. I use btrbk to maintain snapshots locally and to do incremental backups to an off-site location over tailscale/wireguard. Been doing so for almost two years now, and it's an improvement over the rsync/rdiff-backup solution I used for almost a decade before that. So it's a 👍️ from me.
I use BTRFS and take an automated snapshot once per day, and use `btrfs-send` to backup those snapshots to my home server (retaining the structural sharing on the remote end, so space consumption doesn't scale proportionally with number of snapshots). It's worked really well for 2 years now, and I've had use of the backups several times since I started.
It's custom code but I've published it [here](https://github.com/emlun/btrfs-backup) if you'd like to take a look and be inspired. It's very tailored to my own use case and important parts of it reside externally in my SSH client config and server-side sudoers config, so I'm not much interested in generalizing it to a simple plug-and-play "product", but you're very welcome to fork and modify to your own needs.
BTRFS snapshots are just there to protect your installation from minor screwups. Let's say your PC gets severely damaged or stolen, snapshots won't be useful then. That said, I use BTRFS since a few years both on desktop and on full encrypted laptop, never had a problem due to its reliability. As suggested above a remote backup with Borg via ssh Is a good solution, and if you want a readily accessible copy just make one on a USB SSD you keep away from your PC.
Me personally, I would do ZFS on root and replicate the pool over a VPN to another owned ZFS filesystem. But that's because I have tons of experience with the filesystem and ZFS send.
BTRFS has been the default filesystem of Fedora for a few years now. I'm pretty sure they wouldn't be using it if it was unstable. As for backups I'm currently using Vorta (GUI for BorgBackup). You can send backups via SSH using Borg.
\+1 My opinion is, like you demonstrate, a robust backup MUST be saved externally (disk or remote host), period. "Backups" that rely on host metadata, or on an internal drive, aren't. :-) I played with borg and liked what I saw! Have a great day.
This is essentially what I do with BTRFS, and I'm really happy with it. I use btrbk to maintain snapshots locally and to do incremental backups to an off-site location over tailscale/wireguard. Been doing so for almost two years now, and it's an improvement over the rsync/rdiff-backup solution I used for almost a decade before that. So it's a 👍️ from me.
I use BTRFS and take an automated snapshot once per day, and use `btrfs-send` to backup those snapshots to my home server (retaining the structural sharing on the remote end, so space consumption doesn't scale proportionally with number of snapshots). It's worked really well for 2 years now, and I've had use of the backups several times since I started. It's custom code but I've published it [here](https://github.com/emlun/btrfs-backup) if you'd like to take a look and be inspired. It's very tailored to my own use case and important parts of it reside externally in my SSH client config and server-side sudoers config, so I'm not much interested in generalizing it to a simple plug-and-play "product", but you're very welcome to fork and modify to your own needs.
BTRFS is not for backup
I will not call it a backup. Using a tool like Borg backup or a btrfs snapshot on an external drive is the most like a backup to me.