Storage & Backup Architecture

Storage and backup infrastructure support the availability, recoverability, and long-term maintenance of OnyxNet.

The environment uses TrueNAS for network storage and Proxmox Backup Server (PBS) for virtualization backup capabilities.

These technologies serve different purposes, but both contribute to infrastructure resilience.

Implementation Status

Component	Status
TrueNAS	Operational
ZFS storage	Operational
Proxmox Backup Server	Deployed
Complete backup coverage audit	Not yet documented
Verified recovery procedures	Documentation pending
Ginnungagap offsite backup	Deferred

The presence of backup infrastructure does not establish that every workload is protected or that every recovery procedure has been successfully tested.

High-Level Architecture

The existing storage and backup systems can be represented conceptually as:

OnyxNet Infrastructure
        |
        +-- TrueNAS
        |     |
        |     +-- ZFS Storage Pools
        |     +-- Datasets and Files
        |     +-- Snapshot Capabilities
        |
        +-- Proxmox Environments
              |
              +-- Aesir Production Cluster
              +-- Vanir Experimental Environment
              |
              +-- PBS Backup Infrastructure

This is a functional overview, not a representation of verified physical storage connections or complete backup coverage.

TrueNAS — Network Storage

TrueNAS provides centralized storage services within the homelab.

ZFS is the underlying storage technology.

Its capabilities include:

Storage pools
Filesystems and datasets
Data integrity checks
Snapshots
Replication
Storage management

The actual availability and protection of data depend on the deployed pool layout, configuration, and operational procedures.

ZFS Datasets

ZFS datasets provide a flexible way to organize data while allowing different management settings and protection policies.

Dataset properties can include compression, quotas, permissions, and snapshot schedules.

The current dataset inventory and settings should be reviewed before publishing detailed configuration claims.

ZFS Snapshots

ZFS snapshots preserve a point-in-time view of a dataset or volume.

They can help recover previous file versions and support replication workflows.

However, snapshots stored on the same physical system are not a substitute for an independent backup copy.

Loss of the entire storage system may also destroy locally stored snapshots.

Proxmox Backup Server

Proxmox Backup Server provides dedicated backup capabilities for Proxmox virtual machines and Linux containers.

The environment includes an existing PBS target.

PBS uses a backup datastore to hold backup data and associated metadata.

Its capabilities include:

Incremental backup processing
Deduplication
Backup retention management
Integrity verification
Guest and file recovery
Remote datastore synchronization

Actual coverage and operational configuration must be evaluated separately.

Backup Coverage

Backup coverage should be documented per workload.

For each important virtual machine or container, the following information is useful:

Attribute	Purpose
Workload	Identifies the protected service
Source environment	Identifies Aesir or Vanir
Backup destination	Identifies the intended PBS datastore
Schedule	Establishes when protection occurs
Retention	Defines available recovery points
Verification	Records backup integrity checks
Restore test	Records evidence of recoverability

This information belongs in an internal operational inventory unless it has been reviewed for public disclosure.

Local Storage vs. Backup Storage

Aesir uses node-local storage for its virtualization workloads.

That storage is separate from the existence of a PBS backup destination.

Local ZFS storage, guest backup storage, and shared storage are different architectural concepts.

A multi-node Proxmox cluster does not automatically provide shared disks or automatic application recovery.

Storage placement and recovery procedures must account for these differences.

Storage Reliability Considerations

Integrity

Integrity checks help identify corruption, but monitoring and repair capabilities depend on the storage configuration.

Availability

Redundant disks, where configured, may improve resilience against certain hardware failures.

Redundancy does not eliminate the need for backups.

Capacity

The environment has finite storage capacity.

Retention, application growth, snapshots, and backup datasets all compete for available space.

Recoverability

A backup system should be evaluated against specific recovery scenarios rather than only whether backup jobs finish successfully.

Future Offsite Resilience

Ginnungagap is a deferred offsite backup and disaster recovery project.

Its selected connectivity approach uses Tailscale rather than the originally proposed VLAN 700 transit design.

The future project is intended to protect:

TrueNAS datasets using an appropriate ZFS replication design.
Proxmox VM/LXC backups using an appropriate PBS-compatible mechanism.

No offsite deployment or tested replication capability is claimed at this time.

See ADR-001: Ginnungagap Connectivity.

Development Priorities

Near-term work can improve backup confidence without purchasing additional hardware.

Areas to review include:

Current storage inventory
Available backup capacity
Snapshot schedules and retention
Proxmox backup-job coverage
PBS verification jobs
Recovery procedures
Failure monitoring
Restore-test results

Engineering Takeaway

Reliable storage architecture requires more than sufficient disk capacity.

Data integrity, failure handling, backup coverage, retention, and recoverability must be considered together.