From 5a1ad4520aac86c7371c8bee9488396122dfc79c Mon Sep 17 00:00:00 2001 From: Paul Buetow Date: Sat, 24 Jan 2026 23:13:41 +0200 Subject: Update content for html --- ...5-07-14-f3s-kubernetes-with-freebsd-part-6.html | 24 ++++++++++---------- gemfeed/atom.xml | 26 +++++++++++----------- 2 files changed, 25 insertions(+), 25 deletions(-) (limited to 'gemfeed') diff --git a/gemfeed/2025-07-14-f3s-kubernetes-with-freebsd-part-6.html b/gemfeed/2025-07-14-f3s-kubernetes-with-freebsd-part-6.html index fe828914..3df72356 100644 --- a/gemfeed/2025-07-14-f3s-kubernetes-with-freebsd-part-6.html +++ b/gemfeed/2025-07-14-f3s-kubernetes-with-freebsd-part-6.html @@ -345,7 +345,7 @@ zroot/bhyve/rocky keystatus available -

The 1-minute replication window is perfectly acceptable for my personal use cases. This isn't a high-frequency trading system or a real-time database—it's storage for personal projects, development work, and home lab experiments. Losing at most 1 minute of work in a disaster scenario is a reasonable trade-off for the reliability and simplicity of snapshot-based replication. Additionally, in the case of a "1 minute of data loss," I would likely still have the data available on the client side.

@@ -462,13 +462,13 @@ global: grid: 4x7d | 6x30d regex: "^zrepl_.*" - - name: f0_to_f1_fedora + - name: f0_to_f1_freebsd type: push connect: type: tcp address: "192.168.2.131:8888" filesystems: - "zroot/bhyve/fedora": true + "zroot/bhyve/freebsd": true send: encrypted: true snapshotting: @@ -495,9 +495,9 @@ EOF

-The Fedora VM is only used for development purposes, so it doesn't require as frequent replication as the NFS data. It's off-topic to this blog series, but it showcases, hows zrepl's flexibility in handling different datasets with varying replication needs.
+The FreeBSD VM is only used for development purposes, so it doesn't require as frequent replication as the NFS data. It's off-topic to this blog series, but it showcases, hows zrepl's flexibility in handling different datasets with varying replication needs.

Furthermore:

@@ -609,13 +609,13 @@ http://www.gnu.org/software/src-highlite -->
zrepl status

-With this setup, both zdata/enc/nfsdata and zroot/bhyve/fedora on f0 will be automatically replicated to f1 every 1 minute (or 10 minutes in the case of the Fedora VM), with encrypted snapshots preserved on both sides. The pruning policy ensures that we keep the last 10 snapshots while managing disk space efficiently.
+With this setup, both zdata/enc/nfsdata and zroot/bhyve/freebsd on f0 will be automatically replicated to f1 every 1 minute (or 10 minutes in the case of the FreeBSD VM), with encrypted snapshots preserved on both sides. The pruning policy ensures that we keep the last 10 snapshots while managing disk space efficiently.

The replicated data appears on f1 under zdata/sink/ with the source host and dataset hierarchy preserved:


This is by design - zrepl preserves the complete path from the source to ensure there are no conflicts when replicating from multiple sources.

@@ -639,14 +639,14 @@ zrepl is running as pid 2309. # Check that new snapshots are being created and replicated paul@f0:~ % doas zfs list -t snapshot | grep `zrepl` | tail -2 zdata/enc/nfsdata@zrepl_20250701_202530_000 0B - 200K - -zroot/bhyve/fedora@zrepl_20250701_202530_000 0B - 2.97G - +zroot/bhyve/freebsd@zrepl_20250701_202530_000 0B - 2.97G - . . . paul@f1:~ % doas zfs list -t snapshot -r zdata/sink | grep 202530 zdata/sink/f0/zdata/enc/nfsdata@zrepl_20250701_202530_000 0B - 176K - -zdata/sink/f0/zroot/bhyve/fedora@zrepl_20250701_202530_000 0B - 2.97G - +zdata/sink/f0/zroot/bhyve/freebsd@zrepl_20250701_202530_000 0B - 2.97G - . . . @@ -875,12 +875,12 @@ paul@f1:~ % doas zfs list -t snapshot | grep nfsdata # Destroy the entire destination dataset to allow clean replication paul@f1:~ % doas zfs destroy -r zdata/sink/f0/zdata/enc/nfsdata -# For VM replication, do the same for the fedora dataset -paul@f1:~ % doas zfs destroy -r zdata/sink/f0/zroot/bhyve/fedora +# For VM replication, do the same for the freebsd dataset +paul@f1:~ % doas zfs destroy -r zdata/sink/f0/zroot/bhyve/freebsd # Wake up zrepl to start fresh replication paul@f0:~ % doas zrepl signal wakeup f0_to_f1_nfsdata -paul@f0:~ % doas zrepl signal wakeup f0_to_f1_fedora +paul@f0:~ % doas zrepl signal wakeup f0_to_f1_freebsd # Check replication status paul@f0:~ % doas zrepl status --mode raw diff --git a/gemfeed/atom.xml b/gemfeed/atom.xml index b8cf30b2..14c0f6a0 100644 --- a/gemfeed/atom.xml +++ b/gemfeed/atom.xml @@ -1,6 +1,6 @@ - 2026-01-17T00:21:37+02:00 + 2026-01-24T23:12:38+02:00 foo.zone feed To be in the .zone! @@ -6791,7 +6791,7 @@ zroot/bhyve/rocky keystatus available -

The 1-minute replication window is perfectly acceptable for my personal use cases. This isn't a high-frequency trading system or a real-time database—it's storage for personal projects, development work, and home lab experiments. Losing at most 1 minute of work in a disaster scenario is a reasonable trade-off for the reliability and simplicity of snapshot-based replication. Additionally, in the case of a "1 minute of data loss," I would likely still have the data available on the client side.

@@ -6908,13 +6908,13 @@ global: grid: 4x7d | 6x30d regex: "^zrepl_.*" - - name: f0_to_f1_fedora + - name: f0_to_f1_freebsd type: push connect: type: tcp address: "192.168.2.131:8888" filesystems: - "zroot/bhyve/fedora": true + "zroot/bhyve/freebsd": true send: encrypted: true snapshotting: @@ -6941,9 +6941,9 @@ EOF

-The Fedora VM is only used for development purposes, so it doesn't require as frequent replication as the NFS data. It's off-topic to this blog series, but it showcases, hows zrepl's flexibility in handling different datasets with varying replication needs.
+The FreeBSD VM is only used for development purposes, so it doesn't require as frequent replication as the NFS data. It's off-topic to this blog series, but it showcases, hows zrepl's flexibility in handling different datasets with varying replication needs.

Furthermore:

@@ -7055,13 +7055,13 @@ http://www.gnu.org/software/src-highlite -->
zrepl status

-With this setup, both zdata/enc/nfsdata and zroot/bhyve/fedora on f0 will be automatically replicated to f1 every 1 minute (or 10 minutes in the case of the Fedora VM), with encrypted snapshots preserved on both sides. The pruning policy ensures that we keep the last 10 snapshots while managing disk space efficiently.
+With this setup, both zdata/enc/nfsdata and zroot/bhyve/freebsd on f0 will be automatically replicated to f1 every 1 minute (or 10 minutes in the case of the FreeBSD VM), with encrypted snapshots preserved on both sides. The pruning policy ensures that we keep the last 10 snapshots while managing disk space efficiently.

The replicated data appears on f1 under zdata/sink/ with the source host and dataset hierarchy preserved:


This is by design - zrepl preserves the complete path from the source to ensure there are no conflicts when replicating from multiple sources.

@@ -7085,14 +7085,14 @@ zrepl is running as pid 2309. # Check that new snapshots are being created and replicated paul@f0:~ % doas zfs list -t snapshot | grep `zrepl` | tail -2 zdata/enc/nfsdata@zrepl_20250701_202530_000 0B - 200K - -zroot/bhyve/fedora@zrepl_20250701_202530_000 0B - 2.97G - +zroot/bhyve/freebsd@zrepl_20250701_202530_000 0B - 2.97G - . . . paul@f1:~ % doas zfs list -t snapshot -r zdata/sink | grep 202530 zdata/sink/f0/zdata/enc/nfsdata@zrepl_20250701_202530_000 0B - 176K - -zdata/sink/f0/zroot/bhyve/fedora@zrepl_20250701_202530_000 0B - 2.97G - +zdata/sink/f0/zroot/bhyve/freebsd@zrepl_20250701_202530_000 0B - 2.97G - . . . @@ -7321,12 +7321,12 @@ paul@f1:~ % doas zfs list -t snapshot | grep nfsdata # Destroy the entire destination dataset to allow clean replication paul@f1:~ % doas zfs destroy -r zdata/sink/f0/zdata/enc/nfsdata -# For VM replication, do the same for the fedora dataset -paul@f1:~ % doas zfs destroy -r zdata/sink/f0/zroot/bhyve/fedora +# For VM replication, do the same for the freebsd dataset +paul@f1:~ % doas zfs destroy -r zdata/sink/f0/zroot/bhyve/freebsd # Wake up zrepl to start fresh replication paul@f0:~ % doas zrepl signal wakeup f0_to_f1_nfsdata -paul@f0:~ % doas zrepl signal wakeup f0_to_f1_fedora +paul@f0:~ % doas zrepl signal wakeup f0_to_f1_freebsd # Check replication status paul@f0:~ % doas zrepl status --mode raw -- cgit v1.2.3