up vote 7 down vote favorite
4
share [g+] share [fb]

With btrfs hitting production in Oracle EL 14th this month (together with working fsck and scrubbing from Linux 3.2) I was thinking of redesigning my current backup solution to utilise it. Note that I'm thinking about doing it for small amounts of data, less than 10TB, that's fairly static (less than 1% changed daily). In short a SMB/SOHO backup solution.

What the backup should do:

  1. do a LVM snapshot of ext[234]/XFS/JFS on the production server
  2. rsync/transfer changed data to btrfs on backup server
  3. snapshot the btrfs filesystem
  4. drop old snapshots when free space is running low

Pros:

  • All files easily available, no decompression or loop mounting needed
  • Past snapshots also easily available...
  • ... so I can share them as read-only Samba shares (with shadow copy support)
  • Snapshots take minimal amount of space thanks to copy-on-write (snapshot without changes takes literally few KiB on disk)
  • High backup consistency: checksums on files, scrubbing of all data and built-in redundancy

Questions:

  • Is there some backup solution (in form of Bacula, BackupPC, etc.) that is, or can be easily made, aware of copy-on-write file system?
  • Or will I need to use in-home rsync solution?
  • What do people with ZFS boxes dedicated for backup to backup their Linux machines?
link|improve this question
48% accept rate
feedback

3 Answers

up vote 3 down vote

I've done some extensive searching in the last week for something similar. I have found no solutions to do all 4 steps. There are numerous blogs from home users who try the 'rsync to btrfs'-type of backups, and all of the major Btrfs wikis cover how to perform Btrfs snapshots.

There are also quite a few people who are attempting different ways of rotating Btrfs snapshots. However, you are the first person I've seen who wants to rotate snapshots based on disk space. I am playing with btrfs-snap myself which creates a set of hourly, weekly and monthly snapshots, and it's nice and simple.

The Dirvish project seems to meet many of your requirements. Some developers are attempting to integrate Dirvish with Btrfs. However, the Dirvish project seems a bit stalled.

At this point in time, you are ahead of the curve.

link|improve this answer
Well, I just want a backup solution as pain free as BackupPC: when disk space is low, it just deletes old data (old snapshots). While I was afraid that I am ahead of the curve, it's not like ZFS hasn't been with us for the past few years... – Hubert Kario Feb 3 at 23:40
feedback
up vote 1 down vote

I am working on a OS backup system similar to BackupPC. I have thought about this. What has been stopping me from actually implementing that is that you cannot hardlink between subvolumes. You can also only create snapshots of subvolumes -> One subvolume per backup client. Thus the file level deduplication feature cannot coexist with this approach. And that file level deduplication usually saves a lot of space. Do you want to back up only one server?

If btrfs had block level deduplication this problem can be probably avoided, but that is usually unsufferably slow as well...

Then such an approach would of course entail a tight integration with one filesystem (btrfs), so this should be an optional feature.

I'm asking because I'm thinking about adding such a cow feature, but do not know if I should because of the drawbacks listed above.

link|improve this answer
cross-subvolume reflink copy (a semi-hardlink done by cp --reflink) is either already implemented or will be implemented in near future. Online de-duplication in FS is either slow (lessfs) or needs huge amounts of RAM (ZFS) so depending on it would really be a bad feature in backup software. Either way, btrfs-oriented backup software will have a big audience, it's supposed to be the next ext3 after all. – Hubert Kario Feb 13 at 22:53
One more thing: you can work-around this problem by keeping all servers in one subvolume -- you can reflink copy between them (to dedupe) while preserving snapshot capability. You just have to snapshot after you dedupe, you can still snapshot after backuping only a single server! The backups won't take more space if you do the backups one at a time. Alternatively you can backup all servers, dedupe and only then snapshot. This way you can backup few servers at the same time. – Hubert Kario Feb 13 at 23:03
You're right. Didn't think of that. For convenience you can then symlink to the right snapshots in another volume. I did also see a patch for cross-volume hardlink (or --reflink) but it did not look like it made it/or will make it to mainline. I'll really look into that! Now you probably do your backups over ssh. My project is specialized for local networks... (auto discovery and so on) – UrOni Feb 14 at 12:57
Yes, the patch is alive and working, unfortunately not in mainline, I don't know why. I'm trying to bug Chris Mason about it. As for your project, feel free to drop me a line, I'll gladly beta-test it (time permitting). It sure sounds interesting. – Hubert Kario Feb 14 at 23:51
feedback
up vote 0 down vote

According to Avi Miller (his talk during LinuxConf.AU) a btrfs send/receive is being worked on. It'll be faster than rsync since it doesn't need to traverse through directories to find changes in files.. I don't know if there's an expected release date yet though.

There is, however, a utility built into btrfs-progs that lists every file that has changed between snapshots/etc.. btrfs subvolume find-new

link|improve this answer
1  
I want to backup to btrfs, not from... – Hubert Kario Feb 3 at 22:39
feedback

Your Answer

 
or
required, but never shown
discard

Not the answer you're looking for? Browse other questions tagged or ask your own question.