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#

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.

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 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#

Hardware Selection: Starlink Mini#

• 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.

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.

1 n8n Automated Server Audit — “Intelligent Server Update Monitor with AI Recommendations”#

When local SMTP is unavailable or when you want a richer, centrally-consolidated overview of the entire fleet’s update posture, an n8n workflow (imported from Intelligent Server Update Monitor with AI Recommendations.json) runs on a repeating schedule to SSH into every node, inspect pending packages via apt list --upgradable, send those results through a local Ollama instance for intelligent categorisation, and deliver the verdict in your inbox.

Installing and Launching Pi (pi.dev)#

Follow these steps to set up the Pi coding agent on your Mac Studio and link it straight to your custom local short-context models.

1 Environment Preparation#

Because Pi is a JavaScript terminal application, it runs on Node.js. If you do not have Node installed yet, use Homebrew to get it ready.

1.1 Install Node.js via Homebrew#

brew install node

2 Installation#

Install the official global Pi command-line tool. As noted in the documentation, we include the security flag to bypass unnecessary third-party package scripts.

Hugo file GenDash: Obsidian to Hugo Automated Publishing Guide

This guide outlines the infrastructure and configuration required to sync an Obsidian vault across multiple devices and automate the publishing process to a Hugo website via Cloudflare Pages.

1. Multi-Device Sync (The Git & Web Layer)#

To sync your notes between computers and view them on mobile devices without the overhead of real-time database sync engines:

1.1. Between Computers (Mac Studio & MacBook Pro/Air)#

We use the Obsidian Git plugin to synchronize GenDash vaults directly via GitHub.

App Store Submission Checklist#

1. Administrative & Legal#

• 1.1 Active Apple Developer Program Membership: Annual subscription required to distribute on the store.
• 1.3 App Store Connect User Access: Proper permissions for the team members managing the submission.
• 1.2 Facultative - I’ll start with the individual account - D-U-N-S Number: Unique identifier used by Apple to verify business entities for organizations.
• 1.4 Paid Applications Agreement: Signed contract required for apps with a purchase price or subscriptions, via https://appstoreconnect.apple.com/ (Demande TPS-TVQ fait 27 avril)
• 1.5 Banking and Tax Information: Verified details needed for Apple to process your earnings.
• 1.6 Public Privacy Policy URL: A web link detailing how you handle and protect user data. (https://github.com/marcoue/GenDash-Support/ and Privacy form in App store)
• 1.7 Export Compliance Documentation: Proof of clearance for apps utilizing specific types of encryption. (Via Info.plist file in Xcode)
• 1.8 Digital Services Act (DSA) Compliance: Mandatory legal registration for distribution within the European Union. (Opted out for now as it requires my personal home address)

2. Technical Requirements#

• 2.1 Latest Mandatory Xcode Version Build: The binary must be compiled with the current Apple-approved IDE.
• 2.2 Latest iOS SDK Compatibility: Ensuring the app supports current system APIs and frameworks.
• 2.3 App Privacy Manifest: A .privacyinfo file documenting the data types accessed by your code.
• 2.4 SHA-256 Certificate Support: Modern security standard required for app signing certificates.
• 2.5 64-bit Architecture Support: Technical requirement for compatibility with all modern iOS hardware.
• 2.6 Optimized Binary Size: Monitoring the final build to stay within cellular download limits. (When app is completed)
• 2.7 Bitcode Disabled: Adherence to modern standards where bitcode is no longer required for thinning.

3. Metadata#

• 3.1 App Name: The primary title of the application as it appears in search.
• 3.2 Subtitle: A secondary tagline used to summarize the app’s purpose.
• 3.3 Description: A full text overview of features and functionality for potential users.
• 3.4 Keywords: A hidden list of terms that improve the app’s search discoverability.
• 3.5 Promotional Text: A short, editable field to highlight news or limited-time updates.
• 3.6 Marketing URL: A link to your product’s landing page or company website.
• 3.7 Support URL: A direct link where users can go for technical help or FAQs.
• 3.8 Version Number and Build String: Incremental identifiers for tracking your releases and builds.
• 3.9 Category Selection: Tags that determine which store departments the app resides in.

4. Visual Assets#

• 4.1 App Icon: A 1024x1024 px image representing the app on home screens.
• 4.2 Screenshots for 6.7" Display: Visuals for the largest iPhone models like the Pro Max.
• 4.5 iPad Screenshots: Required imagery if your app is compatible with iPadOS.

5. App Review Information#

• 5.1 Demo Account Credentials: Login data provided to allow reviewers to access hidden features.
• 5.2 Review Notes: Extra instructions to help the reviewer understand complex workflows.
• 5.3 Reviewer Contact Information: Name and number for the person Apple should call with questions.
• 5.4 Hardware Requirements: Documentation of any external hardware needed for the app to work.

6. Privacy & Content#

• 6.1 Privacy Nutrition Labels: A summary of what data is collected and how it is linked.
• 6.2 Accessibility Nutrition Labels: A declaration of the app’s support for assistive technologies.
• 6.3 Age Ratings: A self-assessment used to determine content suitability for different age groups.
• 6.4 App Tracking Transparency (ATT) Prompt: The system-level request for permission to track user data.
• 6.5 Content Rights: Legal confirmation that you have the rights to use all displayed content.

7. Pricing & Availability#

• 7.1 Pricing Tier Selection: The defined cost for purchasing the app or in-app services.
• 7.2 Regional Availability: A list of specific countries where the app will be available.
• 7.3 Pre-order Status: A setting to allow users to sign up for the app before launch.
• 7.4 Release Methodology: A choice between manual, scheduled, or automatic publication.

8. Critical Alerts Entitlement & Implementation#

• Submit the “Critical Alerts Entitlement” Request Fill out the official Apple form providing a safety-based justification for why GenDash fuel/status alerts must bypass the mute switch.

The Antigravity Pro Developer Playbook#

Using an agentic IDE like Antigravity in 2026 requires a shift from “typing code” to “orchestrating intelligence.” This guide covers the mental models and technical strategies to build complex apps like GenDash while maximizing credit efficiency.

1 XCode MCP#

{
  "mcpServers": {
    "xcode-tools": {
      "command": "npx",
      "args": ["-y", "xcodebuildmcp@latest", "mcp"]
    }
  }
}

2 The Model Garage: Choosing the Right Engine#

In Antigravity, you have a team of experts. Don’t use a supercar for a grocery run.