Hi, We are considering using a ZFS based storage as a staging disk for Networker. We''re aiming at providing enough storage to be able to keep 3 months worth of backups on disk, before it''s moved to tape. To provide storage for 3 months of backups, we want to utilize the dedup functionality in ZFS. I''ve searched around for these topics and found no success stories, however those who has tried did not mention if they had attempted to change the blocksize to any smaller than the default of 128k. Does anyone have any experience with this kind of setup? Regards, Sigbjorn
Hello, we use ZFS on Solaris 10u8 as a backup to disk solution with EMC Networker. We use the standard recordsize 128k and zfs compression. Dedup we can''t use, because of Solaris 10. But we working on to use more feature and look for more improvements... But we are happy with this solution. Hans -- This message posted from opensolaris.org
On Wed, Aug 18, 2010 at 9:48 AM, Sigbjorn Lie <sigbjorn at nixtra.com> wrote:> Hi, > > We are considering using a ZFS based storage as a staging disk for Networker. We''re aiming at > providing enough storage to be able to keep 3 months worth of backups on disk, before it''s moved > to tape. > > To provide storage for 3 months of backups, we want to utilize the dedup functionality in ZFS. > > I''ve searched around for these topics and found no success stories, however those who has tried > did not mention if they had attempted to change the blocksize to any smaller than the default of > 128k. > > Does anyone have any experience with this kind of setup?I tried this with NetBackup, and decided against it pretty rapidly. Basically, we got hardly any dedup at all. (Something like 3%; compression gave us much better results.) Tiny changes in block alignment completely ruin the possibility of significant benefit. Using ZFS dedup is logically the wrong place to do this; you want a decent backup system that doesn''t generate significant amounts of duplicate data in the first place. -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
On Wed, Aug 18, 2010 at 7:51 AM, Peter Tribble <peter.tribble at gmail.com> wrote:> I tried this with NetBackup, and decided against it pretty rapidly. > Basically, we > got hardly any dedup at all. (Something like 3%; compression gave us > much better results.) Tiny changes in block alignment completely ruin the > possibility of significant benefit.We are using Netbackup with ZFS Disk Stage under Solaris 10U8, no dedupe but are getting 1.9x compression ratio :-)> Using ZFS dedup is logically the wrong place to do this; you want a decent > backup system that doesn''t generate significant amounts of duplicate data > in the first place.The latest release of NBU (7.0) supports both client side and server side dedupe (at additional cost ;-). We are using it in test for backing up remote servers across slow WAN links with very good results. -- {--------1---------2---------3---------4---------5---------6---------7---------} Paul Kraus -> Senior Systems Architect, Garnet River ( http://www.garnetriver.com/ ) -> Sound Coordinator, Schenectady Light Opera Company ( http://www.sloctheater.org/ ) -> Technical Advisor, RPI Players
On Aug 18, 2010, at 5:11 AM, Paul Kraus wrote:> On Wed, Aug 18, 2010 at 7:51 AM, Peter Tribble <peter.tribble at gmail.com> wrote: > >> I tried this with NetBackup, and decided against it pretty rapidly. >> Basically, we >> got hardly any dedup at all. (Something like 3%; compression gave us >> much better results.) Tiny changes in block alignment completely ruin the >> possibility of significant benefit. > > We are using Netbackup with ZFS Disk Stage under Solaris 10U8, > no dedupe but are getting 1.9x compression ratio :-) > >> Using ZFS dedup is logically the wrong place to do this; you want a decent >> backup system that doesn''t generate significant amounts of duplicate data >> in the first place. > > The latest release of NBU (7.0) supports both client side and > server side dedupe (at additional cost ;-). We are using it in test > for backing up remote servers across slow WAN links with very good > results.It is always better to manipulate data closer to the consumer of said data. Ideally, applications replicate, compress, and dedup their own data. -- richard -- Richard Elling richard at nexenta.com +1-760-896-4422 Enterprise class storage for everyone www.nexenta.com
Hi, What sort of compression ratio do you get? Sigbjorn On Wed, August 18, 2010 12:59, Hans Foertsch wrote:> Hello, > > > we use ZFS on Solaris 10u8 as a backup to disk solution with EMC Networker. > > We use the standard recordsize 128k and zfs compression. > > > Dedup we can''t use, because of Solaris 10. > > > But we working on to use more feature and look for more improvements... > > > But we are happy with this solution. > > > Hans > -- > This message posted from opensolaris.org > _______________________________________________ > zfs-discuss mailing list zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss > >
Wow, not bad! What is your CPU penalty for enabling compression? Sigbjorn On Wed, August 18, 2010 14:11, Paul Kraus wrote:> On Wed, Aug 18, 2010 at 7:51 AM, Peter Tribble <peter.tribble at gmail.com> wrote: > > >> I tried this with NetBackup, and decided against it pretty rapidly. >> Basically, we >> got hardly any dedup at all. (Something like 3%; compression gave us much better results.) Tiny >> changes in block alignment completely ruin the possibility of significant benefit. > > We are using Netbackup with ZFS Disk Stage under Solaris 10U8, > no dedupe but are getting 1.9x compression ratio :-) > >> Using ZFS dedup is logically the wrong place to do this; you want a decent >> backup system that doesn''t generate significant amounts of duplicate data in the first place. > > The latest release of NBU (7.0) supports both client side and > server side dedupe (at additional cost ;-). We are using it in test for backing up remote servers > across slow WAN links with very good results. > > -- > {--------1---------2---------3---------4---------5---------6---------7---------} > Paul Kraus > -> Senior Systems Architect, Garnet River ( http://www.garnetriver.com/ ) > -> Sound Coordinator, Schenectady Light Opera Company ( > http://www.sloctheater.org/ ) > -> Technical Advisor, RPI Players > >
On Wed, Aug 25, 2010 at 3:27 AM, Sigbjorn Lie <sigbjorn at nixtra.com> wrote:> Wow, not bad! > > What is your CPU penalty for enabling compression?Not noticeable on the server side. The NBU servers are M4000 with 4 dual core CPUs, so we have (effectively) 16 CPUs and 16 GB of RAM. The load does climb to the 7 to 8 region when the server is busiest (over 100 backup jobs running and it is the master server). This server is overkill for NBU, but it was sized to be a V490 but by the time we ordered it the V490 was no longer shipping so we changed over to the M4000 with the same configuration. We do not have good data on the CPU penalty for client side dedupe yet. Based on recent NBU 7.0 issues, we will probably wait for 7.1 to upgrade production.>> We are using Netbackup with ZFS Disk Stage under Solaris 10U8, >> no dedupe but are getting 1.9x compression ratio :-)>> The latest release of NBU (7.0) supports both client side and >> server side dedupe (at additional cost ;-). We are using it in test for backing up remote servers >> across slow WAN links with very good results.-- {--------1---------2---------3---------4---------5---------6---------7---------} Paul Kraus -> Senior Systems Architect, Garnet River ( http://www.garnetriver.com/ ) -> Sound Coordinator, Schenectady Light Opera Company ( http://www.sloctheater.org/ ) -> Technical Advisor, RPI Players
Sigbjorn Stop! Don''t do it... it''s a waste of time. We tried exactly what you''re thinking of... we bought two Sun/Oracle 7000 series storage units with 20TB of ZFS storage each planning to use them as a backup target for Networker. We ran into several issues eventually gave up the ZFS networker combo. We''ve used other storage devices in the past (virtual tape libraries) that had deduplication. We were used to seeing dedup ratios better than 20x on our backup data. The ZFS filesystem only gave us 1.03x, and it had regular issues because it couldn''t do dedup for such large filesystems very easily. We didn''t know it ahead of time, but VTL solutions use something called "variable length" block dedup, whereas ZFS uses "fixed block" length dedup. Like one of the other posters mentioned, things just don''t line up right and the dedup ratio suffers. Yes, compression works to some degree -- I think we got 2 or 3x on that, but it was a far cry from the 20x that we were used to seeing on our old VTL. We recently ditched the 7000 series boxes in favor of a much pricier competitor. It''s about double the cost, but dedup ratios are better than 20x. Personally I love ZFS and I use it in many other places, but we were very disappointed with the dedup ability for that type of data. We went to Sun with our problems and they ran it up the food chain and word came back down from the developers that this was the way it was designed, and it''s not going to change anytime soon. The type of files that Networker writes out just are not friendly at all with the dedup mechanism used in ZFS. They gave us a few ideas and things to tweak in Networker, but no measurable gains ever came from any of the tweaks. If are considering a home-grown ZFS solution for budget reasons, go for it.... just do yourself a favor and save yourself the overhead of "trying" to dedup. When we disabled dedup on our 7000 series boxes, everything worked great and compression was fine with next to no overhead. Unfortunately, we NEEDED at least a 10x ratio to keep the 3 week backups we were trying to do. We couldn''t even keep a 1 week backup with the dedup performance of ZFS. If you need more details, I''m happy to help. We went through months of pain trying to make it work and it just doesn''t for Networker data. best wishes Daniel 2010/8/18 Sigbjorn Lie <sigbjorn at nixtra.com>:> Hi, > > We are considering using a ZFS based storage as a staging disk for Networker. We''re aiming at > providing enough storage to be able to keep 3 months worth of backups on disk, before it''s moved > to tape. > > To provide storage for 3 months of backups, we want to utilize the dedup functionality in ZFS. > > I''ve searched around for these topics and found no success stories, however those who has tried > did not mention if they had attempted to change the blocksize to any smaller than the default of > 128k. > > Does anyone have any experience with this kind of setup? > > > Regards, > Sigbjorn > > > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss >
Hi Daniel, We we''re looking into very much the same solution you''ve tested. Thanks for your advise. I think we will look for something else. :) Just out of curiosity, what ZFS tweaking did you do? And what "much pricier competitor" solution did you end up with in the end? Regards, Sigbjorn Daniel Whitener wrote:> Sigbjorn > > Stop! Don''t do it... it''s a waste of time. We tried exactly what > you''re thinking of... we bought two Sun/Oracle 7000 series storage > units with 20TB of ZFS storage each planning to use them as a backup > target for Networker. We ran into several issues eventually gave up > the ZFS networker combo. We''ve used other storage devices in the past > (virtual tape libraries) that had deduplication. We were used to > seeing dedup ratios better than 20x on our backup data. The ZFS > filesystem only gave us 1.03x, and it had regular issues because it > couldn''t do dedup for such large filesystems very easily. We didn''t > know it ahead of time, but VTL solutions use something called > "variable length" block dedup, whereas ZFS uses "fixed block" length > dedup. Like one of the other posters mentioned, things just don''t line > up right and the dedup ratio suffers. Yes, compression works to some > degree -- I think we got 2 or 3x on that, but it was a far cry from > the 20x that we were used to seeing on our old VTL. > > We recently ditched the 7000 series boxes in favor of a much pricier > competitor. It''s about double the cost, but dedup ratios are better > than 20x. Personally I love ZFS and I use it in many other places, > but we were very disappointed with the dedup ability for that type of > data. We went to Sun with our problems and they ran it up the food > chain and word came back down from the developers that this was the > way it was designed, and it''s not going to change anytime soon. The > type of files that Networker writes out just are not friendly at all > with the dedup mechanism used in ZFS. They gave us a few ideas and > things to tweak in Networker, but no measurable gains ever came from > any of the tweaks. > > If are considering a home-grown ZFS solution for budget reasons, go > for it.... just do yourself a favor and save yourself the overhead of > "trying" to dedup. When we disabled dedup on our 7000 series boxes, > everything worked great and compression was fine with next to no > overhead. Unfortunately, we NEEDED at least a 10x ratio to keep the 3 > week backups we were trying to do. We couldn''t even keep a 1 week > backup with the dedup performance of ZFS. > > If you need more details, I''m happy to help. We went through months > of pain trying to make it work and it just doesn''t for Networker data. > > best wishes > Daniel > > > > > > > > > 2010/8/18 Sigbjorn Lie <sigbjorn at nixtra.com>: > >> Hi, >> >> We are considering using a ZFS based storage as a staging disk for Networker. We''re aiming at >> providing enough storage to be able to keep 3 months worth of backups on disk, before it''s moved >> to tape. >> >> To provide storage for 3 months of backups, we want to utilize the dedup functionality in ZFS. >> >> I''ve searched around for these topics and found no success stories, however those who has tried >> did not mention if they had attempted to change the blocksize to any smaller than the default of >> 128k. >> >> Does anyone have any experience with this kind of setup? >> >> >> Regards, >> Sigbjorn >> >> >> _______________________________________________ >> zfs-discuss mailing list >> zfs-discuss at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss >> >>
IMHO, if U use the backup SW that support dedupe in the SW then ZFS is still a viable solution On 8/26/2010 6:13 PM, Sigbj?rn Lie wrote:> Hi Daniel, > > We we''re looking into very much the same solution you''ve tested. > Thanks for your advise. I think we will look for something else. :) > > Just out of curiosity, what ZFS tweaking did you do? And what "much > pricier competitor" solution did you end up with in the end? > > > Regards, > Sigbjorn > > > > Daniel Whitener wrote: >> Sigbjorn >> >> Stop! Don''t do it... it''s a waste of time. We tried exactly what >> you''re thinking of... we bought two Sun/Oracle 7000 series storage >> units with 20TB of ZFS storage each planning to use them as a backup >> target for Networker. We ran into several issues eventually gave up >> the ZFS networker combo. We''ve used other storage devices in the past >> (virtual tape libraries) that had deduplication. We were used to >> seeing dedup ratios better than 20x on our backup data. The ZFS >> filesystem only gave us 1.03x, and it had regular issues because it >> couldn''t do dedup for such large filesystems very easily. We didn''t >> know it ahead of time, but VTL solutions use something called >> "variable length" block dedup, whereas ZFS uses "fixed block" length >> dedup. Like one of the other posters mentioned, things just don''t line >> up right and the dedup ratio suffers. Yes, compression works to some >> degree -- I think we got 2 or 3x on that, but it was a far cry from >> the 20x that we were used to seeing on our old VTL. >> >> We recently ditched the 7000 series boxes in favor of a much pricier >> competitor. It''s about double the cost, but dedup ratios are better >> than 20x. Personally I love ZFS and I use it in many other places, >> but we were very disappointed with the dedup ability for that type of >> data. We went to Sun with our problems and they ran it up the food >> chain and word came back down from the developers that this was the >> way it was designed, and it''s not going to change anytime soon. The >> type of files that Networker writes out just are not friendly at all >> with the dedup mechanism used in ZFS. They gave us a few ideas and >> things to tweak in Networker, but no measurable gains ever came from >> any of the tweaks. >> >> If are considering a home-grown ZFS solution for budget reasons, go >> for it.... just do yourself a favor and save yourself the overhead of >> "trying" to dedup. When we disabled dedup on our 7000 series boxes, >> everything worked great and compression was fine with next to no >> overhead. Unfortunately, we NEEDED at least a 10x ratio to keep the 3 >> week backups we were trying to do. We couldn''t even keep a 1 week >> backup with the dedup performance of ZFS. >> >> If you need more details, I''m happy to help. We went through months >> of pain trying to make it work and it just doesn''t for Networker data. >> >> best wishes >> Daniel >> >> >> >> >> >> >> >> >> 2010/8/18 Sigbjorn Lie <sigbjorn at nixtra.com>: >>> Hi, >>> >>> We are considering using a ZFS based storage as a staging disk for >>> Networker. We''re aiming at >>> providing enough storage to be able to keep 3 months worth of >>> backups on disk, before it''s moved >>> to tape. >>> >>> To provide storage for 3 months of backups, we want to utilize the >>> dedup functionality in ZFS. >>> >>> I''ve searched around for these topics and found no success stories, >>> however those who has tried >>> did not mention if they had attempted to change the blocksize to any >>> smaller than the default of >>> 128k. >>> >>> Does anyone have any experience with this kind of setup? >>> >>> >>> Regards, >>> Sigbjorn >>> >>> >>> _______________________________________________ >>> zfs-discuss mailing list >>> zfs-discuss at opensolaris.org >>> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss >>> > > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss-------------- next part -------------- A non-text attachment was scrubbed... Name: laotsao.vcf Type: text/x-vcard Size: 221 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20100826/83587a2c/attachment.vcf>