OpenMediaVault (OMV)
๐ก Quick Navigation
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
- Backup data separated from primary data (different host / different disk)
- Verifiable (periodic restore spot checks)
- 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, Authelia
- Home/IoT: Home Assistant, TeslaMate
- Media: Calibre
- Productivity: Nextcloud, Bitwarden
- Notes and publishing: Obsidian Sync
- Others: Karakeep
Note
Network conventions (recommended)
proxy: services exposed behind reverse proxyinternal: 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)