Which do you prefer and why for HDD or SDD hard disks ? And how is Ext4 with power failures nowadays ? iirc a few years ago there were issues with Ext3 (Yes, Ext3) and I remember a no barrier option was needed ? Is Ext4 much better ? And what FS do you prefer on usb storage ?
I’ve been liking BtrFS for the snapshots, send/receive, and subvolumes/quota.
Cool! Thanks for this. I remember I read about bcachefs years ago. I see that it has made much progress, gets good reviews and it has a sub Reddit with more recent info. I read that the --help only had up to date info (unlike wiki, man page). I hope this will be accepted by upstream Linux kernel.
exfat for simple USB Storage, works on any OS (linux just needs exfat-utils and fuse)
Ext4 for linux drives
wasn’t exfat support included some time ago into the kernel?
Yes, it was added into Linux Kernel 5.4 in November 2019 after Microsoft open-sourced exFAT [quick context overview].
ext4 for extreme reliabilty cases, BTRFS for everything else
ext4 works very well. I had stability issues with btrfs the multiple times I’ve tried it.
Hmm that really depends on the specific situation and use case. For simple usb drives I usually use exFat these days as there are no file permission issues as with ext4. System drive ssd I use ext4 and on the server/nas I use zfs.
I agree with exFAT mostly for that and compatibilty.
With PC I tend to use XFS in comparison both in HDD and SSD.
What about Snapshots in XFS? I think, they added this years ago.
I lived BTRFS for snapshots, but had much problems on an external drive and multiple times data loss… a broken cable was the reason… but the drive wotked with ext4 much better than with btrfs…
And on a hybrid SSHD also btrfs is not the best idea, if you use snapshots (every hour for example eith cron). It makes the SSHD as slow as the HDD behind the SSD-cache…
https://en.wikipedia.org/wiki/XFS#Snapshots
I don’t think that are a good idea in a running environment…
Anyways, for backups I use the traditional way. The thing in which I am interested is data deduplication.
ok. making snapshots with btrfs is also no backup-strategy (alone). But sending the snapshot to an external drive or backup-store is a really good thing for making backups. Much faster than doing this with rsync.
Don’t use rsync. I do them with Nextcloud or Syncthing and sometimes manually.
For other cases, I use a manager for an Hypervisor for VMs to make programmed backups, also including snapshots.
For me, an snapshot is a backup method.
BTRFS-snapshots only is no backup-method. Only if you send them to an external Store (external HD, SAN, NAS…) In case of deduplication and Copy-On-Write, a snapshot is physically the same store-location as the original. Only the few changed parts of the whole filesystem are stored on another physical place on the same HD.
So if you use BTRFS-snapshots you MUST send/receive the snapshots to another medium, if you want to use snapshots as backup. Data-loss is so a big danger.
I think you understand backup not as the real abstract concept but as a sub-class called “a secure way to make a backup”.
If you copy a file to other folder to the same hard drive it is still a backup.
The same happens with the btrfs-snapshots if the idea are for the files or changes you made in an Operating System installation (OpenIndiana with ZFS snapshots made for every system upgrade).
Maybe the example I gave was not enough.
The point of snapshots is serving as some kind of incremental backups always dependent of a main backup or the main instance.
Always the changes are copied, it is valid, even if a delta of a file was the only thing saved.
This applies to systems with deduplication enabled and COW.
Bfrfs for automatic snapshots and easier data recoverability out-of-the-box. I use it on SSD, but I imagine that on a HDD it works just fine too.
Here’s something different. I use several external USB drives with mergeFS + EXT4 to backup my file server (LVM + EXT4).
Cool, thanks for the mergerFS mention. Since this is packaged for Debian, and in Arch Linux AUR, I am eager to try this.