Samba LXC redundancy

[Mrt12]

Good day,
I have the following scenario.

I set up a file storage server with SAMBA and LXC. It works absolutely fine. I have now around 8 TB of data on my storage.
I use a ZFS dataset for the storage, and a bind mount to the LXC. This works phantastically well.

However I now have a new problem. I would like to replicate the SMB server. I know there is the possibility of clustered SAMBA, but it seems to me a bit complicated.
But I have already set up a ZFS replication task that runs every 10 min and uses zfs send / zfs receive to synchronize the entire 8 TB dataset to a second server I have.
I wonder, can I also set up a replication task for the LXC container that copies the LXC to the other server? will that work with the bind mount? I see that Proxmox does not let me create a replication task for this particular LXC, because it uses a bind mount. Can I fix this somehow?

But then I still have the problem that, in case of a failure of the first SAMBA server, the replicated one would come into play and the files would be modified on the 2nd dataset. So I would need some sort of bidirectional replication. But I am not sure if such a thing is possible.
How should I address the problem of a redundant file server? any good ideas?

 

[Mrt12]

Okay, I experimented a bit with replication. It somehow works, but not quite:

I created a test LXC on my node "pve0" and set up replication to node "pve1". That works fine, as the LXC's attached subvols are successfuly sent over to the other node.

However, when I manually then move the LXC to the other node, according to the wiki

https://pve.proxmox.com/wiki/Storage_Replication

the replication direction should be reversed automatically. It *somehow* works, but not quite, as suddenly, the replication job gets stuck:

2024-12-04 14:09:00 117-0: start replication job
2024-12-04 14:09:00 117-0: guest => CT 117, running => 0
2024-12-04 14:09:00 117-0: volumes => pve:subvol-117-disk-0,pve:subvol-117-disk-1
2024-12-04 14:09:02 117-0: create snapshot '__replicate_117-0_1733317740__' on pve:subvol-117-disk-0
2024-12-04 14:09:02 117-0: create snapshot '__replicate_117-0_1733317740__' on pve:subvol-117-disk-1
2024-12-04 14:09:02 117-0: using secure transmission, rate limit: none
2024-12-04 14:09:02 117-0: incremental sync 'pve:subvol-117-disk-0' (__replicate_117-0_1733317680__ => __replicate_117-0_1733317740__)
2024-12-04 14:09:02 117-0: send from @__replicate_117-0_1733317680__ to tank/pve/subvol-117-disk-0@__replicate_117-0_1733317740__ estimated size is 624B
2024-12-04 14:09:02 117-0: total estimated size is 624B
2024-12-04 14:09:02 117-0: TIME        SENT   SNAPSHOT tank/pve/subvol-117-disk-0@__replicate_117-0_1733317740__
2024-12-04 14:09:03 117-0: cannot receive incremental stream: incremental send stream requires -L (--large-block), to match previous receive.
2024-12-04 14:09:03 117-0: command 'zfs recv -F -- tank/pve/subvol-117-disk-0' failed: exit code 1
2024-12-04 14:09:03 117-0: delete previous replication snapshot '__replicate_117-0_1733317740__' on pve:subvol-117-disk-0
2024-12-04 14:09:03 117-0: delete previous replication snapshot '__replicate_117-0_1733317740__' on pve:subvol-117-disk-1
2024-12-04 14:09:04 117-0: end replication job with error: command 'set -o pipefail && pvesm export pve:subvol-117-disk-0 zfs - -with-snapshots 1 -snapshot __replicate_117-0_1733317740__ -base __replicate_117-0_1733317680__ | /usr/bin/ssh -e none -o 'BatchMode=yes' -o 'HostKeyAlias=pve1' -o 'UserKnownHostsFile=/etc/pve/nodes/pve1/ssh_known_hosts' -o 'GlobalKnownHostsFile=none' root@130.92.113.6 -- pvesm import pve:subvol-117-disk-0 zfs - -with-snapshots 1 -snapshot __replicate_117-0_1733317740__ -allow-rename 0 -base __replicate_117-0_1733317680__' failed: exit code 255

I have seen that others experienced a similar issue with the -L flag, but I do not understand the solution to this problem and why it even occurs. Is this a bug, or am I doing something wrong? do I understand it correctly that my replication fails because I have set the record size of my ZFS datasets to 1M? I actually did this deliberately, as I did lots of experimentation and tests and found out that performance and compression ratio are better with 1M recordsize than with 128K, at least in my use case and the kind of data that I have.