lazy mirror / live backup

[Mike Wolman]

>>>> For example if you want to create a failover zfs storage pool, if you make
>>>> the zfs pool out of gmirror devices with one being a local device and the
>>>> other being a ggatec device.  You would then have your zfs raidz pool
>>>> replicated on a remote host.  I do not think you can do this with zfs by
>>>> itself as you are not able to layer raidz pool ontop of a load of zfs
>>>> mirrors.
>>>
>>> On plain zfs yes, you can have that.
>>>
>>> zpool create tank raidz mirror da0 da1 mirror da2 da3 mirror da4 da5.
>>
>> So could you do:
>>
>> zpool create rank raidz mirror ad0 ggatec0 mirror ad1 ggatec1 mirror ad2
>> ggatec2
>
> AFAIK you can't do raidz over mirror, unless you mirror at disk layer.
> Just mirror would work for shure.
>
>> Then should the primary fileserver fail would the backup machine be able
>> to import this zfs pool?
>
> This is obviously the primary reason for such a mirror, but it also the
> most insane point about it.
> While you can import it on another machine you completely loose the state
> information, since the backup side is modified in an unknown way.
> That's the case with your gmirror enhancements as well.
> You completely trust the sync state of an offline disk.
>
>> Would you also be able to tune zfs to prefer the local disks to the remote
>> ones?
>
> No, unless you offline them.
>
> But the point with ZFS is that you don't neeed such mirror hacks at all.
> Just create a pool for your data and one or more for backup.
> The backup pools can be on different machines as well - no need to
> ggate the disks.
> Then setup a cron-job to build snapshots on short time regular base.
> "zfs send" it into the "zfs receive" on the backup host.
> E.g. by using ssh.
> This can be done differentially between two snapshots, no need to do
> a full transfer everytime.
> In case you need to switch to the backup side, you can easily rool back
> any side you want to get back in sync.
> You can also just replace the disks on your primary system with the
> disks from the backup and just import the pool.
> This even works for a slow link, because writers don't need to wait
> for the backup system to keep up, wich would be the case for ggate
> based mirrors over slow links.
> And if you still want to disconnect/reconnect drives on the main system
> you can zpool import/export your backup pool disks and run the
> zfs send/receive localy.
> There is no need that the backup disks are of the same size, because
> you copy based on data not disk blocks.
> E.g. your backup pool can be much bigger than the primary and keep
> more snapshots, or it is smaller and keep less snapshots.
> You can use cheap SATA disks to backup a SCSI system.
> You can compress the data on the backup pool, while not using
> compression on the primary pool - or use stronger compression.
>

Thank you for enlightening me on the zfs send and receive stuff, for the 
above example i can see how well suited zfs is.

My only concern is zfs is quite heavy weight (memory wise) compared to 
gmirror and ufs for a simple laptop/desktop setup which you may just want 
to replicate the entire drive and grab the ggatec device and be ready to 
run should anything happen to the machine.

Im sure there are other situations where running zfs on the available 
hardware is not an option compared to gmirror - im not sure what the 
recommended amount for freebsd but as far as i can rember the suggested 
about for solaris is 1Gb - comparing to gmirror i think i have run it on a 
machine doing simple home fileserving with 128Mb.

Mike.