Unifi UNAS-Pro Backup Strategy

UniFi UNAS-Pro Master Backup Strategy: Native Rsync Daemon (Pull) Architecture#

This document defines the complete operational standard, architecture, schedule matrix, node-by-node configuration reference, and disaster recovery procedures for backing up all shared data from the master UniFi UNAS-Pro NAS (10.1.2.2) across the fleet of 5 TrueNAS SCALE storage nodes (HP1, HP2, HP3, HP6, HP7). It is designed to be sufficient to fully reconstruct the entire setup from scratch.

The former HP7TrueNAS node (10.1.1.17) is now HP6TrueNAS. The storage dataset, SMB shares, and backup script have been renamed to the HP6 identifiers.

Scripts Management Migration Plan

Scripts Management Migration Plan#

This document is the master architectural migration plan for establishing /Users/marc/Scripts as your primary local master Git repository, linked to git@github.com:marcoue/Scripts.git, with automated mirroring to the UNAS-Pro NAS (/Volumes/Software/Software/Scripts/) and automated pull execution by remote TrueNAS/Linux/Proxmox nodes.


1. Executive Summary & Architecture Goal#

🎯 Primary Master Architecture#

  1. Master Repository: /Users/marc/Scripts on your Mac SSD is your primary master repository for editing, testing, running, and managing all homelab scripts.
  2. GitHub Remote: Linked to git@github.com:marcoue/Scripts.git on branch main.
  3. Automated NAS Mirroring: A Git post-commit hook automatically syncs committed scripts from ~/Scripts/ to /Volumes/Software/Software/Scripts/ on UNAS-Pro.
  4. Remote Server Pull Execution: Remote servers (HP1, HP2, HP3, HP7, HP8, Proxmox, Linux) pull their scripts from UNAS-Pro (Software/Scripts/) on their scheduled runs.

πŸ”„ Data & Deployment Flow#

  [Mac Workstation] (Primary Master Workspace)
   └── ~/Scripts/ (git@github.com:marcoue/Scripts.git)
        β”œβ”€β”€ MacOS/
        β”œβ”€β”€ Linux/
        β”œβ”€β”€ Proxmox/
        └── TrueNAS/
             β”‚
             β”œβ”€β”€ (git commit)
             β–Ό
        [Git post-commit Hook]
             β”‚
             β”œβ”€β”€ (rsync auto-mirror)
             β–Ό
  [UNAS-Pro Master NAS] (Distribution Mirror)
   └── /Volumes/Software/Software/Scripts/
        β”œβ”€β”€ MacOS/
        β”œβ”€β”€ Linux/
        β”œβ”€β”€ Proxmox/
        └── TrueNAS/ (Exposed as Rsync Module: root@10.1.2.2::Software/Scripts/TrueNAS/)
             β”‚
             β”œβ”€β”€ (Rsync pull on schedule)
             β–Ό
  [Remote Nodes: HP1, HP2, HP3, HP7, HP8, Proxmox, Linux]
   └── Local Execution of Version-Controlled Scripts

πŸ“‚ 1.1 Filesystem Standard & Disaster Recovery Protocol#

  1. Standard POSIX Filesystem Path:
    • The destination path /Volumes/Software/Software/Scripts/ (and subfolders MacOS/, Linux/, Proxmox/, TrueNAS/) is a standard, plain-text directory tree residing on the mounted Software SMB share (smb://10.1.2.2/Software). There are zero proprietary databases, hidden hooks, or custom file structures on the NAS.
  2. Mac Auto-Mount Convenience (Login Items):
    • To ensure the SMB share is always available for Git post-commit auto-mirroring, add /Volumes/Software to macOS System Settings > General > Login Items.
  3. macOS Reinstall / Disaster Recovery:
    • Reinstalling or replacing macOS on your Mac Studio has zero effect on UNAS-Pro or TrueNAS servers. The NAS files remain intact, and TrueNAS backup cron jobs continue executing without interruption.
    • To restore your Mac workstation repo after a fresh macOS install:
      # Step 1: Clone master repository from GitHub
      git clone git@github.com:marcoue/Scripts.git ~/Scripts
      
      # Step 2: Re-install 1-line Git post-commit auto-mirror hook
      cat << 'EOF' > ~/Scripts/.git/hooks/post-commit
      #!/usr/bin/env bash
      if [ -d "/Volumes/Software/Software/Scripts" ]; then
          rsync -av --delete --exclude='.git' --exclude='*.log' /Users/marc/Scripts/ /Volumes/Software/Software/Scripts/
      fi
      EOF
      chmod +x ~/Scripts/.git/hooks/post-commit

2. Complete Script Inventory & Mapping#

The following table lists all existing scripts found across your NAS repository (git@github.com:marcoue/Scripts.git) and local Mac folder (~/Scripts/), mapped to their final category subfolders:

Unifi UNAS-Pro Backup Migration Plan

UNAS-Pro Backup Migration Plan: SMB (Push) to Native Rsync Daemon (Pull)#

Antigravity Chat: agy –conversation=4c0c9b6d-2722-4fd6-a4aa-638c75ab46f4

This document is the complete master migration plan for transitioning the UNAS-Pro backup strategy from the UniFi Drive UI-managed SMB (Push) setup to a Native Rsync Daemon (Pull) model.

Because the UniFi Drive UI natively supports Rsync server settings and shared folder modules, migrating to Rsync requires configuring your TrueNAS SCALE servers (HP1, HP2, HP3, HP6, HP7) to pull the backups directly from the UNAS-Pro Rsync daemon over TCP port 873.

2026-07-23 - UniFi WAN Security Audit Report

UniFi UDM-SE WAN, Security & IPv6 Audit Report#

Date: July 23, 2026
Gateway Device: Ubiquiti UniFi Dream Machine Special Edition (UDM-SE)
Firmware Version: 5.1.19.33549
Primary ISP (WAN1): Cogeco Connexion (1000 Mbps Down / 30 Mbps Up)
Failover ISP (WAN2): VidΓ©otron (Currently Down - Offline)
Secondary Backup ISP (WAN3): Starlink (CGNAT)


1. Executive Summary#

An in-depth audit of the UniFi Dream Machine SE gateway was performed via the UniFi API. The assessment evaluated the primary WAN (WAN1 - Cogeco Connexion), secondary failover WAN (WAN2 - VidΓ©otron), and backup satellite WAN (WAN3 - Starlink).

KVM - Tripp Lite Java Web Start Fix

Tripp Lite KVM Java Web Start (JNLP) Setup & SSL Fix#

This guide documents the fix for opening the Tripp Lite KVM virtual console (viewer.jnlp) on macOS when modern Java blocks connections due to legacy TLS/SSL cipher handshake failures.


1. Problem Overview#

When launching viewer.jnlp via Java Web Start (javaws), the applet fails with the following errors:

com.sun.deploy.net.FailedDownloadException: Unable to load resource: https://10.1.5.2:443/iClientJ12111.jar@pid=...
javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure

Cause#

Tripp Lite IP KVM switches (and rebranded ATEN/Avocent devices) rely on legacy SSL/TLS protocols (TLS 1.0 / TLS 1.1) and deprecated ciphers (e.g., 3DES, 1024-bit Diffie-Hellman keys). Modern Java runtimes (Java 8u291+ and newer) disable these protocols by default in java.security.

Proxmox - PBS Backups via NAS with to GDrive

Proxmox Backup Server (PBS) - Backups via NAS to GDrive (Decoupled, Monitored & Encrypted)#

This guide is intended for off-site disaster recovery (DR) copies, not as a primary backup destination.

This documentation covers a decoupled, stage-based architecture: The PBS Method (Deduplicated Datastore on NAS): The Proxmox Backup Server (PBS) host HP1BackupServer (10.1.1.211) mounts a local NAS share under proper system ownership (uid=34) to run a fully deduplicated backup datastore. A dedicated sync container MMDocker (10.1.2.230) mounts the same share to asynchronously push the deduplicated chunk structure to Google Drive via an optimized rclone sync script.

Proxmox Backup Server - Mounting an SMB NAS Share as a PBS Datastore

Proxmox Backup Server - Mounting an SMB NAS Share as a PBS Datastore#

This note outlines the step-by-step process used to mount a remote SMB/Samba share from a NAS onto a Proxmox Backup Server (PBS) host at the OS level, assign proper permissions for the PBS daemon, and initialize it as a new backup datastore.

Prerequisites#

  • A target share on the NAS (e.g., //10.1.2.2/ProxmoxBackups).
  • An existing SMB credentials file on the PBS host (e.g., /root/.smb_credentials).

Step-by-Step Implementation#

Step 1: Create the Local Mount Directory#

Create a dedicated folder at the root of the PBS host filesystem where the network share will be attached.

Backrest & Restic Google Drive Backup Setup

NAS Backup Pipeline: Backrest, Restic & Google Drive#

Complete configuration guide for backing up isolated TrueNAS/DSM network shares from the headless Ubuntu VM (HP1Docker) to an encrypted Google Drive repository using Backrest (a Web UI wrapper for Restic) and Rclone. For baseline Rclone installation, remote management, and CLI commands, see the RClone Guide.


1. System Architecture Overview#

  • Source Data: 8 explicit network shares mounted via CIFS/SMB on the host VM at /mnt/<ShareName>.
  • Backup Host: Ubuntu VM (HP1Docker - 10.1.2.202).
  • Backup Agent: Backrest Docker Container running Restic 0.18.1.
  • Target Backend: Google Drive (proxmox.app@gmail.com) via a dedicated Rclone remote.
  • Security Model: Client-side, zero-knowledge encryption via a dedicated repository password before data leaves the local host.
  • Rate-Limit Protections: Powered by a custom Google Cloud Project ID to bypass global multi-user API query restrictions during multi-terabyte data transfers.

2. Directory Structure Setup#

All configuration and container runtime files are centralized on the host under the user deployment directory.

Starlink

Starlink Emergency Network Backup Playbook#

This document outlines the operational and financial strategy for utilizing a Starlink Mini hardware kit on a Roam subscription tier as an infrastructure-independent secondary WAN failover. This configuration completely bypasses local terrestrial infrastructure dependencies (cell towers and cable/fiber nodes) during extended power grid collapses.


1. Core Architecture Strategy#

  • Integrated Router: Router is built directly into the dish panel, featuring a native, weather-sealed RJ45 Ethernet port. No proprietary Ethernet adapters required.
  • Direct WAN Hand-off: Connects directly from the dish into the secondary WAN port of the local gateway/firewall (e.g., UniFi Gateway).
  • Power Efficiency: Draws 25–40 Watts. Capable of native DC power input, making it resilient when running off standard 100W USB-C PD power banks or 12V portable generator setups.

Plan Selection: Roam Tier#

  • Cell Congestion Immunity: Roam plans skip geographic cell capacity checks. If an emergency triggers a mass local reactivation event, the system will block standard Residential activations but will approve Roam activations instantly.
  • Mobility Option: Allows the hardware to be disconnected from the home mount and utilized remotely for off-grid operations or travel.

2. Financial Metrics (CAD)#

  • Standby Mode Base Rate: $15.00 / month
  • Roam 100GB Tier: $75.00 / month
  • Roam Unlimited Tier: $200.00 / month
  • Over-Cap Throttled Speed: 1.0 Mbps Download / 0.5 Mbps Upload
  • Annual Idle Maintenance: $180.00 / year

3. Operational Lifecycles & Playbooks#

Configuration A: Baseline Idle State#

  1. Connect the Starlink Mini to the secondary WAN port of the gateway.
  2. Place the Starlink subscription into Standby Mode via the account portal.
  3. Keep the unit powered on.
    • Result: The dish consumes minimal background data to maintain alignment, pull critical system firmware updates, and pass basic network pings.
    • Bandwidth Cap: Throughput is strictly capped at 500 Kbps in this state. The link remains live just enough to load the Starlink management portal and process two-factor authentication (2FA) emails.

Configuration B: Phase 1 Activation (Short-Term Outage)#

Execute this phase when local terrestrial links drop and an extended power grid outage is confirmed.

Linux - Unattended-Upgrades

Unattended-Upgrades Configuration (VM & LXC)#

Not Used, as a reference only

The objective of this guide is to safely automate software updates across a high-density environment of virtual machines and LXC containers, significantly reducing daily manual maintenance without compromising infrastructure stability. By shifting from a manual execution model to a structured deployment using the native unattended-upgrades utility, the system handles the download, installation, and post-update cleanup of all packages automatically in the background. Rather than allowing unpredictable automated reboots that could disrupt active services or interfere with critical backup windows, this configuration enforces a strict “notify-only” baseline. It leverage a lightweight mail client to alert the administrator immediately when a reboot is pending, combining hands-free patching with complete operational control.