Skip to content

Self-Hosted Personal Cloud Infrastructure

Building a private, encrypted, multi-platform file system on a repurposed HP Z2 Mini G5 workstation — replacing a paid iCloud subscription with infrastructure I own and control.

Overview

I had an HP Z2 Mini G5 workstation (Intel i9-10900K, 64GB RAM, dual 1TB NVMe SSDs) sitting unused while I daily-drove a laptop. Rather than let it continue collecting dust, I deployed it as a headless Linux server hosting a personal cloud file system accessible from my Windows laptop, iPhone, and Mac — over an encrypted private network reachable from anywhere in the world.

The result is a system that's faster than iCloud on my home network, eliminates a recurring subscription, and gave me hands-on experience with the same Linux + networking + monitoring stack that modern utilities, SCADA systems, and cloud platforms run on.

This write-up documents the architecture, technical decisions, and skills demonstrated. It was built in a single weekend as a learning project during my second year of Power Systems Engineering at Conestoga College.

Architecture

┌───────────────────────────────────────────────────────────┐
│                  Devices (anywhere)                        │
│   Windows Laptop  ·  iPhone  ·  MacBook (planned)         │
└────────────┬──────────────────┬───────────────────────────┘
             │                  │
             │  SMB over Tailscale (encrypted, peer-to-peer)
             │                  │
┌────────────▼──────────────────▼───────────────────────────┐
│              HP Z2 Mini G5 — Headless Server              │
│                                                            │
│   Ubuntu Server 24.04 LTS                                 │
│   ├── Tailscale (mesh VPN with Let's Encrypt HTTPS)       │
│   ├── Samba (SMB file sharing for Windows/macOS/iOS)      │
│   ├── smartd → msmtp → Gmail (drive health monitoring)    │
│   └── cron + rsync (versioned snapshot backups)           │
│                                                            │
│   Drive 1 (Samsung 1TB NVMe): OS + applications           │
│   Drive 2 (SK hynix 1TB NVMe): /data/files (user data)    │
│   Drive 3 (Samsung T5 500GB USB): /mnt/backup (snapshots) │
└───────────────────────────────────────────────────────────┘

The system is intentionally not exposed to the public internet. All access flows through Tailscale's WireGuard-based encrypted overlay network, which means:

  • Services listen only on the private tailnet, not on public IPs
  • Authentication is handled by Tailscale's identity layer
  • Traffic between devices is end-to-end encrypted and routed peer-to-peer when possible
  • No port forwarding, no public DNS records pointing to my server

Implementation

1. Operating System Installation

I installed Ubuntu Server 24.04 LTS (long-term support) on the workstation with a custom storage layout designed for failure isolation:

  • Drive 1 (Samsung NVMe): OS at /, with a small EFI partition for boot
  • Drive 2 (SK hynix NVMe): User data mounted at /data

This separation means I can rebuild the OS without losing data, and the OS drive's heavier write workload doesn't compete with file storage I/O.

# Custom partition layout during install:
# /dev/nvme1n1p1 → /boot/efi  (1G)
# /dev/nvme1n1p2 → /          (953G, OS drive)
# /dev/nvme0n1p1 → /data      (953G, dedicated data drive)

Ubuntu Server is headless by design — no GUI, controlled entirely via SSH. After initial setup, I unplugged the monitor and keyboard. The machine now lives on a shelf and is administered remotely.

2. Encrypted Remote Access via Tailscale

To access the server from outside my home network without exposing it to the public internet, I deployed Tailscale, an open-source mesh VPN built on WireGuard.

Tailscale handles the hard problems of NAT traversal, key exchange, and mesh networking automatically. After installing the client and authenticating, every device on my account becomes addressable by hostname (e.g., ssh gabriel@z2mini) regardless of which network it's on. Traffic flows peer-to-peer when possible, falling back to encrypted relays only when both endpoints are behind restrictive NAT.

# Install Tailscale and authenticate
curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up --ssh

# Enable Tailscale's SSH replacement — uses tailnet identity
# instead of separately managing SSH keys/passwords

Enabling Tailscale SSH replaces traditional SSH authentication with Tailscale's identity provider, eliminating a class of credential management problems.

3. Cross-Platform File Sharing with Samba

For file sharing, I evaluated the major options:

Option Native iOS Files Native Windows Native macOS Verdict
Nextcloud Poor (third-party app required) Good Good Skipped — iOS UX gap
WebDAV Mediocre Buggy on Windows Good Skipped — Windows issues
SMB (Samba) Excellent Native Native Selected

I configured Samba with two shares:

  • \\z2mini\files — read-write, primary user data
  • \\z2mini\backup — read-only, view backup snapshots without risk of accidental modification
[files]
   path = /data/files
   valid users = gabriel
   force user = gabriel
   create mask = 0664
   directory mask = 0775
   vfs objects = catia fruit streams_xattr
   fruit:metadata = stream
   fruit:model = MacSamba

The fruit VFS module (Samba's Apple/macOS compatibility layer) handles edge cases around iOS Files behavior, including resource forks, extended attributes, and file metadata. Without these settings, iOS Files exhibited read-only behavior despite the share being writable.

The shares mount natively on every platform with no third-party software required.

4. Versioned Backup System

A simple mirror backup is dangerous: if a file gets accidentally deleted, the next backup propagates the deletion. To protect against accidental deletion as well as drive failure, I implemented a versioned snapshot system using rsync and hard links — the same technique Apple's Time Machine uses.

How it works: - A "current" mirror tracks the latest state - Each daily run creates a new dated snapshot via hard-linked copy - Unchanged files share storage across snapshots, so 30 daily snapshots of mostly-unchanged data take roughly the same disk space as one copy

Retention policy: - 7 daily snapshots - 4 weekly snapshots (Sundays only)

#!/bin/bash
# Versioned backup with hard-linked snapshots

# Safety check: verify backup drive is mounted before writing
if ! mountpoint -q /mnt/backup; then
    echo "ERROR: /mnt/backup is not mounted. Aborting." >&2
    exit 1
fi

# Sync source to "current" mirror
rsync -a --delete /data/files/ /mnt/backup/current/

# Create today's hard-linked snapshot if it doesn't exist
TIMESTAMP=$(date '+%Y-%m-%d')
[ ! -d "/mnt/backup/daily/$TIMESTAMP" ] && \
    cp -al /mnt/backup/current/ /mnt/backup/daily/$TIMESTAMP

# Sunday: also create weekly snapshot
[ "$(date '+%u')" = "7" ] && [ ! -d "/mnt/backup/weekly/$TIMESTAMP" ] && \
    cp -al /mnt/backup/current/ /mnt/backup/weekly/$TIMESTAMP

# Prune: keep last 7 daily, last 4 weekly
find /mnt/backup/daily -maxdepth 1 -mindepth 1 -type d | sort | head -n -7 | xargs rm -rf
find /mnt/backup/weekly -maxdepth 1 -mindepth 1 -type d | sort | head -n -4 | xargs rm -rf

Scheduled via cron to run daily at 3 AM. Files deleted accidentally can be recovered from any of the past 7 days, and weekly snapshots extend that window to a month.

5. Drive Health Monitoring with Email Alerts

Hardware fails. To get advance warning, I configured smartd (the SMART monitoring daemon) to perform daily short self-tests on all three drives and email me only when something is wrong.

Setting up email from a home server is non-trivial because residential IPs are widely blocked by major mail providers. I used msmtp to relay through Gmail's SMTP servers using an app password, which involved configuring AppArmor profiles to allow msmtp to write its log file under Ubuntu's mandatory access control system.

# /etc/smartd.conf — daily 2 AM short self-tests, email on issues
/dev/nvme0n1 -a -s S/../.././02 -m gabrielgabrie99@gmail.com
/dev/nvme1n1 -a -s S/../.././02 -m gabrielgabrie99@gmail.com
# backup drive: Samsung 990 PRO in an ASMedia USB-NVMe enclosure — needs -d sntasmedia and a stable by-id path
/dev/disk/by-id/usb-ASMT_2462_NVME_2504178506CB-0:0 -d sntasmedia -a -m gabrielgabrie99@gmail.com

# /etc/apparmor.d/local/usr.bin.msmtp
/var/log/msmtp.log rwk,

The philosophy is silence equals healthy. I never get routine status emails — only alerts when SMART detects pre-failure conditions, read errors, temperature thresholds, or self-test failures.

6. Security Posture

Security choices made deliberately:

  • No public internet exposure. Services listen only on the Tailscale interface; the server has no public-facing ports.
  • Mandatory access control via AppArmor. Even processes running as root are restricted to specific filesystem paths and operations.
  • Non-root user for daily operations. Administrative tasks use sudo; the user account has no password authentication for SSH (Tailscale identity only).
  • Separate Samba password database. Network share authentication is decoupled from system login.
  • Encrypted backups via filesystem-level controls. Backup drive uses ext4 with proper permissions; the drive is physically secured.

Skills Demonstrated

This project required hands-on experience across several technical domains:

Linux Systems Administration - Ubuntu Server installation with custom partitioning - Headless server management via SSH - Service configuration via systemd - Filesystem management (ext4, mount points, fstab, UUIDs) - AppArmor profile customization - Log rotation and cron scheduling

Networking - VPN architecture with WireGuard-based mesh networking - Cross-platform file sharing protocols (SMB/CIFS, comparison with WebDAV) - DNS, hostname resolution, NAT traversal concepts - Trade-off analysis between security models

Storage and Backup Architecture - Multi-drive layouts for failure isolation - Filesystem selection (ext4 vs. exfat trade-offs) - Versioned snapshot backups with hard links - SMART health monitoring and predictive failure detection - Disaster recovery planning

Scripting and Automation - Bash scripting with safety checks (mount validation, error handling) - rsync for incremental synchronization - cron for scheduled task execution - Email automation through SMTP relay

Security - Defense-in-depth principles - Mandatory access control (AppArmor) - Encrypted overlay networks - Credential management (app passwords, key-based auth)

Why This Matters for Power Systems Engineering

Modern utility infrastructure increasingly runs on the same Linux + containerized + secure-network stack used in this project. Smart grid platforms, SCADA gateways, EMS systems, IoT for advanced metering infrastructure, and grid analytics platforms all rely on these foundational skills.

A 2025 Canadian Electricity Association estimate puts grid modernization investment at over $1.7 trillion by 2050. The engineers who can bridge traditional power systems knowledge with modern software infrastructure are positioned to contribute meaningfully to this transition. Building this homelab gave me direct experience with the operational concerns — uptime, monitoring, backups, security — that matter when these systems are running critical infrastructure.

Lessons Learned

A few things I'd highlight from the experience:

Simplicity beats sophistication for personal infrastructure. I initially architected an elaborate Caddy + Tailscale plugin setup for HTTPS-with-custom-domains. After hours of debugging, I recognized I was over-engineering and pivoted to a simpler design. The lesson: validate the simplest path works end-to-end before adding complexity.

Documentation as a deliverable, not a byproduct. Writing this up clarified my own understanding of decisions I made under pressure. Several architecture choices got better as I articulated them.

The 90% solution often beats the 100% solution. Self-hosted file sync (e.g., Nextcloud) tries to perfectly replicate iCloud's "everything offline everywhere" model and ends up with mediocre iOS integration. SMB makes a different trade-off — files live on the server, accessed live — and ends up feeling better in daily use precisely because it's simpler.

Honest debugging matters. Several times during the build, an approach that should have worked didn't. Each time, the right move was to read the actual error logs carefully rather than trust my mental model. The discipline of "what does the system actually say?" is as valuable in software as in power systems analysis.

Cost Analysis

Item Cost
HP Z2 Mini G5 workstation $0 (already owned, otherwise unused)
64GB DDR4 RAM upgrade $0 (previously installed)
Samsung T5 500GB external SSD $0 (already owned)
Ubuntu Server 24.04 LTS $0 (open source)
Tailscale (Personal plan) $0 (free tier sufficient)
Samba $0 (open source)
Monthly recurring cost (server) $0
iCloud subscription $12.99/month → $3.99/month (downgraded from 2 TB to 200 GB tier — kept for iMessage history, Family Sharing pool, and iPhone Backup; Photos moved to Immich)

Annual savings: ~$108. Cost over a 5-year horizon: ~$540. Not a full elimination of the iCloud bill — iMessage attachments, the Family Sharing storage pool, and iPhone Backup keep ~150 GB of legitimate iCloud usage that isn't worth self-hosting separately. The win is moving the dominant cost (the 458 GB Photos library) onto infrastructure I own.

Future Work

Planned next iterations:

  • Off-site backup to a drive kept at my parents' home, manually rotated monthly — protection against fire/theft scenarios
  • Energy data collection pipeline — using the server's always-on availability to continuously scrape and analyze IESO public data (Ontario electricity prices, demand, generation mix), building a unique dataset for power systems analysis
  • Web-accessible dashboard for visualizing energy data and providing portfolio-quality demos for co-op interviews
  • Migration to ethernet connectivity when I move in September — Wi-Fi works but ethernet eliminates a category of network reliability concerns
  • HTTPS reverse proxy properly implemented with Caddy + DNS challenge for cleaner URLs on portfolio-facing services

About Me

I'm Gabriel Gabrie, a second-year Power Systems Engineering student at Conestoga College with a strong software background. My interests sit at the intersection of energy infrastructure and modern software practices — specifically how the digitalization and electrification of Canada's grid creates opportunities for engineers who can work across both domains.

I hold a CAPM and am working toward my PMP. Other projects in my portfolio include:

  • Prices — a real-time Ontario electricity price visualization
  • Circuits — circuit analysis tooling
  • Minimal — minimalist productivity tooling

Portfolio: gabrielgabrie.com LinkedIn: Connect with me

This system was built in May 2026 as part of an ongoing effort to develop both technical depth and the kind of self-directed infrastructure skills that map cleanly to a career in modern utility engineering.