Backup Strategies#

1. Backrest & Restic Google Drive Backup#

Encrypts TrueNAS/DSM network shares with Restic and stores them in Google Drive through Rclone. See Backrest & Restic Google Drive Backup Setup.

2. Proxmox PBS Backup to Google Drive#

Synchronizes the deduplicated PBS datastore from the UNAS-Pro NAS to Google Drive through MMDocker and Rclone. See Proxmox - PBS Backups via NAS with to GDrive.

3. UNAS-Pro to TrueNAS Rsync Pull Backups#

TrueNAS nodes pull shared data from UNAS-Pro on staggered hourly schedules into local ZFS datasets. See Unifi UNAS-Pro Backup Strategy.

Frigate Installation Project Plan#

codex resume 01a010cc-f385-7fb1-bda6-375f3a85e303

UniFi Protect remains the primary NVR. Frigate will be an additional detection and classification layer. No installation or configuration should begin until the read-only validation phase is complete.

1. Project Objectives#

1.1 Functional Objectives#

The system will detect animals using Frigate motion detection, object detection, tracking, and zones.

It will distinguish coyotes from chickens, dogs, cats, deer, raccoons, foxes, and unknown animals. The initial tuning priority is avoiding missed coyote detections; false positives can be reduced afterward.

Local AI Camera Detection Documentation#

codex resume 01a01163-4a3e-7cd2-b780-30eef5e8f62d Continuation: codex resume 01a01b8f-a60c-7f01-9173-c4c189929d3b

This document describes the working local visual-classification implementation and the information required to recreate it. It is documentation, not a task list.

1. Purpose and Design Principles#

1.1 Purpose#

The system adds a second-stage visual classifier to the existing UniFi Protect and Home Assistant installation.

UniFi Protect remains responsible for recording video and detecting broad event categories such as animal, person, or vehicle. Home Assistant receives the Protect event, obtains an image, sends it to a local vision-capable Ollama model, evaluates the structured result, records the decision, and sends a notification only when the objective-specific policy accepts the result.

Home Assistant - Stale & Unavailable Devices Cleanup#

This checklist tracks all stale, orphaned, and currently unavailable entities in Home Assistant grouped by physical/virtual device. Use the interactive checkboxes (- [ ]) to track your manual cleanup in the Home Assistant UI or via SSH.

Summary Stats:

• Total Devices / Groups: 5
• Total Affected Entities: 21
• Stale Restored Entities (Registry Orphans / Deprecated): 10
• Currently Unavailable Entities (Offline Hardware / Connection Loss): 11

Cleanup Methods#

1. UI Deletion (Recommended for Stale / Orphaned Entities):
   • Go to Settings > Devices & Services > Entities.
   • Filter by Status: Restored / Unavailable or search the entity ID.
   • Select the checkbox next to the entity and click Delete Selected (red button at top).
2. Device / Integration Reconfiguration:
   • If an entire device is decommissioned (e.g. old Meross Coop Door opener replaced by ESPHome), go to Settings > Devices & Services > [Integration] > Devices, click the 3 dots on the device card, and click Delete.
3. Companion App Cleanup:
   • On mobile devices, disable unused tracking sensors in HA App Settings > Companion App > Manage Sensors to remove them cleanly.

1. Meross Smart Plugs, Switches & Openers (1 Devices, 2 Entities)#

• Garage Driveway Lights (Meross Dimmer) (Garage — 2 entities — Unavailable / Offline)
  • light.garage_driveway_lights_meross_dimmer — Garage Driveway Lights (Meross Dimmer) (light) — 🔴 Offline / Unavailable
  • sensor.garage_driveway_lights_meross_dimmer_signal_strength — Garage Driveway Lights (Meross Dimmer) - signal_strength (sensor) — 🔴 Offline / Unavailable

2. Aqara, Zigbee & Matter Sensors (3 Devices, 17 Entities)#

• Aqara Motion Sensor (No Area — 5 entities — Stale Restored)

📱 Home Assistant & UniFi Device Management Standard#

1. Executive Summary & Architecture#

This document defines the Single Source of Truth (SSOT) Device Management Architecture for the Homelab environment.

To optimize speed, usability, and data integrity:

1. Google Sheets serves as the Primary User Entry Interface. Adding or editing devices in the spreadsheet is fast, accessible on mobile/desktop, and requires zero complex IPAM UI navigation.
2. NetBox (v4.2) serves as the Automated IPAM & DCIM System of Record. It is hosted on 10.1.2.202:8082 and reconciled directly from Google Sheets via terminal alias.

flowchart LR
    A["Google Sheets (User Entry)"] -->|Mac Studio Alias: netbox| B["sync_gsheets_to_netbox.py"]
    B -->|Non-Destructive Delta Sync| C["NetBox v4.2 (10.1.2.202:8082)"]
    C -->|API & Interoperability| D["UniFi UDM / Home Assistant / Pi-hole"]

2. Standard Operating Procedure (SOP) for Device Management#

A. Adding or Editing Devices#

1. Open the Google Sheet inventory (Devices tab).
2. Add or edit any row (Location, Name, Serial, MAC, IP, Type, Brand).
3. Open your Mac Studio terminal and type:

   netbox

4. Outcome: The script fetches your spreadsheet, securely sends the inventory to NetBox on 10.1.2.202:8082, and updates your network records in seconds.

B. Retiring or Deleting a Device#

• Option 1 (Archive / Keep Record): Change the Location column in Google Sheets to Z-Inactive.
  • Behavior: The sync script automatically skips all Z-Inactive rows during import, removing the device from active NetBox IPAM while preserving historical records in your spreadsheet.
• Option 2 (Permanent Delete): Delete the row from the Google Sheet and run netbox.

3. Work Completed#

During the system implementation, the following key engineering milestones were achieved:

Master Plan: UNAS Pro SMB Usage Inventory#

This document outlines the proposed step-by-step strategy to perform a comprehensive audit and inventory of all workloads, computers, virtual machines, Docker stacks, and scripts utilizing SMB shares from the UNAS Pro (10.1.2.2) NAS.

Active Share Matrices#

Workstations & Computers#

Mac Studio (10.1.2.4)#

MMProxmox (10.1.1.10)#

HP1 Proxmox (10.1.1.11)#

Scripts & Automations#

Target Inventory Scope#

The inventory will discover and map every dependency on the UNAS Pro SMB shares across four distinct layers:

UniFi UNAS-Pro Pool Migration Strategy: Pool 1 (SSD) to Pool 2 (HDD)#

This document defines the operational plan, safety protocols, database update queries, and verification steps to migrate all shared folders from Storage Pool 1 (SSD - Degraded RAID5) to Storage Pool 2 (HDD - Healthy RAID5) on the master UniFi UNAS-Pro NAS (10.1.2.2) while preserving all access rights, Samba configurations, and TrueNAS backup operations.

Antigravity chat: agy –conversation=3dd15667-3c79-485d-af10-ebb5c4f9cc01

1. Executive Summary & Objective#

Due to hardware failures on Pool 1 (Slot 2 pulled, Slot 3 accumulating 75,000+ write failures), Pool 1 is operating with zero fault tolerance. To prevent data loss prior to receiving warranty replacement drives, all active shares on Pool 1 will be migrated to Pool 2.

📜 Scripts Management Process#

Workstation Sync Shortcut: To automatically backup all your scripts and custom terminal aliases configuration (staging and pushing your entire ~/Scripts/ repository):

pushscripts

This will stage all modified files in ~/Scripts/, commit, and push updates directly to GitHub and your NAS (without running Homebrew operations).

Workstation Update Shortcut: To pull down the latest custom scripts and terminal aliases from GitHub on an existing machine (after the first-time setup is complete):

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, HP7, HP8). It is designed to be sufficient to fully reconstruct the entire setup from scratch.

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

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: