Yes and no.  The reason it isn't quite the same is that RAID storage

    has no ability to recovery corruption generated by the filesystem

    code itself or corruption caused by other parts of the kernel or by

    hardware snafus which occur prior to the data getting onto the platter.
    When you do logical replication, however, the possibility of this sort of

    corruption seeping into all the replicated copies is greatly reduced

    and the replicated copies can check against each other to detect

    even more such cases.  So with replication you get a degree of detection

    plus the ability to recover (correct) the corrupted data.
    Also one always has one and possibly several backups, both on-site

    and off-site.  A standard RAID system does not give you a functional

    backup of your data, it just gives you redundancy.   Replication

    coupled with HAMMER's historical data store gives you a functional

    backup AND replication at the same time, without having to add yet
    This is something I have been thinking about.  It would be possible

    to replicate just a portion of a filesystem but doing it properly would

    require HAMMER to support a 'filesystem within a filesystem' abstraction

    in order to be able to use the same object ids in the replicated subset

    that the originator used.
    Even though only a subset of files are being replicated the target must

    be able to store objects across the source's entire object id space.

    So what you want to do is create a filesystem within the target's

    filesystem to hold the replication of the subset.
    e.g. something like this (pseudo code):
	mkfilesystem /hammer/my_source_backup

	replicate /elsewhere/my_source /hammer/my_source_backup
	mkfilesystem /hammer/my_pictures_backup

	replicate /elsewhere/my_pictures /hammer/my_pictures_backup
    HAMMER is specified such that this sort of thing could be implemented,

    but not for 2.0.  Basically a filesystem-within-a-filesystem would be

...
[ message continues ]

This seems pretty useful to me (backup /home but not /usr), but can't

the same be achieved by using multiple partitions and mounting them

into a big filesystem?
I tried to achieve something similar with mountctl and jscan, but it

didn't worked:
   # only one root partition which contains everything!
   mount_nullfs /home /mnt/fs_to_backup
   mountctl -a -w /tmp/journal /mnt/fs_to_backup:test
Seems like mountctl is not able to work with nullfs-mounted filesystems.
Regards,
   Michael