On 07/27/11 12:51, Pawel Jakub Dawidek wrote:
On Tue, Jul 26, 2011 at 03:28:10AM -0700, Fred Liu wrote:
The ZFS Send stream is at the DMU layer at this layer the data is
uncompress and decrypted - ie exactly how the application wants it.
Even the data compressed/encrypted by ZFS will be de
On Tue, Jul 26, 2011 at 03:28:10AM -0700, Fred Liu wrote:
>
> >
> > The ZFS Send stream is at the DMU layer at this layer the data is
> > uncompress and decrypted - ie exactly how the application wants it.
> >
>
> Even the data compressed/encrypted by ZFS will be decrypted? If it is true,
> wi
>
> I believe so, also it is more than just the T1C drive you need it
> needs to be in a library and you also need the Oracle Key Management
> system to be able to do the key management for it.
>
Yes. Single T1C is not a big deal. I mean the whole backup system(tape lib
& drive, backup
On 07/27/11 10:24, Fred Liu wrote:
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. T1C is a monster to have if possible ;-).
And doing the job on NDMP no
>
> 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
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
Op 26-07-11 12:56, Fred Liu schreef:
> Any alternatives, if you don't mind? ;-)
vpn's, openssl piped over netcat, a password-protected zip file,... ;)
ssh would be the most practical, probably.
--
No part of this copyright message may be reproduced, read or seen,
dead or alive or by any means,
>
> Yes, which is exactly what I said.
>
> All data as seen by the DMU is decrypted and decompressed, the DMU
> layer
> is what the ZPL layer is built ontop of so it has to be that way.
>
Understand. Thank you. ;-)
>
> There is always some overhead for doing a decryption and decompression,
> t
On 07/26/11 11:28, Fred Liu wrote:
The ZFS Send stream is at the DMU layer at this layer the data is
uncompress and decrypted - ie exactly how the application wants it.
Even the data compressed/encrypted by ZFS will be decrypted?
Yes, which is exactly what I said.
All data as seen by the DM
>
> The ZFS Send stream is at the DMU layer at this layer the data is
> uncompress and decrypted - ie exactly how the application wants it.
>
Even the data compressed/encrypted by ZFS will be decrypted? If it is true,
will it be any CPU overhead?
And ZFS send/receive tunneled by ssh becomes th
On 07/26/11 10:14, Andrew Gabriel wrote:
Does anyone know if it's OK to do zfs send/receive between zpools with
different ashift values?
The ZFS Send stream is at the DMU layer at this layer the data is
uncompress and decrypted - ie exactly how the application wants it.
The ashift is a vdev
Does anyone know if it's OK to do zfs send/receive between zpools with
different ashift values?
--
Andrew Gabriel
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
12 matches
Mail list logo
