# Storage Architecture

## Goals
- rebuild storage on a stable Proxmox node
- use the incoming 8 SAS disks efficiently and safely
- support file sharing over NFS and Samba
- support Nextcloud as a high-priority service
- avoid unnecessary fragility from raw-disk passthrough appliance setups unless there is a strong reason

## Proposed storage host role
One Proxmox node will be the primary storage/workload node.

Planned roles:
- ZFS storage host
- file shares
- media services
- game services
- Nextcloud data backend

## Proposed ZFS layout
### Pool design
Use **one ZFS pool made from 4 mirrored vdevs**:
- vdev 1: disk1 + disk2
- vdev 2: disk3 + disk4
- vdev 3: disk5 + disk6
- vdev 4: disk7 + disk8

This is commonly described as:
- **8 disks total**
- **4 mirror pairs**
- all mirrors striped together in one pool

### Why this layout
Compared with RAIDZ-based layouts, mirror pairs are attractive here because they are usually better for mixed homelab workloads:
- better random I/O
- better VM/container performance
- faster/simpler resilver behavior
- easier future expansion by adding another mirrored pair
- a strong fit for shares + apps + media + VM-related workloads

### Capacity model
Usable raw capacity is roughly equal to the size of 4 of the drives.

Example:
- 8 × 12 TB drives
- usable raw pool capacity is roughly `4 × 12 TB = 48 TB` before filesystem overhead and free-space planning

### Failure model
The pool can survive:
- loss of one disk from a given mirror
- multiple disk failures, as long as no mirror loses both disks

The pool fails if:
- both disks in the same mirror fail

So this layout has good practical resilience, but not unlimited protection.

## Host vs guest ownership of storage
There are 3 main ways to run this.

### Option A — Proxmox host owns ZFS and also serves NFS/Samba
#### Pros
- simplest path
- best direct performance
- no passthrough complexity
- Proxmox has direct visibility into ZFS health and datasets

#### Cons
- file-sharing services live directly on the hypervisor
- less separation of duties
- makes the Proxmox host more "special"

### Option B — Proxmox host owns ZFS, file-sharing runs in a dedicated guest
#### Structure
- Proxmox host directly manages disks and the ZFS pool
- datasets are mounted or bind-mounted into a dedicated Debian LXC or VM
- Samba and/or NFS run in that guest

#### Pros
- best balance of performance and separation
- host keeps direct ZFS control
- file-sharing stack is isolated from the hypervisor
- easier to rebuild the guest without rebuilding the pool
- avoids raw-disk passthrough dependency

#### Cons
- slightly more setup complexity
- permissions/mount design must be thought through
- NFS in containers needs deliberate planning

### Option C — pass disks/HBA to OMV or TrueNAS VM
#### Pros
- storage appliance style management
- nice UI if using such a platform
- storage and sharing packaged together

#### Cons
- more moving parts
- passthrough becomes critical infrastructure
- Proxmox host loses direct ZFS control/visibility
- recovery/migration can be more awkward
- if the guest is unhealthy, the full storage layer is impacted

## Recommended approach
### Primary recommendation
Use **Option B**:
- Proxmox host owns the disks and ZFS pool
- file-sharing services run in a dedicated guest
- Nextcloud runs in its own separate guest

This gives the cleanest compromise between:
- reliability
- performance
- maintainability
- isolation

## Recommended service placement
### On the Proxmox host
- ZFS pool management
- dataset creation
- snapshots/replication tasks
- minimal storage-only responsibilities

### In a dedicated file-services guest
Preferred baseline:
- Debian LXC or small Debian VM
- Samba
- NFS if container/privilege model is acceptable, otherwise use a VM

Suggested exports/mounts from host into guest:
- `tank/shared`
- `tank/media`
- `tank/backups` (maybe limited)
- optional app/share datasets as needed

### In a separate Nextcloud guest
- Nextcloud app
- database (same guest or separate, depending on scale)
- dedicated mounted dataset for user data

Suggested dataset:
- `tank/nextcloud-data`

## NFS / Samba strategy
### NFS
Best for:
- Linux clients
- Proxmox storage consumers
- internal service mounts
- media workflows

### Samba
Best for:
- user-facing shared folders
- desktop access
- mixed-client compatibility

### Practical recommendation
Run both:
- **NFS for infrastructure and Linux-oriented access**
- **Samba for human-facing general file access**

## Nextcloud considerations
Nextcloud is a high-priority service and should not be an afterthought.

### Suggested design
- run Nextcloud in its own guest
- reverse proxy it from your edge/reverse-proxy service
- store user data on a dedicated ZFS dataset
- snapshot the dataset regularly
- separate app/config from bulk user data where practical

### Suggested datasets
- `tank/nextcloud-data`
- optional: `tank/nextcloud-backups`

## Suggested dataset layout
Example starting point:
- `tank/shared`
- `tank/media`
- `tank/backups`
- `tank/nextcloud-data`
- `tank/appdata`
- `tank/vmdata` or Proxmox-managed VM storage dataset

Possible tuning by dataset:
- compression enabled broadly
- quotas where useful
- separate snapshot retention by dataset importance
- recordsize tuned later only if actual workload benefits are clear

## Important operational advice
- keep some free space in the pool; do not run ZFS near 100%
- document disk serials and bay positions
- use SMART monitoring and alerting
- plan backups separately from redundancy; mirrors are not backups
- do not overload the Proxmox host with unrelated apps

## Open design questions
- should the file-services guest be an LXC or a VM?
- do you want NFS from the same guest as Samba, or NFS directly on host?
- will media and VM storage share one pool, or do some workloads need stronger isolation?
- what is the backup target for critical datasets and Nextcloud data?
- do you have HBA passthrough constraints that might push design one way or another?

## Recommended next actions
1. identify exact SAS HBA/controller plan
2. document expected drive sizes/models
3. decide whether file services should run in Debian LXC or VM
4. define initial datasets and share names
5. define backup plan for `shared`, `media`, and `nextcloud-data`