How to mount replicated dataset without breaking further replication?

[Malvineous]

I've looked through the documentation but I can't find anything that mentions how to mount or otherwise access the replicated dataset without breaking the replication process.

Once before I tried mounting the filesystem but I recall this broke the replication process, because it couldn't update the dataset once it had been modified due to the mount.

Are there instructions anywhere (ideally at https://zrepl.github.io) that explains the correct way to access a replicated dataset/snapshot in such a way that the data continues to be replicated without any problems?

[InsanePrawn]

AFAIK there's no good way to have it permanently mounted.

For singular recovery purposes one can use the readonly flag and/or roll the dataset back after unmounting.
zfs clone also exists.

"Why can't is just have it permanently mounted in readonly mode?" - IIRC the problem here is that mounting children inside the dataset will either create a directory (modification of the dataset!) for the mountpoint or fail to do that and thus fail mounting - neither are what you want, probably.
This will of course not happen with datasets that already have that folder, but I think that's a huge sharp edge and there's probably more around.
Feel free to investigate this, the findings might be interesting for the zrepl docs.

[rkelleyrtp]

Started working with zrepl last night and found a way to keep the snapshot permanently mounted and visible on the backup server. This works great on Debian 12 with ZFS 2.1.11 and zrepl 0.61.

The trick:

• Ensure the dataset on the target system is set to readonly mode (eg: zfs set readonly=yes <dataset>)
• Ensure the dataset on the target system has a mountpoint (eg: zfs set mountpoint=<mountpoint> <dataset>)

Once those options are set, simply mount the dataset on the target, and you will see the data. Here are the commands I used when the remote dataset is named mypool/zrepl-01/mypool/data-01:

zfs set readonly=yes mypool/zrepl-01
zfs set readonly=yes mypool/zrepl-01/mypool
zfs set readonly=yes mypool/zrepl-01/mypool/data-01
zfs set mountpoint=/backup_data/data-01 mypool/zrepl-01/mypool/data-01
zfs mount mypool/zrepl-01/mypool/data-01

Adding the readonly=yes option to the parent ensures any other zrepl volume will get the same readonly setting. The best part: the mount point always has the data from the most recent snapshot. If you need data from another snapshot, simply go to /backup/data-01/.zfs/snapshot/<snapshot_dir_name>).

Finally, if you need a read-write copy of the data, simply do zfs clone mypool/zrepl-01/mypool/data-01@<snapshot-name> then mount the clone to a directory.

Hope this helps.

[rkelleyrtp]

@kpfleming Interesting, I was able to send additional datasets even when root_fs was set to readonly=true on the recv (sink) side. For clarity, I have two test machines (zrepl-01 and zrepl-02). Each server had an initial pool called mypool.

The zrepl.yml file on the sender side:

global:
  logging:
    - type: syslog
      format: human
      level: warn

jobs:
- name: zrepl-01__data-01
  type: push
  connect:
    type: tcp
    address: "192.168.101.126:8888"
  filesystems: {
    "mypool<": true,
  }
  snapshotting:
    type: periodic
    prefix: zrepl_
    interval: 1m
  pruning:
    keep_sender:
    - type: not_replicated
    - type: last_n
      count: 3
    keep_receiver:
    - type: last_n
      count: 3

The zrepl.yml file on the recv (sink) side:

global:
  logging:
    - type: syslog
      format: human
      level: warn

jobs:
- name: zrepl-01_backup_dataset
  type: sink
  serve:
    type: tcp
    listen: ":8888"
    clients: {
       "192.168.101.125 : "zrepl-01"
    }
  root_fs: "mypool"

The recv side has readonly=on for the mypool (root_fs). I was able to create multiple child datasets on the sender side (eg zfs create mypool/data-01, zfs create mypool/data-02, etc), and all the datasets were transferred to the recv side w/out issue.

I created a bunch of datasets on the sender side, and was able to get all of them on the recv side (even child datasets). Example:

NAME                                 USED  AVAIL     REFER  MOUNTPOINT
mypool                              5.32G  91.1G       96K  /mypool
mypool/zrepl-01                     5.28G  91.1G       96K  none
mypool/zrepl-01/mypool              5.28G  91.1G      112K  none
mypool/zrepl-01/mypool/data-01      1.17G  91.1G     1.17G  /data/01
mypool/zrepl-01/mypool/data-01/test    96K  91.1G       96K  /data/01/ron
mypool/zrepl-01/mypool/data-02       805M  91.1G      805M  /data/02
mypool/zrepl-01/mypool/data-03       603M  91.1G      603M  /data/03
mypool/zrepl-01/mypool/data-04       801M  91.1G      801M  /data/04
mypool/zrepl-01/mypool/data-05       986M  91.1G      986M  /data/05
mypool/zrepl-01/mypool/data-06      1004M  91.1G     1004M  /data/06
mypool/zrepl-01/mypool/data-07        96K  91.1G       96K  /data/07
mypool/zrepl-01/mypool/data-08        96K  91.1G       96K  /data/08

How does this compare with your config files?

[kpfleming]

Ahh, I see the difference. You are allowing the mountpoints from the sender to flow through during receive, which I don't because it would cause conflicts (all of my senders have rpool filesystems with mountpoints of /). I have zrepl configured to forcibly inherit the mountpoint property when it creates new datasets, and as a result on my system mypool/zrepl-01 would be mounted at something like /backups/zrepl-01 and read-only, so creation of mypool/zrepl-01/mypool would experience an error creating the mountpoint for it.

[rkelleyrtp]

To be clear on my test systems, the mountpoint variables are set on the receiver side (outside of zrepl) once the initial zrepl sync is done. In fact, the mountpoints listed above are not the "real" mountpoint directory on the source system.

[kpfleming]

Thanks for the clarification. I don't do that :-)

[kpfleming]

In any case, I think this is all fine. The guide should not recommend setting readonly=yes at the root_fs level, but should instead recommend using recv -> properties -> override -> readonly: yes so that zrepl itself will set that property on the non-placeholder datasets it creates. For simplicitly canmount and snapdir can also be set there, although they could also be set at the root_fs level and inherited using recv -> properties -> inherit.