On 07/26/11 11:56, Fred Liu wrote:
It is up to how big the delta is. It does matter if the data backup can not
be finished within the required backup window when people use zfs send/receive
to do the mass data backup.
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.
BTW adding a sort of off-topic question -- will NDMP protocol in Solaris will do
decompression and decryption? Thanks.
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.
And ZFS send/receive tunneled by ssh becomes the only way to encrypt
the data transmission?
That isn't the only way.
--
Any alternatives, if you don't mind? ;-)
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.
--
Darren J Moffat
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
