Reduce redundancy: LED Matrix dup, 3-2-1 wording, Synology SHR

infra/backup-strategy/index.njk

@@ -11,7 +11,7 @@ layout: base.njk
 
 <p>The homelab uses a layered backup approach, split into two independent
 tracks: NAS user content, and Proxmox VM/LXC backups. Both follow a
-3-2-1-style rule, multiple copies, multiple media types, at least one
+3-2-1-style rule: multiple copies, multiple media types, and at least one
 copy on a different machine.</p>
 
 <h2>NAS user content, four layers</h2>

infra/index.njk

@@ -42,7 +42,7 @@ sections:
 <section class="about-expanded">
   <h2>The setup at a glance</h2>
   <p>The infrastructure runs on three main machines: a Proxmox VE host (Beelink S12 Pro, 32GB RAM) as the primary compute node, a Synology DS918+ NAS for storage and Docker services, and a Xubuntu VM on Proxmox for development. An OpenWrt router handles multi-WAN failover with WiFi and Powerline backhaul, and four Zyxel GS1200-8HP managed switches distribute the network across the flat.</p>
-  <p>The whole stack is monitored via Prometheus and Grafana, with node exporters on every machine, cAdvisor for container metrics, and SNMP exporters for network hardware. Backups follow a 3-2-1 strategy: local snapshots, NAS copies, offsite sync to a Raspberry Pi in a different room, and cloud archive for worst-case scenarios.</p>
+  <p>The whole stack is monitored via Prometheus and Grafana, with node exporters on every machine, cAdvisor for container metrics, and SNMP exporters for network hardware. Backups follow a layered strategy: local snapshots, NAS copies, offsite sync to a Raspberry Pi in a different room, and cloud archive for worst-case scenarios.</p>
 
   <h2>Why Proxmox</h2>
   <p>Proxmox VE was chosen over alternatives like ESXi or plain Docker for several reasons. The open-source model means no licensing headaches. LXC containers provide near-native performance for lightweight services without the overhead of full VMs. The web UI makes it easy to manage snapshots, backups, and migrations. And the ZFS support on the underlying Debian system gives us reliable snapshots and send/receive for the backup chain.</p>

infra/synology/index.njk

@@ -13,8 +13,8 @@ layout: base.njk
 
 <h2>Storage</h2>
 <ul>
-<li><strong>Bays</strong>, 4 drive slots, populated with a mix of large-capacity HDDs rather than a single uniform set, which SHR was specifically chosen to support.</li>
-<li><strong>RAID type</strong>, SHR (Synology Hybrid RAID), giving single-drive fault tolerance while allowing disks of different sizes to be mixed and later upgraded one at a time without rebuilding the whole array from scratch.</li>
+<li><strong>Bays</strong>, 4 drive slots, populated with a mix of large-capacity HDDs rather than a single uniform set.</li>
+<li><strong>RAID type</strong>, SHR (Synology Hybrid RAID), giving single-drive fault tolerance while allowing drives to be upgraded one at a time without rebuilding the whole array from scratch.</li>
 <li><strong>Snapshots</strong>, Btrfs snapshot replication is used for file versioning instead of the classic recycle bin, taken hourly with a retention schedule of 7 days, 3 weeks, 3 months and 1 year.</li>
 </ul>
 
@@ -29,7 +29,7 @@ layout: base.njk
 <ul>
 <li><strong>Central storage hub</strong>, single source of truth for files and backups that every other host in the network (Proxmox VMs, exporters, workstations) can write to or read from.</li>
 <li><strong>Built-in snapshotting</strong>, Btrfs-based snapshots give point-in-time recovery without the overhead of a separate versioning package.</li>
-<li><strong>Flexible RAID</strong>, SHR allows disks to be swapped and capacity to grow over time without needing matched drive sizes from day one.</li>
+<li><strong>Flexible RAID</strong>, SHR allows capacity to grow over time by swapping in larger drives.</li>
 <li><strong>Lightweight virtualization</strong>, running a single purpose-built Docker VM on the NAS keeps storage-adjacent workloads close to the data, without turning the NAS itself into a general-purpose application server.</li>
 </ul>