Hello, I would like to backup my main zpool (originally called "data") inside an equally originally named "backup"zpool, which will also holds other kinds of backups. Basically I''d like to end up with backup/data backup/data/dataset1 backup/data/dataset2 backup/otherthings/dataset1 backup/otherthings/dataset2 this is quite simply doable by using zfs send / zfs receive. the problem is with compression. I have default compression enabled on my data pool, but I''d like to use gzip-2 on backup/data. I am using b134 with zpool version 22, which I read had some new features regarding this use case (http://arc.opensolaris.org/caselog/PSARC/2009/510/20090924_tom.erickson). The problem is, I don''t understand how to to this. I don''t really care about mantaining former properties but of course that would be a plus. could anyone help me please? Thanks. -- Simone Caldana
> From: zfs-discuss-bounces at opensolaris.org [mailto:zfs-discuss- > bounces at opensolaris.org] On Behalf Of Simone Caldana > > I would like to backup my main zpool (originally called "data") inside > an equally originally named "backup"zpool, which will also holds other > > Basically I''d like to end up with > backup/data > > this is quite simply doable by using zfs send / zfs receive. > > the problem is with compression. I have default compression enabled on > my data pool, but I''d like to use gzip-2 on backup/data.zfs create -o compression=gzip-2 /backup/data zfs send -F data at snap backup/data
> Hello, > > I would like to backup my main zpool (originally > called "data") inside an equally originally named > "backup"zpool, which will also holds other kinds of > backups. > > Basically I''d like to end up with > backup/data > backup/data/dataset1 > backup/data/dataset2 > backup/otherthings/dataset1 > backup/otherthings/dataset2 > > this is quite simply doable by using zfs send / zfs > receive. > > the problem is with compression. I have default > compression enabled on my data pool, but I''d like to > use gzip-2 on backup/data. > I am using b134 with zpool version 22, which I read > had some new features regarding this use case > (http://arc.opensolaris.org/caselog/PSARC/2009/510/200 > 90924_tom.erickson). The problem is, I don''t > understand how to to this. I don''t really care about > mantaining former properties but of course that would > be a plus.I have a similar situation where dedup is enabled on the backup, but not the main pool, for performance reasons. Once the pools are set, I have a script which does exactly what you are looking for using the time-slider snaps. It finds the latest snap common to the main and backup pool, rolls back the backup to that snap, then sends the incrementals in between. It also handles the case of no destination file system and tries to send the first snap. At least in 128a, the auto snapshot seems to delete the old snaps from both pools, even though it is not configured to snap the backup pool, which keeps the snap count sane on the backup pool. I would never claim the script is world-class, but I run it hourly from cron and it keeps the stuff in sync without me having to do anything. Say the word and I''ll send you a copy. Good luck, Marty -- This message posted from opensolaris.org
Il giorno 12/ago/2010, alle ore 15.10, Marty Scholes ha scritto:> Say the word and I''ll send you a copy.pretty please :) thanks (meanwhile, I created the top dataset on the backup pool, set compression to gzip-2, removed any local compression setting on the source dataset children and I am sending one childrean at a time. This way what is sent has no property set and thus inherits the backup dataset one). -- Simone Caldana Senior Consultant Critical Path via Cuniberti 58, 10100 Torino, Italia +39 011 4513811 (Direct) +39 011 4513825 (Fax) simone.caldana at criticalpath.net http://www.cp.net/ Critical Path A global leader in digital communications
Script attached. Cheers, Marty -- This message posted from opensolaris.org -------------- next part -------------- A non-text attachment was scrubbed... Name: zfs_sync Type: application/octet-stream Size: 4005 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20100812/7d9cf374/attachment.obj>