Where are properties of a ZFS filesystem stored (e.g. non-default mountpoints, quota, reservation, compression, exported shares etc.)? Do backup/restore mechanisms (zfs send/receive, Networker/NetBackup/TSM, *tar etc.) handle (save/restore) them automagically or are there additional procedures needed? Thanks, Franz
An earlier response from Matt Ahrens, to a similar question: > ''zfs backup/restore'' (now ''zfs send/receive'') currently only sends the > filesystem''s contents, and not its settings. This is useful if, for > example, you want to use different settings on the remote side (eg. turn > on compression). However, we''re aware that preserving the settings > would be really useful too, and we''ll be working on that for a future > release. Franz Haberhauer wrote:> Where are properties of a ZFS filesystem stored (e.g. non-default > mountpoints, quota, reservation, compression, exported shares etc.)? > Do backup/restore mechanisms (zfs send/receive, Networker/NetBackup/TSM, > *tar etc.) > handle (save/restore) them automagically or are there additional > procedures needed? > > Thanks, > Franz-- -------------------------------------------------------------------------- Jeff VICTOR Sun Microsystems jeff.victor @ sun.com OS Ambassador Sr. Technical Specialist Solaris 10 Zones FAQ: http://www.opensolaris.org/os/community/zones/faq --------------------------------------------------------------------------
Jeff Victor wrote:> An earlier response from Matt Ahrens, to a similar question: > > > ''zfs backup/restore'' (now ''zfs send/receive'') currently only sends the > > filesystem''s contents, and not its settings. This is useful if, for > > example, you want to use different settings on the remote side (eg. > turn > > on compression). However, we''re aware that preserving the settings > > would be really useful too, and we''ll be working on that for a future > > release. >well, then it''s probably a good idea to save any changes from the defaults somewhere as they are done or save the output of a "zfs get" along with backups. - Franz> > > Franz Haberhauer wrote: > >> Where are properties of a ZFS filesystem stored (e.g. non-default >> mountpoints, quota, reservation, compression, exported shares etc.)? >> Do backup/restore mechanisms (zfs send/receive, >> Networker/NetBackup/TSM, *tar etc.) >> handle (save/restore) them automagically or are there additional >> procedures needed? >> >> Thanks, >> Franz >
Yes, a trivial wrapper could: 1. Store all property values in a file in the fs 2. zfs send... 3. zfs receive... 4. Set all the properties stored in that file Franz Haberhauer wrote:> Jeff Victor wrote: > >> An earlier response from Matt Ahrens, to a similar question: >> >> > ''zfs backup/restore'' (now ''zfs send/receive'') currently only sends the >> > filesystem''s contents, and not its settings. This is useful if, for >> > example, you want to use different settings on the remote side (eg. >> turn >> > on compression). However, we''re aware that preserving the settings >> > would be really useful too, and we''ll be working on that for a future >> > release. >> > well, then it''s probably a good idea to save any changes from the > defaults somewhere > as they are done or save the output of a "zfs get" along with backups. > > - Franz > >> >> >> Franz Haberhauer wrote: >> >>> Where are properties of a ZFS filesystem stored (e.g. non-default >>> mountpoints, quota, reservation, compression, exported shares etc.)? >>> Do backup/restore mechanisms (zfs send/receive, >>> Networker/NetBackup/TSM, *tar etc.) >>> handle (save/restore) them automagically or are there additional >>> procedures needed? >>> >>> Thanks, >>> Franz >> >>-- -------------------------------------------------------------------------- Jeff VICTOR Sun Microsystems jeff.victor @ sun.com OS Ambassador Sr. Technical Specialist Solaris 10 Zones FAQ: http://www.opensolaris.org/os/community/zones/faq --------------------------------------------------------------------------
Jeff Victor wrote:> Yes, a trivial wrapper could: > 1. Store all property values in a file in the fs > 2. zfs send... > 3. zfs receive... > 4. Set all the properties stored in that fileIMHO 3. and 4. need to be swapped - otherwise e.g. files will not be compressed when restored. - Franz> > Franz Haberhauer wrote: > >> Jeff Victor wrote: >> >>> An earlier response from Matt Ahrens, to a similar question: >>> >>> > ''zfs backup/restore'' (now ''zfs send/receive'') currently only sends >>> the >>> > filesystem''s contents, and not its settings. This is useful if, for >>> > example, you want to use different settings on the remote side >>> (eg. turn >>> > on compression). However, we''re aware that preserving the settings >>> > would be really useful too, and we''ll be working on that for a future >>> > release. >>> >> well, then it''s probably a good idea to save any changes from the >> defaults somewhere >> as they are done or save the output of a "zfs get" along with backups. >> >> - Franz >> >>> >>> >>> Franz Haberhauer wrote: >>> >>>> Where are properties of a ZFS filesystem stored (e.g. non-default >>>> mountpoints, quota, reservation, compression, exported shares etc.)? >>>> Do backup/restore mechanisms (zfs send/receive, >>>> Networker/NetBackup/TSM, *tar etc.) >>>> handle (save/restore) them automagically or are there additional >>>> procedures needed? >>>> >>>> Thanks, >>>> Franz >>> >>> >>> >
Yep, thanks for digging that up. FYI, this is RFE 6421959 "want zfs
send to preserve properties (''zfs send -p'')".
--matt
On Mon, May 29, 2006 at 02:21:44PM -0400, Jeff Victor
wrote:> An earlier response from Matt Ahrens, to a similar question:
>
> > ''zfs backup/restore'' (now ''zfs
send/receive'') currently only sends the
> > filesystem''s contents, and not its settings. This is useful
if, for
> > example, you want to use different settings on the remote side (eg.
turn
> > on compression). However, we''re aware that preserving the
settings
> > would be really useful too, and we''ll be working on that for
a future
> > release.
>
>
>
> Franz Haberhauer wrote:
> >Where are properties of a ZFS filesystem stored (e.g. non-default
> >mountpoints, quota, reservation, compression, exported shares etc.)?
> >Do backup/restore mechanisms (zfs send/receive,
Networker/NetBackup/TSM,
> >*tar etc.)
> >handle (save/restore) them automagically or are there additional
> >procedures needed?
> >
> >Thanks,
> >Franz
>
> --
> --------------------------------------------------------------------------
> Jeff VICTOR Sun Microsystems jeff.victor @ sun.com
> OS Ambassador Sr. Technical Specialist
> Solaris 10 Zones FAQ: http://www.opensolaris.org/os/community/zones/faq
> --------------------------------------------------------------------------
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Is the idea of ''zfs send -p'' to only send the properities in addition to the content or without content? Actually I would expect sending the poperties as the default for send and an option for receive not to apply the properties - and have an option (-p) for send to send only the properties e.g. when using tar or some other mechanism for the content. Until this becomes available a best practices recommendation is needed how to handle backup/restore including filesystem properties especially with the enterprise backup tools (Networker/NetBackup/TSM,Amanda) given that ZFS will now become available with the upcomming Solaris 10 Update. - Franz Matthew Ahrens wrote:>Yep, thanks for digging that up. FYI, this is RFE 6421959 "want zfs >send to preserve properties (''zfs send -p'')". > >--matt > >On Mon, May 29, 2006 at 02:21:44PM -0400, Jeff Victor wrote: > > >>An earlier response from Matt Ahrens, to a similar question: >> >> >> >>>''zfs backup/restore'' (now ''zfs send/receive'') currently only sends the >>>filesystem''s contents, and not its settings. This is useful if, for >>>example, you want to use different settings on the remote side (eg. turn >>>on compression). However, we''re aware that preserving the settings >>>would be really useful too, and we''ll be working on that for a future >>>release. >>> >>> >> >>Franz Haberhauer wrote: >> >> >>>Where are properties of a ZFS filesystem stored (e.g. non-default >>>mountpoints, quota, reservation, compression, exported shares etc.)? >>>Do backup/restore mechanisms (zfs send/receive, Networker/NetBackup/TSM, >>>*tar etc.) >>>handle (save/restore) them automagically or are there additional >>>procedures needed? >>> >>>Thanks, >>>Franz >>> >>>
On Tue, May 30, 2006 at 04:11:13AM +0200, Franz Haberhauer wrote:> Is the idea of ''zfs send -p'' to only send the properities in addition > to the content or without content? Actually I would expect sending the > poperties as the default for send and an option for receive not to > apply the properties - and have an option (-p) for send to send only > the properties e.g. when using tar or some other mechanism for the > content.I''m not sure, these issues are still under consideration. --matt
Constantin Gonzalez Schmitz
2006-May-30 10:30 UTC
[zfs-discuss] Backup/Restore of ZFS Properties
Hi,>> Yes, a trivial wrapper could: >> 1. Store all property values in a file in the fs >> 2. zfs send... >> 3. zfs receive... >> 4. Set all the properties stored in that file > > IMHO 3. and 4. need to be swapped - otherwise e.g. files will > not be compressed when restored.hmm, I assumed that the ZFS stream format would take the blocks as they are (compressed) and then restore them in a 1:1 fashion (compressed) no matter what the target fs'' compression setting is. Then, the missing compression attribute would only affect new files, while old files are still compressed (just like ZFS doesn''t unpack everything if you just turn off compression). Can anybody clarify? Best regards, Constantin -- Constantin Gonzalez Sun Microsystems GmbH, Germany Platform Technology Group, Client Solutions http://www.sun.de/ Tel.: +49 89/4 60 08-25 91 http://blogs.sun.com/constantin/
On Tue, May 30, 2006 at 12:30:50PM +0200, Constantin Gonzalez Schmitz wrote:> Hi, > > >>Yes, a trivial wrapper could: > >>1. Store all property values in a file in the fs > >>2. zfs send... > >>3. zfs receive... > >>4. Set all the properties stored in that file > > > >IMHO 3. and 4. need to be swapped - otherwise e.g. files will > >not be compressed when restored. > > hmm, I assumed that the ZFS stream format would take the blocks as they are > (compressed) and then restore them in a 1:1 fashion (compressed) no matter > what the target fs'' compression setting is. > > Then, the missing compression attribute would only affect new files, > while old files are still compressed (just like ZFS doesn''t unpack > everything if you just turn off compression).Actually, the ''zfs send'' stream sends the data uncompressed, and when it is received, the compression property is consulted to determine whether to compress it or not. This scheme may not have the best possible performance, but it is flexable. For example, if the other machine has less disk space available, or if it has lots of spare CPU power, then you might want to enable compression there but not on the sent filesystem. Or, if you are simply writing the stream to a file (or tape) for backup purposes, you might want to apply a stronger compression algorithm than the one that we offer, and compressing the already somewhat-compressed data would probably not result in a good compression ratio. Sorry for the belated reply, --matt