mirror of
https://github.com/skoelle/moonweb-site.git
synced 2026-09-17 17:00:25 +00:00
initial commit
This commit is contained in:
@@ -0,0 +1,41 @@
|
||||
---
|
||||
title: "Backup Strategy"
|
||||
section: "infra"
|
||||
parent: "/"
|
||||
description: "Layered 3-2-1 backup strategy covering NAS snapshots, offsite copies, and cloud storage."
|
||||
layout: base.njk
|
||||
---
|
||||
<h1>Backup Strategy</h1>
|
||||
<div class="detail-content">
|
||||
|
||||
<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
|
||||
copy on a different machine.</p>
|
||||
|
||||
<h2>NAS user content — four layers</h2>
|
||||
<table>
|
||||
<tr><th>Layer</th><th>Target</th><th>Frequency</th><th>Purpose</th></tr>
|
||||
<tr><td>Snapshots</td><td>Synology, built-in</td><td>Hourly</td><td>Fast recovery of accidentally deleted files</td></tr>
|
||||
<tr><td>Local backup</td><td>USB drive attached to the NAS</td><td>Daily</td><td>Local versioned backup, independent of the NAS disks</td></tr>
|
||||
<tr><td>Offsite sync</td><td>External drive on a Raspberry Pi in a different room</td><td>Weekly</td><td>Geographically separated copy within the flat</td></tr>
|
||||
<tr><td>Cloud archive</td><td>Cloud storage</td><td>Continuous</td><td>Off-site copy for worst-case scenarios (fire, theft)</td></tr>
|
||||
</table>
|
||||
|
||||
<h2>Proxmox VM/LXC backups — three copies, two machines</h2>
|
||||
<table>
|
||||
<tr><th>Copy</th><th>Target</th><th>Frequency</th></tr>
|
||||
<tr><td>1 — original</td><td>Proxmox host itself</td><td>Daily</td></tr>
|
||||
<tr><td>2 — primary offsite</td><td>Synology NAS (different machine)</td><td>Daily, right after copy 1</td></tr>
|
||||
<tr><td>3 — secondary offsite</td><td>Raspberry Pi backup target, different room</td><td>Daily (skipped one day/week to avoid network contention with the weekly NAS sync)</td></tr>
|
||||
</table>
|
||||
|
||||
<h2>Design principles</h2>
|
||||
<ul>
|
||||
<li>Backups always cross at least one machine boundary — nothing is considered "backed up" if it only lives on the source machine's local disk.</li>
|
||||
<li>Weekly and daily jobs are scheduled to avoid saturating the internal power-line network link used by the offsite backup target.</li>
|
||||
<li>All scheduled jobs ping a dead-man's-switch monitoring service; a missed backup triggers an alert.</li>
|
||||
<li>Power to the offsite drive is only switched on for the duration of its weekly sync, to save power and extend disk life.</li>
|
||||
</ul>
|
||||
|
||||
</div>
|
||||
@@ -0,0 +1,36 @@
|
||||
---
|
||||
title: "Xubuntu Dev VM"
|
||||
section: "infra"
|
||||
parent: "/"
|
||||
description: "A disposable, daily-backed-up Xubuntu VM for AI-assisted, remote development via SSH and Chrome Remote Desktop."
|
||||
layout: base.njk
|
||||
---
|
||||
<h1>Xubuntu Dev VM</h1>
|
||||
<div class="detail-content">
|
||||
|
||||
<p>This is a Xubuntu virtual machine on <a href="/proxmox/">Proxmox pve2</a> in the study that serves as my main development environment, replacing the need for a dedicated physical workstation. It's designed to be lightweight, remotely accessible from anywhere, and — most importantly — completely disposable, which is what makes it a safe place to let AI coding agents operate with far more autonomy than I'd otherwise allow.</p>
|
||||
|
||||
<h2>Why a disposable VM is the biggest advantage</h2>
|
||||
<ul>
|
||||
<li><strong>Daily backups as a safety net</strong> — the VM is backed up once a day through Proxmox. If an AI agent breaks the system, misconfigures something critical, or deletes the wrong files, I simply restore yesterday's snapshot rather than manually debugging the damage.</li>
|
||||
<li><strong>No irreplaceable local data</strong> — nothing important lives only on this VM. All actual project code lives in Git repositories, so after a restore I just <code>git pull</code> everything back and I'm exactly where I left off, minus whatever the agent broke.</li>
|
||||
<li><strong>Higher trust, more autonomy for AI agents</strong> — because the worst-case outcome is "restore a snapshot and re-pull," I can give coding agents like OpenCode much broader permissions on this machine than I would on a system holding unique, unbacked-up state. The blast radius of a mistake is capped at "lose a few hours of uncommitted work," never at "lose data."</li>
|
||||
<li><strong>Cheap to rebuild from scratch</strong> — if the VM ever gets into a truly bad state, standing up a fresh Xubuntu VM and re-cloning repos is a short, well-understood process rather than an emergency.</li>
|
||||
</ul>
|
||||
|
||||
<h2>Remote workflow via SSH</h2>
|
||||
<ul>
|
||||
<li><strong><a href="https://herdr.dev/">Herdr</a></strong> — manages my development workspaces over SSH, letting me organize and switch between multiple project contexts on the VM without manually juggling terminal sessions.</li>
|
||||
<li><strong><a href="https://opencode.ai/de">OpenCode</a></strong> — the AI coding agent I run inside these workspaces; it's the main reason the VM's disposability matters, since it can act with elevated freedom knowing any damage is trivially reversible.</li>
|
||||
<li><strong><a href="https://github.com/jesseduffield/lazygit">lazygit</a></strong> — terminal UI for Git, used for fast commit/branch/diff workflows directly inside the SSH session without leaving the terminal.</li>
|
||||
</ul>
|
||||
|
||||
<h2>Graphical fallback via Chrome Remote Desktop</h2>
|
||||
<ul>
|
||||
<li><strong>Full desktop access</strong> — when a GUI IDE is preferable to terminal-based editing, Chrome Remote Desktop connects straight into the Xubuntu desktop from any device.</li>
|
||||
<li><strong>WebStorm</strong> — used for TypeScript projects that benefit from a full IDE (refactoring tools, debugging, integrated test runners).</li>
|
||||
<li><strong>PyCharm</strong> — used the same way for Python projects.</li>
|
||||
</ul>
|
||||
|
||||
<p class="redacted-note">This setup deliberately treats the dev VM as ephemeral infrastructure, not a pet — the philosophy is: keep state in Git, keep the VM replaceable, and let daily backups absorb the risk of giving an AI agent real write access to the system.</p>
|
||||
</div>
|
||||
@@ -0,0 +1,68 @@
|
||||
---
|
||||
title: "Docker Container Strategy"
|
||||
section: "infra"
|
||||
parent: "/"
|
||||
description: "How self-hosted services are organized across three Docker hosts on Proxmox and Synology, using Docker Compose as the single source of truth."
|
||||
layout: base.njk
|
||||
---
|
||||
<h1>Docker Container Strategy</h1>
|
||||
<div class="detail-content">
|
||||
|
||||
<p>My homelab runs almost entirely on Docker, spread across three dedicated Debian VMs instead of installing containers directly on bare metal or on the NAS operating system itself. Each VM is a clean, disposable Docker host that can be snapshotted and backed up as a whole through Proxmox, and every service is defined declaratively as a Docker Compose file living under <code>/docker-data/compose/<service>/</code>. This keeps the setup portable, reproducible, and easy to document — if a host dies, restoring a VM snapshot brings every container definition back with it.</p>
|
||||
|
||||
<h2>The three Docker hosts</h2>
|
||||
<ul>
|
||||
<li><strong>docker-host-pve</strong> — Debian VM on the main Proxmox server (PVE). This is the primary target for almost all container deployments, including my own images pulled from GHCR. Fully covered by Proxmox VM backups, so the whole host can be restored in one shot.</li>
|
||||
<li><strong>docker-host-nas</strong> — Debian VM running directly on the Synology (via Virtual Machine Manager). Identical setup and folder structure to the PVE host, but used specifically for containers that need direct access to NAS storage volumes, such as media-processing tools that read and write large file libraries.</li>
|
||||
<li><strong>docker-host-pve2</strong> — Debian VM on the secondary Proxmox server (pve2), which lives in the study and is treated as a pure test/dev environment. New containers and compose setups get trialed here before being promoted to docker-host-pve.</li>
|
||||
</ul>
|
||||
|
||||
<h2>Standardized layout</h2>
|
||||
<ul>
|
||||
<li><strong>/docker-data/compose/</strong> — one subfolder per service, each containing its own <code>docker-compose.yml</code> (and <code>.env</code> where needed).</li>
|
||||
<li><strong>/docker-data/volumes/</strong> — persistent container data, kept outside the compose folders so it survives redeploys.</li>
|
||||
<li><strong>/docker-data/backups/</strong> — local backup staging before data is pulled into the wider backup chain.</li>
|
||||
<li><strong>Same convention everywhere</strong> — because all three hosts follow this identical structure, moving a service between hosts or rebuilding a host from scratch is just a matter of copying the compose folder and running <code>docker compose up -d</code>.</li>
|
||||
</ul>
|
||||
|
||||
<h2>Own GitHub projects</h2>
|
||||
<ul>
|
||||
<li><strong>icloud-contacts-sync</strong> — syncs contact data between iCloud and other systems.</li>
|
||||
<li><strong>calendar-sync</strong> — keeps calendars synchronized across sources.</li>
|
||||
<li><strong>mvg-departures</strong> — pulls Munich public transport (MVG) departure data for local dashboards.</li>
|
||||
<li><strong>wetter-api</strong> — a small weather API/worker pair, built from a custom GHCR image and updated automatically via Watchtower.</li>
|
||||
</ul>
|
||||
|
||||
<h2>Infrastructure containers</h2>
|
||||
<ul>
|
||||
<li><strong>mosquitto-mqtt</strong> — central MQTT broker for smart-home and sensor messaging.</li>
|
||||
<li><strong>grafana, prometheus, influxdb</strong> — the monitoring and metrics stack for dashboards and time-series data.</li>
|
||||
<li><strong>healthchecks, uptime-kuma, cadvisor</strong> — service and container health/uptime monitoring.</li>
|
||||
<li><strong>dyndns-updater</strong> — keeps DNS pointed at the home connection; my own project, see <a href="https://github.com/skoelle/dyndns-updater">skoelle/dyndns-updater</a> on GitHub.</li>
|
||||
<li><strong>watchtower</strong> — automatically checks for and applies container image updates on a daily schedule.</li>
|
||||
<li><strong>authelia, nginx-proxy-manager</strong> — authentication layer and reverse proxy for exposing internal services safely.</li>
|
||||
<li><strong>postfix</strong> — internal mail relay used by other containers (e.g. Watchtower notifications) to send email.</li>
|
||||
<li><strong>portainer</strong> — web UI for managing containers across hosts.</li>
|
||||
<li><strong>exporters</strong> — Prometheus exporters for Fritz!Box, Zyxel switches, Nginx, and SNMP devices, feeding the Grafana/Prometheus stack.</li>
|
||||
</ul>
|
||||
|
||||
<h2>Smart home containers</h2>
|
||||
<ul>
|
||||
<li><strong>Home Assistant</strong> — only used for homematicIP integration to mqtt.</li>
|
||||
</ul>
|
||||
|
||||
<h2>Application containers</h2>
|
||||
<ul>
|
||||
<li><strong>SearXNG</strong> — self-hosted, privacy-respecting metasearch engine.</li>
|
||||
<li><strong>Open WebUI</strong> — chat interface for locally hosted LLMs.</li>
|
||||
<li><strong>Stirling PDF</strong> — self-hosted PDF toolkit for merging, converting and editing documents.</li>
|
||||
<li><strong>ArchiveBox</strong> — personal web archiving of bookmarked pages.</li>
|
||||
<li><strong>TubeSync / TubeArchivist [NAS]</strong> — download and archive YouTube content directly onto NAS storage; these run on docker-host-nas specifically because they need direct volume access to the Synology's disks.</li>
|
||||
</ul>
|
||||
|
||||
<h2>Development tools</h2>
|
||||
<ul>
|
||||
<li><strong>Gitea</strong> — self-hosted Git server acting as a mirror of my GitHub repositories, giving me a local fallback and faster internal access.</li>
|
||||
</ul>
|
||||
|
||||
</div>
|
||||
@@ -0,0 +1,19 @@
|
||||
const path = require("path");
|
||||
|
||||
module.exports = function (eleventyConfig) {
|
||||
eleventyConfig.addPassthroughCopy({ "shared/theme-infra.css": "theme.css" });
|
||||
eleventyConfig.addPassthroughCopy({ "shared/base.css": "shared-base.css" });
|
||||
eleventyConfig.addPassthroughCopy({ "shared/favicon/infra.svg": "favicon.svg" });
|
||||
|
||||
return {
|
||||
dir: {
|
||||
input: "infra",
|
||||
includes: "../shared/_includes",
|
||||
output: "dist/infra"
|
||||
},
|
||||
serverOptions: {
|
||||
host: "0.0.0.0",
|
||||
port: 8082
|
||||
}
|
||||
};
|
||||
};
|
||||
@@ -0,0 +1,33 @@
|
||||
---
|
||||
title: "Infra"
|
||||
section: "infra"
|
||||
description: "Homelab infrastructure overview: Proxmox hosts, Synology NAS, Docker VMs and Setup-Guides."
|
||||
layout: base.njk
|
||||
sections:
|
||||
- heading: "Plattform"
|
||||
cards:
|
||||
- title: "🖥️ Proxmox host (PVE)"
|
||||
summary: "Hosting environment for running production VMs and LXC containers for the homelab."
|
||||
href: "/proxmox/"
|
||||
- title: "💾 Synology DS918+"
|
||||
summary: "NAS running Docker services and acting as the primary backup repository."
|
||||
href: "/synology/"
|
||||
- title: "🐳 Docker VMs (Debian)"
|
||||
summary: "Primary target for new Docker/Compose services, running the monitoring exporters."
|
||||
href: "/docker/"
|
||||
- title: "📦 LxC Container"
|
||||
summary: "Pi-hole, Ubuntu-Worker and MariaDB running on slim LxC Containers."
|
||||
href: "/lxc/"
|
||||
- heading: "Strategies & Setup-Guides"
|
||||
cards:
|
||||
- title: "🔄 Backup strategy"
|
||||
summary: "Layered backup approach covering NAS user content and VM/LXC backups across multiple locations."
|
||||
href: "/backup-strategy/"
|
||||
- title: "📊 Prometheus/Grafana"
|
||||
summary: "Central metrics collection and dashboards for hosts, containers, and hardware."
|
||||
href: "/monitoring/"
|
||||
- title: "💻 Dev environment"
|
||||
summary: "A disposable, daily-backed-up Xubuntu VM for AI-assisted, remote development via SSH and Chrome Remote Desktop."
|
||||
href: "/dev-environment/"
|
||||
---
|
||||
{% include "card-grid.njk" %}
|
||||
@@ -0,0 +1,43 @@
|
||||
---
|
||||
title: "LXC Container Strategy"
|
||||
section: "infra"
|
||||
parent: "/"
|
||||
description: "Overview of the lightweight LXC containers running on the main Proxmox host, and why they are LXC instead of Docker."
|
||||
layout: base.njk
|
||||
---
|
||||
<h1>LXC Container Strategy</h1>
|
||||
<div class="detail-content">
|
||||
|
||||
<p>Alongside the Docker-based setup, I run a small number of Linux Containers (LXC) directly on the main Proxmox host (PVE). An LXC is an OS-level virtualization container — unlike a Docker container, which packages a single application and its dependencies, an LXC behaves like a full lightweight Linux system with its own init process, systemd services and package manager, but without the overhead of a full virtual machine. Proxmox manages LXCs natively as first-class citizens, right next to VMs, with their own snapshotting, backup and resource-limit tooling. I use far fewer LXCs than Docker containers, reserving them for cases where a persistent, OS-like environment or tight integration with Proxmox itself makes more sense than a containerized app.</p>
|
||||
|
||||
<h2>Why LXC instead of Docker here</h2>
|
||||
<ul>
|
||||
<li><strong>Native Proxmox integration</strong> — LXCs show up directly in the Proxmox UI with their own resource graphs, backup jobs and snapshots, without needing a Docker host VM in between.</li>
|
||||
<li><strong>Lower overhead than a VM</strong> — an LXC shares the host kernel, so it starts almost instantly and uses less RAM/CPU than a full Debian VM, while still feeling like a real, persistent Linux machine.</li>
|
||||
<li><strong>Better fit for system-level services</strong> — some services (like a DNS resolver or a database server) benefit from being a stable, always-on OS process with predictable networking, rather than an ephemeral, frequently-redeployed container.</li>
|
||||
<li><strong>Simplicity for infrequently-changed services</strong> — these three services rarely change their configuration, so the extra flexibility of Compose-based redeployment isn't needed; a straightforward apt-installed service is easier to reason about long-term.</li>
|
||||
</ul>
|
||||
|
||||
<h2>Pi-hole</h2>
|
||||
<ul>
|
||||
<li><strong>Purpose</strong> — network-wide DNS sinkhole and ad/tracker blocking for every device on the home network.</li>
|
||||
<li><strong>Why LXC</strong> — DNS resolution needs to be rock-solid and always reachable at a fixed IP; running it as a lean, dedicated LXC avoids depending on the Docker host VM being up, and keeps it isolated from Docker networking quirks that could interfere with DNS.</li>
|
||||
<li><strong>Advantage</strong> — near-zero overhead, boots in seconds after a Proxmox host reboot, and its stability is decoupled from whatever is happening on the Docker hosts.</li>
|
||||
</ul>
|
||||
|
||||
<h2>Ubuntu-Worker</h2>
|
||||
<ul>
|
||||
<li><strong>Purpose</strong> — a general-purpose Ubuntu LXC used as a flexible worker/utility machine for ad-hoc scripts, cron jobs and small maintenance tasks that don't warrant their own container image.</li>
|
||||
<li><strong>Why LXC</strong> — it needs to behave like a normal Linux box (full package manager, cron, shell access) rather than a single-purpose containerized app, which makes an LXC a much better fit than wrapping everything in Docker.</li>
|
||||
<li><strong>Advantage</strong> — quick to spin up, snapshot and roll back via Proxmox, and useful as a lightweight sandbox for testing shell scripts or automation before productionizing them elsewhere.</li>
|
||||
</ul>
|
||||
|
||||
<h2>MariaDB</h2>
|
||||
<ul>
|
||||
<li><strong>Purpose</strong> — central relational database instance, currently used by services such as nginx-proxy-manager, reachable over the network at a fixed internal IP.</li>
|
||||
<li><strong>Why LXC</strong> — a database benefits from direct, persistent disk access and predictable performance without the extra storage-driver indirection of Docker volumes; running it as an unprivileged LXC keeps it isolated while still feeling like a native MariaDB install.</li>
|
||||
<li><strong>Advantage</strong> — simple backup via <code>mysqldump</code>, straightforward remote access configuration (bind-address, dedicated service users per consuming application), and one central database that multiple Docker containers on other hosts can connect to over the network instead of each running their own database container.</li>
|
||||
</ul>
|
||||
|
||||
<p class="redacted-note">All three LXCs run exclusively on the main Proxmox host (PVE), not on pve2 or the Synology — they're intentionally kept centralized since they're few in number and don't need the multi-host redundancy that the Docker setup has. IPs, credentials and specific VMIDs are omitted here; only the reasoning behind the LXC-vs-Docker choice is shown.</p>
|
||||
</div>
|
||||
@@ -0,0 +1,38 @@
|
||||
---
|
||||
title: "Monitoring"
|
||||
section: "infra"
|
||||
parent: "/"
|
||||
description: "Prometheus and Grafana monitoring stack for hosts, containers, and hardware metrics."
|
||||
layout: base.njk
|
||||
---
|
||||
<h1>Monitoring</h1>
|
||||
<div class="detail-content">
|
||||
|
||||
<p>Prometheus and Grafana form the central monitoring stack for the whole
|
||||
homelab, running as Docker containers on the NAS.</p>
|
||||
|
||||
<h2>What's monitored</h2>
|
||||
<ul>
|
||||
<li><strong>Proxmox host metrics</strong> — a PVE exporter reports node-level and per-VM/LXC CPU, memory, and disk metrics into a dedicated Grafana dashboard.</li>
|
||||
<li><strong>Host metrics everywhere</strong> — a node exporter runs on the NAS, the Docker host, and every Raspberry Pi, feeding basic CPU/RAM/disk/network stats.</li>
|
||||
<li><strong>Container metrics</strong> — cAdvisor runs on both the Docker host and the NAS, breaking down resource usage per container.</li>
|
||||
<li><strong>Network hardware via SNMP</strong> — an SNMP exporter polls a network-attached printer for toner level, page count, and status, proving the same pattern works for any SNMP-capable device.</li>
|
||||
</ul>
|
||||
|
||||
<h2>Dashboards</h2>
|
||||
<table>
|
||||
<tr><th>Dashboard</th><th>Focus</th></tr>
|
||||
<tr><td>Proxmox monitoring (extended)</td><td>Node-level and per-guest VM/LXC metrics</td></tr>
|
||||
<tr><td>Docker container monitoring</td><td>Per-container CPU/memory/network/disk</td></tr>
|
||||
<tr><td>Network printer</td><td>Toner level, page count, online/offline status via SNMP</td></tr>
|
||||
</table>
|
||||
|
||||
<h2>Open items</h2>
|
||||
<ul>
|
||||
<li>Alerting rules are not yet configured for most services.</li>
|
||||
<li>The secondary (test) Proxmox host isn't monitored yet — it's usually powered off.</li>
|
||||
<li>Retention policy for Prometheus data hasn't been tuned.</li>
|
||||
<li>Monitoring data itself isn't currently backed up.</li>
|
||||
</ul>
|
||||
|
||||
</div>
|
||||
@@ -0,0 +1,42 @@
|
||||
---
|
||||
title: "Proxmox Virtualization"
|
||||
section: "infra"
|
||||
parent: "/"
|
||||
description: "What Proxmox VE is, the hardware it runs on in my homelab, its key advantages, and a short setup walkthrough."
|
||||
layout: base.njk
|
||||
---
|
||||
<h1>Proxmox Virtualization</h1>
|
||||
<div class="detail-content">
|
||||
|
||||
<p>Proxmox VE (Virtual Environment) is a free, open-source virtualization platform that combines KVM-based full virtual machines with lightweight LXC containers in a single web-managed system. It's built on top of Debian, includes ZFS storage management, backup/restore, clustering and monitoring out of the box, and is the foundation my entire homelab runs on — both the <a href="/docker/">Docker</a> hosts and the standalone <a href="/lxc/">LXC services</a> live as guests on top of it.</p>
|
||||
|
||||
<h2>Hardware</h2>
|
||||
<ul>
|
||||
<li><strong>PVE (main server)</strong> — a Beelink Mini-PC, running as the primary Proxmox host. It has a 500GB SSD for VM and container storage, and connects to the network via the server-room Zyxel switch.</li>
|
||||
<li><strong>pve2 (test server)</strong> — a second Proxmox host, physically located in the study and connected via the OpenWRT-side Zyxel switch. It's dedicated purely to testing and development, running the third <a href="/docker/">Docker host VM (docker-host-pve2)</a> plus experimental setups without risking the production environment.</li>
|
||||
<li><strong>Backups</strong> — nightly VM backups from PVE run at 00:30 to an NFS share on the Synology (<code>nas:/volume1/backup</code>), with retention of the last 3 daily, 3 monthly and 1 yearly backup.</li>
|
||||
</ul>
|
||||
|
||||
<h2>Advantages</h2>
|
||||
<ul>
|
||||
<li><strong>Mixed virtualization</strong> — full KVM virtual machines and lightweight LXC containers run side by side on the same host, so I can pick whichever fits a service best.</li>
|
||||
<li><strong>Web-based management</strong> — the entire cluster, its VMs, containers, storage and backups are managed from one browser UI via Authelia/Nginx, no separate tooling needed.</li>
|
||||
<li><strong>Built-in ZFS support</strong> — snapshots, checksumming and pool management are native, making disk setup and VM protection straightforward.</li>
|
||||
<li><strong>Native backup/restore</strong> — scheduled backups to an external NFS target are configured directly in Proxmox, without third-party backup software.</li>
|
||||
<li><strong>No licensing cost</strong> — the platform is fully usable without a subscription by switching to the no-subscription repository, which matters for a homelab that isn't running on enterprise support contracts.</li>
|
||||
</ul>
|
||||
|
||||
<h2>Open-source edition</h2>
|
||||
<ul>
|
||||
<li><strong>Proxmox VE Community/no-subscription</strong> — the enterprise repositories are disabled and the host is switched to the free "no-subscription" package repository, giving full functionality identical to the paid tiers minus vendor support and the enterprise-only repo.</li>
|
||||
<li><strong>License</strong> — Proxmox VE itself is open source (AGPLv3); the subscription only adds official support and access to the more conservative enterprise update channel.</li>
|
||||
</ul>
|
||||
|
||||
<h2>Setup process</h2>
|
||||
<ul>
|
||||
<li><strong>Bootstrap</strong> — on new Beelink hardware, an initial OS (Windows) needs to be cleared first; entering the BIOS (DEL key) to set the boot order to USB-first allows booting the Proxmox installer.</li>
|
||||
<li><strong>Base install</strong> — Proxmox VE installed directly from ISO, then updated after disabling the enterprise repo and enabling the no-subscription repo.</li>
|
||||
<li><strong>Storage</strong> — an additional SSD is partitioned (GPT via <code>parted</code>) and turned into a ZFS pool through the Disks → ZFS section of the web UI.</li>
|
||||
<li><strong>Networking/backup target</strong> — an NFS share from the Synology is mounted for backup storage, and a nightly backup job is scheduled per VM.</li>
|
||||
<li><strong>Guest creation</strong> — VMs (like the Debian Docker-host VMs) and LXCs (Pi-hole, Ubuntu-Worker, MariaDB) are created through the web UI, with ISO images uploaded to local storage beforehand.</li>
|
||||
</ul>
|
||||
@@ -0,0 +1,35 @@
|
||||
---
|
||||
title: "Synology NAS"
|
||||
section: "infra"
|
||||
parent: "/"
|
||||
description: "Model, storage setup and current role of the Synology NAS in the homelab after the late-2025 cleanup."
|
||||
layout: base.njk
|
||||
---
|
||||
<h1>Synology NAS</h1>
|
||||
<div class="detail-content">
|
||||
|
||||
<p>The NAS at the center of the homelab is a Synology DS918+, a 4-bay desktop NAS originally released in 2018. It runs Synology's DSM operating system and uses SHR (Synology Hybrid RAID) across its four drive bays, mixing different drive capacities while still keeping a full mirror-equivalent level of redundancy. After a focused cleanup pass at the end of 2025, the NAS was stripped down to only the packages and containers that are actually in active use, rather than years of accumulated, half-used software.</p>
|
||||
|
||||
<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>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>
|
||||
|
||||
<h2>What runs on it today</h2>
|
||||
<ul>
|
||||
<li><strong>Docker host VM</strong> — a dedicated Debian VM (docker-host-nas) runs on the NAS's virtualization layer, hosting containers that specifically need direct access to NAS storage volumes.</li>
|
||||
<li><strong>File storage & backup target</strong> — the core role of the NAS remains classic network storage, plus acting as the backup destination for scheduled Proxmox VM backups from the rest of the homelab.</li>
|
||||
<li><strong>Legacy packages removed</strong> — unused DSM packages (like a web/photo/media package, an old drive-sync service and unused indexing) were uninstalled to reduce background load and disk writes.</li>
|
||||
</ul>
|
||||
|
||||
<h2>Main strengths</h2>
|
||||
<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>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>
|
||||
|
||||
</div>
|
||||
Reference in New Issue
Block a user