Solved Receive a snapshot to an preexisting data-set?

[mefizto]

Greetings all,

I have music on a server data-set storage/music; however, the data-set was created with a recordsize=128K. I would like to back them up to a different server with a data-set with a recordsize=1M.

As such I created a data-set storage/music with the recordsize=1M on the second server, but the zfs-send storage/music@date zfs-recv -dvu storage/music transferred them into storage/music/music.

Is there a way around this?

Kindest regards,

M

 

[rigoletto@]

This is exactly what you told to be done. It should be just storage at the receiving point, to get the result you are expecting.

 

[mefizto]

Hi rigoletto@,

thank you for the reply.

This is exactly what you told to be done. It should be just storage at the receiving point, to get the result you are expecting.

I understand that this is what I did by using the -d option.

Let me rephrase the question (hopefully) more artfully. My structure looks like this:

NAME            MOUNTPOINT
storage            /storage
storage/mail    /storage/mail

So, how do I set the properties on the future data-set storage/music different from the original data-set storage/music?

Kindest regards,

M

 

[rigoletto@]

You can set the properties per filesystem. I don't know if recordsize is allowed to be changed on-the-fly (likely yes) but the changes would just have effect on new writtings.

zfs set recordsize=1M storage/music

[EDIT]
Yes, you can change on-the-fly. I just tested in here.

 

[Erichans]

Generally, in addition to the specific recordsize property, zfs-receive(8):

-o property=value
       Sets the specified property as if the command zfs set
       property=value was invoked immediately before the receive.
       [...]
       Any editable property can be set at receive time. [...]

As music is (in all likelyhood to be) considered read only, you could also experiment with the ZFS compression property settings. This could be advantageous when the choosen music compression format at encoding time is less effective then what can be achieved with ZFS compression techniques; it depends on the choosen music encoding settings.

When using property settings in a send-receive action, consider the use of the -x option of zfs-receive(8) to control property settings only for the issued send-receive action:

-x property
       Ensures that the effective value of the specified property after
       the receive is unaffected by the value of that property in the send
       stream (if any), as if the property had been excluded from the send
       stream. [...]

 

[mefizto]

Hi rigoletto@,

thank you again for your reply.

You can set the properties per filesystem. . . . but the changes would just have effect on new writtings.

I know, but that is exactly the problem, the property settings will affect only the newly created data. Furthermore, some property must be set upon creation and is immutable afterwards, e.g., encryption, cf. zfs-load-key(8).

But, I believe that I figured it out based on Erichans' reply, see below.

Hi Erichans,

thank you very much for posting the -o property=value and the -x property back-to-back because when I was reviewing the zfs-receive(8) last night, the interplay between them did not make sense to me. In fact, I used the -x encryption when experimenting with transferring an unencrypted stream to an encrypted data-set.

So, my current understanding is that I do not need to create the data-set before the transfer, but I set all the desired properties with the -o property=value upon receiving the stream.

Back to experimenting.

Kindest regards,

M

 

[mefizto]

Greetings all,

well, it worked - almost. From the report there was an attempt, but:

cannot receive recordsize property on storage: permission denied

As I understand, the problem is that due to my rampant paranoia; I am not executing the transfer as a root, but rather I created a specific user on both the source and the sink, and gave the user only the minimum permissions to perform the transfer.

Reading zfs-allow(8), I could add the required permissions to the user at the sink, but different datasets may require different permissions, so it would get rather messy.

So, I wonder whether a two-step tango would not be a better solution. Create a data-set with the required properties on the pool, transfer the snapshot into another dataset onto the pool, rsync the two data-sets and delete the another data-set.

Any other ideas would be appreciated.

Kindest regards,

M