[Discuss] rsnapshot vs. rdiff-backup

[Edward Ned Harvey (blu)]

> From: discuss-bounces+blu=nedharvey.com at blu.org [mailto:discuss-
> bounces+blu=nedharvey.com at blu.org] On Behalf Of Kent Borg
> 
> Once the snapshot exists, it is there, self-consistent and unchanging,
> it can be read at leisure to copy off to a backup.  The volume doesn't
> need to be unmounted or anything.
> 
> What mechanisms do other systems have to make this easier?  Some
> internals-to-internals data transport that is more efficient,
> opportunistic, etc., than a file interface?

It is far, far, lightyears better to use the internal "btrfs send" rather than using a utility on top of the filesystem.  Tools that work on top of the filesystem have to look at metrics such as mtime, and file size, to determine if the file's changed, and sometimes those are wrong, and if it's a big file with a few small blocks changed then they're not smart enough to intelligently locate the changed blocks, etc.

In COW (zfs & btrfs) you represent all the data in your filesystem with a tree structure.  To make a snapshot, you just set aside a copy of the root node, and mark the tree as read-only.  Instantaneous.  Future writes will reference the original tree, except for new blocks.  To calculate the difference between this snapshot and a later snapshot, all you have to do is scan the new filesystem tree for anything that doesn't reference the original, so you've got the advantage of pre-indexed list of all changed blocks.  Far, farr, faster than scanning the whole filesystem on top of the filesystem layer, inspecting all the characteristics of all the files to try inferring data changes based on that information.  Instead, it's streamlined and serialized list of changed blocks.  Can't get any more efficient than that.