Date: Sat, 21 Apr 2007 02:08:05 +0200 From: Bernd Walter <ticso@cicely12.cicely.de> To: Mike Wolman <mike@nux.co.uk> Cc: freebsd-fs@freebsd.org Subject: Re: lazy mirror / live backup Message-ID: <20070421000805.GA64413@cicely12.cicely.de> In-Reply-To: <20070421000029.N4559@nux.eros.office> References: <20070420232209.G4559@nux.eros.office> <20070421000029.N4559@nux.eros.office>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Apr 21, 2007 at 12:12:57AM +0100, Mike Wolman wrote: > > According to Mike Wolman: > >>The problem with zfs is you cannot layer it as u can with the geom > >>classes. > > > >Yes and no. It is not as versatile as all geom classes I believe but on > >FreeBSD it is a geom provider. > > I havent played with zfs that much and was unaware that zfs created a > device like the geom classes. > > >>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. -- B.Walter http://www.bwct.de http://www.fizon.de bernd@bwct.de info@bwct.de support@fizon.de
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070421000805.GA64413>