> Bryan, > > Thanks for your suggestion. I am looking at this as > more of a DR solution. However, I might be able to > use your method if my data can be a little old. > Perhaps this way I could sync the data nightly with a > remote site to make sure that I am no more than 24 > hours behind in the case of a disaster.
Yeah, totally understood. However, if your RPO can be a little bit old, you gain a lot in bandwidth conservation if you have a slow link between the two sites by replicating incrementals on a schedule. Let me give a simplified example. Consider for a moment replicating a single database that is 5MBs in size. What if that same database had a "rate of change" of a gigabyte per hour(maybe all the data is constantly changing within the database). It's not growing in size, but it is being heavily modified. If you use a constant replication strategy with in order delivery, suddenly you have to have enough buffer and bandwidth to transfer 24GBs a day in this example for a 5MB database. However, if you replicate once a night instead, you just have to have enough buffer and bandwidth to replicate 5MBs. My example is a bit extreme, but I wanted to illustrate the difference between the bandwidth and resource conservation of a small RPO vs. a longer RPO. I'm afraid another prob you might run into with trying to replicate ZFS with AVS or array based replication is that you might have to replicate entire Pools instead of single filesystems. That may or may not be a problem depending on your filesystem architecture or DR needs. Maybe you need all the filesystems anyway. :) ~Bryan This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
