OpenMediaVault (OMV)

💡 Quick Navigation

• 🎯 Main Purposes
• ⚙️ Hardware and Storage
• 🧱 Architecture Split
• 🔁 Backup Strategy
• 🐳 Docker Service Layer
• 🏠 Home Lab Overview

---

What is OMV?

OpenMediaVault (OMV) is an open-source NAS/server management system based on Debian.
In this Home Lab, OMV is more than a file server:

• Application runtime layer (Docker host)
• Backup landing zone for TrueNAS

---

🎯 Two Main Purposes of Using OMV

1) Backup target for TrueNAS

• Uses one 14TB HDD as backup disk
• Runs nightly backup of TrueNAS data (including SATA SSD data)
• Goal: keep an independent recovery copy for accidental deletion, service failures, or hardware issues

2) Docker service host

• OMV runs multiple Docker containers
• Service data is mounted from TrueNAS to OMV via NFS
• Separation of concerns: storage (TrueNAS) vs applications (OMV)
• Reduces single points of failure and improves operational flexibility

---

Host Information

• Host: omv
• Management approach: OMV + Docker Compose
• Public-facing notes do not expose internal LAN IP details

---

⚙️ Hardware and Storage Configuration

Item	Configuration	Notes
Boot Drive	1 x 256GB M.2 NVMe SSD	OMV system installation
Backup Data Drive	1 x 14TB HDD	Stores daily backups synced from TrueNAS
Role	Compute + Backup	Docker runtime + backup landing

📝 Note: current boot setup is a single disk (not mirrored). For higher system fault tolerance, boot mirror can be considered in the future.

---

🧱 Architecture Responsibilities (Why Separate TrueNAS + OMV)

Layer	Platform	Primary Responsibility
Storage Layer	TrueNAS	Primary data pool, ZFS fault tolerance, data integrity
App Layer	OMV + Docker	Service deployment, orchestration, reverse proxy entry
Backup Layer	OMV 14TB HDD	Daily backup receiver from TrueNAS

Benefits of the split architecture

• Fault isolation: storage and service failures are less tightly coupled
• Operational flexibility: service upgrades do not directly impact storage architecture
• Faster recovery: data can be restored quickly from OMV backup side

---

🔁 Backup Strategy (OMV as TrueNAS Backup Target)

• Source: TrueNAS Data (including SATA SSD-related data)
• Destination: OMV 14TB HDD
• Frequency: every night (recommended 00:00–03:00 depending on load)
• Method: rsync / snapshot-based (exact task config to be documented)
• Retention: TBD (e.g., 7 daily + 4 weekly + 3 monthly)

Backup design principles

1. Backup data separated from primary data (different host / different disk)
2. Verifiable (periodic restore spot checks)
3. Traceable (keep historical versions, not just overwrite)

---

🐳 Docker Service Layer (OMV)

• OMV runs multiple containerized services (application layer)
• Service data is unified through TrueNAS NFS mounts; OMV mainly acts as compute + orchestration node

Storage practice (current architecture)

• Container data and config are centralized in TrueNAS datasets
• OMV mounts via NFS and provides them to Docker containers
• This keeps storage/compute responsibilities clear and improves migration and maintainability

Service categories (current plan)

• Infrastructure: Nginx Proxy Manager
• Home/IoT: Home Assistant, TeslaMate
• Media: Plex, Calibre
• Productivity: Nextcloud, Bitwarden
• Photos: Immich
• Others: Karakeep

Network conventions (recommended)

• proxy: services exposed behind reverse proxy
• internal: internal service communication

Ops SOP (recommended)

• Before update: backup config + DB
• Update flow: pull → recreate → health check
• Rollback strategy: keep previous image tag + volume snapshot

---

Operations TODO

• Add actual backup schedule (cron/script path)
• Add restore drill records
• Add monitoring/alerts (disk health, backup success rate, container health)