4 ms·

I still fail to see the benefit for a desktop user with ZFS or BTRFS. I find that backing up policy of 2 copies local and one off site (I use CrashPlan) is a ve

by baldfat 10y ago

I still fail to see the benefit for a desktop user with ZFS or BTRFS. I find that backing up policy of 2 copies local and one off site (I use CrashPlan) is a very robust system that saves any data loss. My main data loss comes from hardware problems or a command problem like mv photo.jpg and forget the don't over wirte command. That's a simple fix on my side. I copy the effected file over.

K0SM0S 10y ago
I can only speak for myself, but here's the gist of it. (Not an expert in this field so please bear with me if I'm too fuzzy or not rigorous enough). - COW[0] + snapshotting[1] basically give you git-like rollback/failsafe capability. You could e.g. trigger it manually before updating or tweaking stuff, or have it automated everytime you run some pacman/apt/yast/whatever. - subvolumes[2] give you the features of partitioning without the physical/ordering limitations (each subvol can expand into free space, etc.) Combined with snapshots (you can snapshop each subvol discretely as its own fs), especially towards another physical btrfs drive, and some automation tool (like Snapper from openSUSE or simply crons), your 'machine-wide git' becomes an effective backup solution (1st order at least but you can snapshot to several machines including off-site obviously). So it's a "set it up and forget it" very powerful filesystem base for your machine, regardless of what you do with it. Rollback instantly, automated backups, self-healing in case of corruption, and btrfs in single-disk or RAID 0/1/10 is incredibly performant. It basically allows you to utterly destroy your install and get it back up and running within minutes (if your snapshotting strategy is well devised, it can be as painless as a matter of changing the boot drive and fixing a single UUID entry in the /boot files, literally 5 minutes). Note: on your root drive, on OS install you'd typically subvol /home, /var, /var/log (so as to debug externally), or domain folders like /var/www and so on and so forth. It basically makes most 'nix fs architectures constrain-free of most physical drive limitations. [0]: https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Copy_on_Write_.28CoW.29 https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Copy_o... [1]: https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Snapshots https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Snapsh... [2]: https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Subvolumes https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Subvol...
- baldfat 10y ago
  I ran a btrfs on two production machines and it was more of a headache then a benefit. Now on my server it was a great tool. I could snapshot have an issue then restore to where it was. Desktop has to many file changes and applications from normal uses to be of benefit to me.
  - K0SM0S 10y ago
    Agreed you need a bit of pre-thinking going into this. - I don't see much activity on the root volume, most of it in my case is either from VMs or userland. - For VMs I use discrete subvolumes, different fs/snapshot/backup strategies given the intricacies of this use-case. You'd typically snapshot VMs from the hypervisor itself. - /home is its own subvol, with again specific settings. I typically disable COW on /home but adopt a much more agressive snapshot policy (e.g. every hour). Whereas system (/) can COW a lot with little to no performance impact, but snapshot only once a day is usually fine. Note that I only use SSDs (either 2x RAID 0 over SATA 3, or NVMe) and my workstation is a beefy one; so that may explain why I don't see any resource issue whatsoever with these admittedly heavier filesystems (btrfs being much leaner than ZFS in this regard, depending on how you setup the latter). My personal intuition is that major OS suppliers will eventually move to such 'modern' fs under the hood for most users, if only to provide easy rollback/backup features that actually work fine and fast. But it takes years to validate a new fs on an existing architecture, so I wouldn't expect that for Windows or MacOS until the next 'major' version (post-10.x, amusingly in both cases).
tracker1 10y ago
Beyond what others have said.. raid isn't backup and backup isn't raid.... re-installing your OS and restoring from backup takes a lot of time... recovering from a down disk in a redundant array means you aren't down during that time... install a disk to replace the bad one, and continue about your daily life. That said, it's always an exercise in frustration, and if personal hardware unexpected cost, when a drive dies. That said, it's still less down time than a full recovery.
- baldfat 10y ago
  That's why I said 2 copies :) 1) I have a second hard drive that has a copy of the files from the first drive (They are not raid and it makes saves mechanical errors). It isn't for restoring the OS but for saving the file. I did play with a dd backup solution on a second drive but that wasn't very practical. rsync was way more practical for my needs as a content maker. 2) I have a home server that uses Crashplan that sends the files to their server. This is my offsite backup. If I accidentally delete a file this is where I get my backup copy.
nec4b 10y ago
Snapshots - e.g. i had several versions of xorg.conf to play with Boot environments - saved me many times while learning about BSD Periodic data checks Datasets - are like standalone filesystems which you can tailor for specific use (use compression,...) I have TrueOS instaled on a workstation and I use ZFS raid10 for reliability. I also have offline backups, but it sure is nice not to worry about that, unless something really out of ordinary happens.

by baldfat 10y ago

K0SM0S 10y ago

I can only speak for myself, but here's the gist of it. (Not an expert in this field so please bear with me if I'm too fuzzy or not rigorous enough). - COW[0] + snapshotting[1] basically give you git-like rollback/failsafe capability. You could e.g. trigger it manually before updating or tweaking stuff, or have it automated everytime you run some pacman/apt/yast/whatever. - subvolumes[2] give you the features of partitioning without the physical/ordering limitations (each subvol can expand into free space, etc.) Combined with snapshots (you can snapshop each subvol discretely as its own fs), especially towards another physical btrfs drive, and some automation tool (like Snapper from openSUSE or simply crons), your 'machine-wide git' becomes an effective backup solution (1st order at least but you can snapshot to several machines including off-site obviously). So it's a "set it up and forget it" very powerful filesystem base for your machine, regardless of what you do with it. Rollback instantly, automated backups, self-healing in case of corruption, and btrfs in single-disk or RAID 0/1/10 is incredibly performant. It basically allows you to utterly destroy your install and get it back up and running within minutes (if your snapshotting strategy is well devised, it can be as painless as a matter of changing the boot drive and fixing a single UUID entry in the /boot files, literally 5 minutes). Note: on your root drive, on OS install you'd typically subvol /home, /var, /var/log (so as to debug externally), or domain folders like /var/www and so on and so forth. It basically makes most 'nix fs architectures constrain-free of most physical drive limitations. [0]: https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Copy_on_Write_.28CoW.29 https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Copy_o... [1]: https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Snapshots https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Snapsh... [2]: https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Subvolumes https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Subvol...

baldfat 10y ago
I ran a btrfs on two production machines and it was more of a headache then a benefit. Now on my server it was a great tool. I could snapshot have an issue then restore to where it was. Desktop has to many file changes and applications from normal uses to be of benefit to me.
- K0SM0S 10y ago
  Agreed you need a bit of pre-thinking going into this. - I don't see much activity on the root volume, most of it in my case is either from VMs or userland. - For VMs I use discrete subvolumes, different fs/snapshot/backup strategies given the intricacies of this use-case. You'd typically snapshot VMs from the hypervisor itself. - /home is its own subvol, with again specific settings. I typically disable COW on /home but adopt a much more agressive snapshot policy (e.g. every hour). Whereas system (/) can COW a lot with little to no performance impact, but snapshot only once a day is usually fine. Note that I only use SSDs (either 2x RAID 0 over SATA 3, or NVMe) and my workstation is a beefy one; so that may explain why I don't see any resource issue whatsoever with these admittedly heavier filesystems (btrfs being much leaner than ZFS in this regard, depending on how you setup the latter). My personal intuition is that major OS suppliers will eventually move to such 'modern' fs under the hood for most users, if only to provide easy rollback/backup features that actually work fine and fast. But it takes years to validate a new fs on an existing architecture, so I wouldn't expect that for Windows or MacOS until the next 'major' version (post-10.x, amusingly in both cases).

tracker1 10y ago

Beyond what others have said.. raid isn't backup and backup isn't raid.... re-installing your OS and restoring from backup takes a lot of time... recovering from a down disk in a redundant array means you aren't down during that time... install a disk to replace the bad one, and continue about your daily life. That said, it's always an exercise in frustration, and if personal hardware unexpected cost, when a drive dies. That said, it's still less down time than a full recovery.

baldfat 10y ago
That's why I said 2 copies :) 1) I have a second hard drive that has a copy of the files from the first drive (They are not raid and it makes saves mechanical errors). It isn't for restoring the OS but for saving the file. I did play with a dd backup solution on a second drive but that wasn't very practical. rsync was way more practical for my needs as a content maker. 2) I have a home server that uses Crashplan that sends the files to their server. This is my offsite backup. If I accidentally delete a file this is where I get my backup copy.

nec4b 10y ago

Snapshots - e.g. i had several versions of xorg.conf to play with Boot environments - saved me many times while learning about BSD Periodic data checks Datasets - are like standalone filesystems which you can tailor for specific use (use compression,...) I have TrueOS instaled on a workstation and I use ZFS raid10 for reliability. I also have offline backups, but it sure is nice not to worry about that, unless something really out of ordinary happens.