On Jan 10, 2008, at 5:13 PM, Jim Dunham wrote: > Eric, > >> >> On Jan 10, 2008, at 4:50 AM, Łukasz K wrote: >> >>> Hi >>> I'm using ZFS on few X4500 and I need to backup them. >>> The data on source pool keeps changing so the online replication >>> would be the best solution. >>> >>> As I know AVS doesn't support ZFS - there is a problem with >>> mounting backup pool. >>> Other backup systems (disk-to-disk or block-to-block) have the >>> same problem with mounting ZFS pool. >>> I hope I'm wrong ? >>> >>> In case of any problem I want the backup pool to be operational >>> within 1 hour. >>> >>> Do you know any solution ? >> >> If it doesn't need to be synchronous, then you can use 'zfs send -R'. > > The prior statement could lead one to believe that 'zfs send -R' is > asynchronous replication, which it is not.
Right, should have said "you can leverage 'zfs send -R'". Replication isn't built into core ZFS (at least not yet), but the building blocks to do it are available. > > The functionality ZFS provides via send/recv is known as time-fixed, > or snapshot replication. Here, a non-changing data source, the > snapshot, is synchronized from the source to destination node based on > either a full or differential set of changes. > > Unlike synchronous or asynchronous replication, where data is > continuously replicated in a write-order consistent manner, time-fixed > replication is discontinuous, often driven by taking periodic > snapshots of the changing data, performing the differential > synchronization of the non-changing source data to the remote host, > then waiting until the next interval. > > The most common problem with time-fixed replication is trying to > determine, or calculate the periodic interval to use, since its > optimal value is based on many variables, most of which are changing > over time and usage patterns. How is this different than any asynchronous replication solution? With AVS, can't you tune the async queue? One of the beauties behind using ZFS for async replication is when a network partition happens. When the replication scheme doesn't have intimate knowledge of what its trying to replicate, then it has to copy *every block* over. Which means you have to store more & more blocks while the network is down. Where do you store those blocks? How are they stored (any redundancy)? What happens when you still have plenty of space left in your ZFS pool but your secondary storage for async replication is full? With ZFS and snapshots, you don't have to store the blocks on secondary storage. And when the network comes back up, you don't have to send/recv over every snapshot you've taken but couldn't replicate as the network was down - just the difference between the latest snapshot and the last successfully received/replicated. Feel free to correct me if i've misunderstood how AVS works, but this is a scenario a customer ran into while using VVR. eric _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
