13

I want to configure a desktop system in which the home filesystem would be redundant (e.g. RAID-1), and would have weekly snapshots taken. I've already done this with ZFS, the snapshot system is wonderful, and with send/recv you can easily create backups on external media. Unfortunately, at that point, I want GNU+Linux and not FreeBSD or Solaris, so I'm looking for suggestions for good alternatives.

I reckon that my alternatives are:

  1. btrfs - it seems to be exactly what I need, it has snapshots and commands that allow you to easily replicate zfs send. Yet all documentation mentions that it's still experimental. I can't seem to find any actual reports on its reliability or usability issues. Can you point me to any information on that issue that could clarify whether it would be a possible choice? I have a large preference for this option, mostly because I don't want to reformat the drives when btrfs becomes ready, but I there's no information on whether it's usable at all, whether it's a silly idea to use it, etc. The question that I cannot get the answer to is what does "experimental" mean.
  2. lvm snapshots and ext4 - preferably not, since it can consume an awful amount of space when new files are created. Creating 200 GB files requres 200 GB free space and 200 GB additionally for snapshots. I also have found it unreliable -- failed metadata rewrite results in an unreadable PV. I'm wondering how btrfs would compare here.
  3. A single filesystem (ext4) on a RAID-1 array with custom COW snapshots with hardlinks (like cp -al). That's my current preference if I can't use btrfs.

So how experimental btrfs is, which should I choose, and do I have any other options? What if I don't keep external incremental backups, would that affect my choice?

Improve this question
11
  • 1
    Re #3: Hardlinking doesn't really make a good backup... if you modify or damage the original, the same happens to all "copies".
    – u1686_grawity
    Mar 16, 2011 at 19:49
  • Good point. I didn't consider that. Thanks.
    – TestUser16418
    Mar 16, 2011 at 22:18
  • @grawity, You shouldn't be directly modifing snapshots. That is the point of them. They should be a 'read-only' picture of your system sometime in the past.
    – g19fanatic
    Mar 17, 2011 at 11:36
  • @g19fanatic: Exactly my point. If your "snapshots" are being done by hardlinking, then modifying the live copy of a file will cause the "snapshots" to change too (because hardlinks do not copy data).
    – u1686_grawity
    Mar 17, 2011 at 14:44
  • 1
    @grawity: i do not think he means hardlinking in the same manner that you are thinking. Think of the Apple TimeRestore software. it does an initial copy of everything as its first snapshot. Then every snapshot afterwards uses a hardlink to files in the snapshot before it for files that haven't changed. If a file has changed, then either a diff or a directly copy is done instead hardlinking to the previous snapshot. using this method, when you modify a live file, you will not be changing your backups as they work off of snapshots and not the live data.
    – g19fanatic
    Mar 17, 2011 at 16:05

4 Answers 4

Reset to default
0

This answer is maintained for historical reasons and may not apply to current versions of btrfs.

btrfs is experimental in the sense that it is still subject to change. As a result, btrfs may not be fully stable. In addition, since there is currently no fsck for btrfs, it is possible to damage the filesystem and render it unusable in the event of a power failure because there is no means to recover from the damage. See the brtfs wiki for more information on this filesystem. Until a filesystem check utility is ready, I would not recommend btrfs, and it would probably be best to select option 3.

Improve this answer
1
  • By design, BTRFS does not really need fsck. BTRFS has checksums, so a scrub will reliably detect errors (and fix them if possible, depending on redundancy). Other filesystems like ext4 can clean up after a crash but they won't know for sure if something has been corrupted. Also, most basic features of BTRFS shouldn't really be considered experimental anymore.
    – basic6
    Nov 12, 2015 at 19:11
7

While nobody has officially blessed it, I'd personally guess that it's ready for production use.

Some reasons that are typically given for not using it in production: the on-disk format may not be stable, there is no btrfsck, there is no support available. So let's examine those:

That last one is what really says it for me. If Oracle – the company that maintains the software – is now willing to give you commercial support for it, then it's probably ready. Of course they have a strong interest in never saying that the open source version (which is, as far as I know, the same software, just no support contract) is actually ready for use, because they want you to buy the support and of course they don't want to be blamed if you go off by yourself and do something unsupported and blow up your disks, but I doubt they'd be willing to support it at all if they really thought it would lose data.

Improve this answer
2

Snapper is a tool that will automate this process for you. You can have hourly snapshots if you want, different snapshot intervals per subvolume, easy rollback, automatically delete old snapshots afaik it even has a gui.

Improve this answer
1

While this doesn't answer the btrfs question, you wrote "I've already done this with ZFS, the snapshot system is wonderful, and with send/recv you can easily create backups on external media. Unfortunately, at that point, I want GNU+Linux" and as of 2013 there is http://zfsonlinux.org/ - enjoy!

Improve this answer
1
  • ZFSonLinux works very well indeed. But it has to be installed manually (there are some repositories though).
    – basic6
    Nov 12, 2015 at 19:14

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .