On Thu, Sep 06, 2007 at 06:44:06PM +0100, Darren J Moffat wrote: > Nicolas Williams wrote: > >>Does anyone have a use case for clear text filenames and metadata but > >>filesystem encrypted content ? > > > >Traditional backups. > > If by traditional you mean things like 'tar'. How would you restore ? > Note that the on disk ciphertext has an IV derived from the > transaction group that the data was written in. That info wouldn't be > in the backup so it couldn't be restored.
You'd have to find a way to include the IV in the backup (e.g., in an extended or system attr). > >Personally I think that whole and incremental zfs sends (with ciphertext > >as it appears on disk, or perhaps re-encrypted) are the way to deal with > >backups of encrypted filesystems, and that metadata should be encrypted > >as well. But I'm sure many will disagree. > > I'm thinking about that separately, I first need to work out exactly how > zfs send with property passing is going to work. Sure. > >Using zfs sends exclusively for backups means that restores have to be > >of entire datasets, not just of individual files. But I don't think > >production environments are accustomed to the consequences of using zfs > >sends instead of traditional archives. > > zfs send isn't a viable long term backup due to this statement in zfs(1): > > The format of the stream is evolving. No backwards compati- > bility is guaranteed. You may not be able to receive your > streams on future versions of ZFS. The ZFS or ZFS crypto teams could revise the format so that it is sufficiently extensible as to support backwards compatibility. There's nothing fundamental about zfs send that prevents it, just a 'small' matter of protocol design and implementation. Nico --
