> > The only way you will know of decrypting and decompressing causes a > problem in that case is if you try it on your systems. I seriously > doubt it will be unless the system is already heavily CPU bound and > your > backup window is already very tight. >
That is true. > > My understanding of the NDMP protocol is that it would be a > "translator" > that did that it isn't part of the core protocol. > > The way I would do it is to use a T10000C tape drive and have it do the > compression and encryption of the data. > > http://www.oracle.com/us/products/servers-storage/storage/tape- > storage/t10000c-tape-drive-292151.html > > The alternative is to have the node in your NDMP network that does the > writing to the tape to do the compression and encryption of the data > stream before putting it on the tape. > I see. T10000C is a monster to have if possible ;-). And doing the job on NDMP node(Solaris) needs extra software, is it correct? > > For starters SSL/TLS (which is what the Oracle ZFSSA provides for > replication) or IPsec are possibilities as well, depends what the risk > is you are trying to protect against and what transport layer is. > > But basically it is not provided by ZFS itself it is up to the person > building the system to secure the transport layer used for ZFS send. > > It could also be write directly to a T10k encrypting tape drive. > > -- Gotcha! Many thanks. Fred _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss