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.

This approach isolates WAN latency and internet dependency from your hypervisors to preserve system stability.

Why This Decoupled Approach?#

Directly mounting a cloud filesystem to Proxmox via rclone mount on the hypervisors can overwhelm network shares, cause thread lockups during snapshots, or throw I/O errors if internet bandwidth fluctuates.

By separating the duties:

• Stage 1: Local Backup (Fast Path) – Proxmox VE nodes backup directly to the PBS API on HP1BackupServer. PBS instantly deduplicates the data and writes 4MB chunks to the local NAS. This completes at LAN speeds and releases VM snapshot locks quickly.
• Stage 2: Cloud Sync (Asynchronous Path) – The dedicated synchronization machine MMDocker wakes up on a schedule, grabs those new encrypted chunks from the NAS, and sweeps them to Google Drive. Hypervisors remain completely untouched by the cloud transfer.

Architecture Flow#

  [ Proxmox VE (HP1) ]               [ Proxmox VE (HP2) ]
           │                                  │
           ▼ Deduplicated Backups via PBS API ▼
┌────────────────────────────────────────────────────────┐
│         Proxmox Backup Server (HP1BackupServer)        │
│                    IP: 10.1.1.211                      │
│  - Local mount: /Backups-Priority                      │
│  - Mounted via SMB with uid=34,gid=34                  │
└──────────────────────────┬─────────────────────────────┘
                           │ Writes chunks to
                           ▼
┌────────────────────────────────────────────────────────┐
│                  Local NAS (UNAS Pro)                  │
│             Path: //10.1.2.2/ProxmoxBackups            │
└──────────────────────────┬─────────────────────────────┘
                           │
                           │ Mounted via SMB (noperm)
                           ▼
┌────────────────────────────────────────────────────────┐
│             Sync Host: MMDocker (10.1.2.230)           │
│  23:00 PM Scheduled Scripted Sync                      │
│  - Locks execution via flock                           │
│  - Executes parallel rclone sync                       │
│  - Triggers email summary via msmtp                    │
└──────────────────────────┬─────────────────────────────┘
                           │
                 Encrypted Stream Layer
                           ▼
┌────────────────────────────────────────────────────────┐
│                  Google Drive Cloud                    │
│               Path: GDrive-Encrypted:                  │
└────────────────────────────────────────────────────────┘

Prerequisites#

Before beginning, ensure you have:

• An SMB or NFS share created on your NAS (10.1.2.2) configured to accept backups.
• Proxmox Backup Server running on HP1BackupServer (10.1.1.211).
• SSH access to the dedicated sync machine MMDocker (10.1.2.230).
• A Google Cloud OAuth Client ID and Client Secret configured in your Google Developer Console.
• A Gmail account with 2-Step Verification enabled and a 16-character App Password created (to send status notifications).

Step 1 – Mount the NAS Share on the PBS Host (HP1BackupServer)#

You must mount the NAS share at the OS level on your PBS machine. You must force permissions to the PBS system user (backup, UID 34) so the PBS daemon has permission to write database chunks.

1. SSH into HP1BackupServer (10.1.1.211).
2. Create the local directory:

   mkdir -p /Backups-Priority

3. Create the SMB credentials file to store the NAS login details securely:

   nano /root/.smb_credentials

   Paste the following lines (replacing with your actual NAS username and password):

   username=YOUR_NAS_USERNAME
   password=YOUR_NAS_PASSWORD

   Secure the file so only the root user can read it:

   chmod 600 /root/.smb_credentials

4. Open /etc/fstab and append the following persistent mounting rule:

   //10.1.2.2/ProxmoxBackups /Backups-Priority cifs credentials=/root/.smb_credentials,uid=34,gid=34,iocharset=utf8,vers=3.0,nofail,_netdev 0 0

5. Reload systemd and mount the folder:

   systemctl daemon-reload && mount -a

6. Confirm ownership is correct (backup backup should own /Backups-Priority):

   ls -la / | grep Backups-Priority

(Note: From the PBS Web GUI, you can now add /Backups-Priority as a Datastore).

Step 2 – Detailed Rclone Setup Wizard on MMDocker#

Log into your dedicated synchronization host MMDocker (10.1.2.230) to set up rclone. For baseline Rclone installation, remote management, and CLI commands, see the RClone Guide. If it is not installed, install it natively:

sudo apt update && sudo apt install rclone -y

Launch the configuration wizard:

rclone config

1. Base Remote (GDrive)#

1. Current remotes: Type n for New remote.
2. name: Enter GDrive.
3. Storage: Type drive (Google Drive).
4. client_id: Paste your custom Google Cloud OAuth Client ID.
5. client_secret: Paste your custom Google Cloud OAuth Client Secret.
6. scope: Type 3 to select drive.file (Access to files created or opened by rclone only).
7. service_account_file: Leave blank.
8. Edit advanced config? Type n.
9. Use web browser to automatically authenticate? Type n (headless environment).
10. Result: Copy the terminal command string provided by rclone. Run that command on a local desktop machine where you are logged into your target Google Account.
11. Verification: Paste the long authorization token string returned by your desktop terminal back into the headless sync node prompt on MMDocker.
12. Configure this as a Shared Drive? Type n.
13. Keep this “GDrive” remote? Type y.

2. Encryption Remote (GDrive-Encrypted)#

Create the second, encrypted structural layout directly over your newly established Google Drive pipe:

1. Current remotes: Type n for New remote.
2. name: Enter GDrive-Encrypted.
3. Storage: Type crypt.
4. remote: Type GDrive:Proxmox-Backups.
5. filename_encryption: Type 1 (standard).
6. directory_name_encryption: Type 1 (true).
7. password: Generate or type a strong password. Store it in your password manager!
8. password_salt: Generate or type a strong salt. Store it in your password manager!
9. Keep this “GDrive-Encrypted” remote? Type y.
10. Quit: Type q to exit.

Step 3 – Mount the NAS Target on MMDocker#

To let rclone access the raw chunks generated by PBS, MMDocker (10.1.2.230) must mount the same NAS target folder.

1. SSH into MMDocker (10.1.2.230).
2. Create a local path on the system:

   mkdir -p /mnt/ProxmoxBackups

3. Create the SMB credentials file /root/.smb_credentials (similar to Step 1) to securely store the NAS login details on this host:

   sudo nano /root/.smb_credentials

   Paste your NAS details:

   username=YOUR_NAS_USERNAME
   password=YOUR_NAS_PASSWORD

   Secure the file:

   sudo chmod 600 /root/.smb_credentials

4. Open /etc/fstab and add the persistent mounting line:

   //10.1.2.2/ProxmoxBackups /mnt/ProxmoxBackups cifs credentials=/root/.smb_credentials,iocharset=utf8,noperm,_netdev,nofail 0 0

5. Reload systemd and mount the directories:

   sudo systemctl daemon-reload && sudo mount -a

Step 4 – Configure System Mail Delivery (msmtp) on MMDocker#

To send automatic status recaps, configure a lightweight mail forwarder (msmtp) on MMDocker.

1. Install the utilities:

   sudo apt install msmtp msmtp-mta mailutils -y

2. Open the global configuration file:

   sudo nano /etc/msmtprc

3. Paste the following settings, substituting your sender email and the Gmail App Password:

   defaults
   auth             on
   tls              on
   tls_trust_file   /etc/ssl/certs/ca-certificates.crt
   logfile          /var/log/msmtp.log
   
   account          gmail
   host             smtp.gmail.com
   port             587
   from             YOUR_SENDER_EMAIL@gmail.com
   user             YOUR_SENDER_EMAIL@gmail.com
   password         YOUR_16_CHAR_GMAIL_APP_PASSWORD
   
   account default : gmail

4. Secure the configuration file permissions:

   sudo chmod 600 /etc/msmtprc
   sudo chown msmtp:root /etc/msmtprc

Step 5 – Deployment and Script Setup on MMDocker#

This synchronization wrapper script runs on MMDocker (10.1.2.230). It is highly optimized for pushing the massive amounts of small 4MB chunk files that PBS creates.

Path: /home/marc/scripts/priority_backups_rclone_gdrive_sync.sh

#!/bin/bash

# ==============================================================================
# SCRIPT: priority_backups_rclone_gdrive_sync.sh
# PATH: /home/marc/scripts/priority_backups_rclone_gdrive_sync.sh
# PURPOSE: Syncs Priority PBS backups to GDrive, checks cloud space, and emails recaps.
# 
# QUICK SETUP COMMANDS:
#      1. Create directory and file:
#         mkdir -p /home/marc/scripts && nano /home/marc/scripts/priority_backups_rclone_gdrive_sync.sh
#      2. Make the script executable:
#         chmod +x /home/marc/scripts/priority_backups_rclone_gdrive_sync.sh
#
# Manual start: /home/marc/scripts/priority_backups_rclone_gdrive_sync.sh
# Check logs: tail -f /home/marc/logs/priority-sync/sync_$(date +%Y-%m-%d)*.log
# Manual Start with logs check: /home/marc/scripts/priority_backups_rclone_gdrive_sync.sh & sleep 2 && tail -f /home/marc/logs/priority-sync/sync_$(date +%Y-%m-%d)*.log
# ==============================================================================

# --- CONFIGURATION ---
SOURCE_DIR="/mnt/ProxmoxBackups"
REMOTE="GDrive-Encrypted:"
EMAIL_TO="proxmox.app@gmail.com"

DATE=$(date +%Y-%m-%d_%Hh%M)
LOG_DIR="/home/marc/logs/priority-sync"
LOG_FILE="$LOG_DIR/sync_$DATE.log"

# Ensure log directory exists under marc's home

# --- PRE-FLIGHT PROCESS LOCK (flock) ---
exec 200>"/tmp/priority_rclone_gdrive_sync.lock"
if ! flock -n 200; then
    echo "Priority Sync already in progress. Exiting."
    exit 1
fi

# --- LOGGING ---
> "$LOG_FILE"
exec > >(tee -a "$LOG_FILE") 2>&1

# --- HELPER: GET CLOUD FREE SPACE ---
get_cloud_free_space() {
    local space
    space=$(/usr/bin/rclone about "$REMOTE" 2>/dev/null | grep -i "Free:" | awk '{print $2, $3}')
    if [ -z "$space" ]; then
        echo "Unknown (API Timeout/Unreachable)"
    else
        echo "$space"
    fi
}

# --- INITIAL SPACE CHECK ---
echo "Checking initial cloud storage availability..."
START_SPACE=$(get_cloud_free_space)
echo "Initial Free Space: $START_SPACE"
echo "----------------------------------------------"

# --- NOTIFICATION (Fires via Trap) ---
send_notification() {
    EXIT_CODE=$?
    STATUS=$([ "$EXIT_CODE" -eq 0 ] && echo "SUCCESS" || echo "FAILED")
    
    # Small pause to guarantee rclone finishes flushing its log file buffer to disk
    sleep 1

    # Query final space right before sending email
    END_SPACE=$(get_cloud_free_space)

    # Extract the final rclone statistics block from the log
    STATS_BLOCK=$(grep -E "^Transferred:|^Errors:|^Checks:|^Deleted:|^Elapsed time:" "$LOG_FILE" | tail -n 8)

    {
      echo "Status: $STATUS"
      echo "Run Date: $(date)"
      echo "Log File: $LOG_FILE"
      echo "----------------------------------------------"
      echo "Google Drive Capacity Profile:"
      echo "  - Cloud Free Space (Before Sync): $START_SPACE"
      echo "  - Cloud Free Space (After Sync) : $END_SPACE"
      echo "----------------------------------------------"
      echo "Rclone Statistics:"
      if [ -n "$STATS_BLOCK" ]; then
          echo "$STATS_BLOCK"
      else
          echo "No transfer statistics generated."
      fi
      echo "----------------------------------------------"
      if [ "$EXIT_CODE" -ne 0 ]; then
          echo "!!!! SYNC ENCOUNTERED ERRORS !!!!"
          echo "Last 15 lines of log for debugging:"
          tail -n 15 "$LOG_FILE"
      fi
    } | mail -s "MMDocker backup of HP1PBSBackups-Priority - $STATUS" "$EMAIL_TO"

    # Housekeeping: Keep only the last 7 days of local logs
    find "$LOG_DIR" -name "sync_*.log" -type f -mtime +7 -delete
}
trap send_notification EXIT INT TERM

echo "=========================================="
echo "RCLONE SYNC START: $DATE"
echo "=========================================="

# --- EXECUTE SYNC (OPTIMIZED FOR PBS SMALL CHUNKS) ---
/usr/bin/rclone sync "$SOURCE_DIR" "$REMOTE" \
    --local-no-preallocate \
    --fast-list \
    --drive-use-trash=false \
    --transfers 16 \
    --checkers 32 \
    --buffer-size 32M \
    --drive-chunk-size 64M \
    --log-file="$LOG_FILE" \
    --log-level INFO

# Capture the exact exit code of rclone immediately so success/fail state is accurate
RCLONE_EXIT_CODE=$?

echo "=========================================="
echo "SYNC PROCESS COMPLETED WITH CODE: $RCLONE_EXIT_CODE"
echo "=========================================="

# Exit with rclone's code to trigger the trap notification accurately
exit $RCLONE_EXIT_CODE

Make the script executable:

chmod +x /home/marc/scripts/priority_backups_rclone_gdrive_sync.sh

Step 6 – Automate via Cron Schedule on MMDocker#

Open the crontab environment on MMDocker (10.1.2.230):

crontab -e

Add your scheduled synchronization line to run the high-priority PBS datastore sync every night at 23:00 (11:00 PM):

# Run priority PBS backup sync to Google Drive every night at 11:00 PM
0 23 * * * /home/marc/scripts/priority_backups_rclone_gdrive_sync.sh >/dev/null 2>&1

Step 7 – Disaster Recovery: Restoring a PBS Datastore from GDrive#

Because your off-site backups are a heavily deduplicated chunk structure that has been encrypted by rclone, a Proxmox hypervisor cannot read them directly from the cloud. You must use rclone to present the chunk architecture to a PBS instance (either by downloading it or mounting it directly), attach that local folder as a PBS datastore, and then restore via PVE.

       [ Google Drive Cloud ] (Encrypted Chunks)
                 │
        ┌────────┴────────┐
        │                 │
        │ Method 1:       │ Method 2:
        │ rclone mount    │ rclone sync
        │ (On-the-fly)    │ (Full download)
        ▼                 ▼
 ┌──────────────────────────────┐
 │     Any Local PBS Server     │ -> Add path as a PBS Datastore
 └──────────────┬───────────────┘
                │
                │ PVE Connects to PBS
                ▼
 ┌──────────────────────────────┐
 │         Proxmox Host         │ -> Restore VMs via PVE GUI
 └──────────────────────────────┘

DR Prerequisites: Before attempting recovery, you must have:

1. A working Proxmox VE (PVE) host.
2. A running Proxmox Backup Server (PBS) instance (can be a physical host, or a temporary VM inside PVE).
3. Your rclone.conf details stored offsite (e.g., in a password manager), containing the Google Cloud OAuth API keys, and specifically the password and salt for the GDrive-Encrypted remote.

Recovery Strategies: Detailed Analysis#

Method 1: The “On-the-Fly” Direct Mount (Recommended for Fast Recovery)#

Instead of waiting for a multi-terabyte sync download to finish, you can mount the encrypted Google Drive folder directly to a temporary PBS instance using rclone mount.

1. How it works: rclone decrypts files on the fly. PBS treats the mount point as a standard directory, reading the backup index files (.fidx / .didx) and requesting chunks only when a VM restore is actually triggered.
2. Pros:
   • Near-instant restore startup: You can start restoring your most critical VM (e.g., your router, firewall, or main server) within minutes of setting up the fresh PBS.
   • No local staging space needed: You don’t need a huge temporary NAS or spare drive to store the entire 2TB+ datastore.
3. Cons:
   • WAN Bottlenecks: Restore speeds are limited by your WAN/Internet download speed.
   • Latency: High latency during restore because chunks (each 4MB) are fetched over HTTPS on demand.

Command Example for Mounting:

rclone mount GDrive-Encrypted: /mnt/Recovered-Datastore \
    --vfs-cache-mode full \
    --allow-other \
    --read-only &

(Note: Using --vfs-cache-mode full helps cache requested chunks locally, reducing redundant WAN requests).

Method 2: The Full Sync Down (The Original Method)#

You use rclone sync to download the entire chunk structure to local storage first, then attach it to PBS.

1. Pros:
   • LAN-Speed Restores: High restore speed since PVE pulls from a local LAN speed datastore.
   • No Internet Dependency during Restore: Once the download is complete, your restore process will not be impacted by internet dropouts.
2. Cons:
   • High Time-to-Recovery (TTR): You must wait for the entire sync to complete before you can recover even a single VM. If you have 2TB of backups, this could take hours or days depending on your internet connection.
   • Staging Space: Requires you to have a replacement local storage target (like a new NAS or large local drive) ready and mounted beforehand.

Command Example for Syncing:

rclone sync GDrive-Encrypted: /mnt/Recovered-Datastore --fast-list --transfers 16 --checkers 32 -P

Step-by-Step Recovery Workflow (Total-Loss Scenario)#

If your homelab is completely gone and you need to rebuild from scratch, this is the exact sequence to follow:

  [ New PVE Host ] ◄─── Restores VMs via LAN ─── [ Temporary PBS ]
                                                        │
                                                 rclone mount/sync
                                                        │
                                                        ▼
                                             [ Google Drive (Cloud) ]

Step 1: Install a clean Proxmox VE (PVE) host#

• Get a hypervisor back up and running.

Step 2: Spin up a temporary PBS (Proxmox Backup Server)#

• Install PBS on a spare physical machine, or simply spin it up as a fresh VM inside your new PVE.

Step 3: Install and configure Rclone on the new PBS#

• Log into your new PBS instance over SSH and install rclone and fuse3 (required for mounting cloud drives):

  apt update && apt install rclone fuse3 -y

• Recreate the rclone.conf configuration (located at /root/.config/rclone/rclone.conf).

  This is your single point of failure. You must have the Google Client ID, Client Secret, and most importantly, the Encryption Password and Salt for the GDrive-Encrypted remote stored off-site (e.g., in a password manager like Bitwarden or 1Password). Without these keys, the chunks on GDrive are useless garbage.

Step 4: Mount or Sync the Datastore#

• If mounting on-the-fly: Run the rclone mount command to mount GDrive-Encrypted: to /mnt/Recovered-Datastore (see Method 1 above).
• If syncing fully: Mount your new local NAS/disk at /mnt/Recovered-Datastore, and run the rclone sync command (see Method 2 above).

Step 5: Attach the Datastore in PBS#

• Fix directory ownership so PBS can access it:

  chown -R backup:backup /mnt/Recovered-Datastore

• Log into the PBS Web GUI, go to Datastore -> Add Datastore, name it (e.g., Cloud-Recovery), and set the backing path to /mnt/Recovered-Datastore.
• Click Add. PBS will automatically read the existing metadata. All your backup groups, snapshots, and VM files will instantly populate in the PBS GUI.

Step 6: Connect PVE and Restore#

• Log into the PVE Web GUI.
• Navigate to Datacenter -> Storage -> Add -> Proxmox Backup Server.
• Add the temporary PBS instance and select the Cloud-Recovery datastore.
• Go to the storage node in the PVE tree, open the Backups tab, choose the VM you need to recover first, and click Restore.

🔒 Do you need local PVE Encryption Keys?#

No, you do not. Your current PVE storage configuration (/etc/pve/storage.cfg) does not use client-side encryption for the PBS storages.

This is highly beneficial for disaster recovery because the VM backup files are not encrypted with keys stored locally on PVE. Once you authenticate to the PBS server, you can restore them immediately without needing any lost PVE-side keys. The only encryption layer in place is the one managed by rclone on GDrive, which you can easily decrypt using your saved password/salt.

Step 8 – Quick Command Reference (Start, Monitor, Stop)#

Below is a cheat sheet of commands to manually control and monitor your background sync operations on MMDocker (10.1.2.230).

1. The “Start & Watch” Combo#

If you want to manually trigger the sync outside of the cron schedule and instantly watch the live transfer statistics on your screen, use this one-liner:

/home/marc/scripts/priority_backups_rclone_gdrive_sync.sh & sleep 2 && tail -f /home/marc/logs/priority-sync/sync_$(date +%Y-%m-%d_%Hh%M).log

(Press Ctrl+C at any time to stop viewing the log—the sync will safely continue running in the background).

2. Monitor an Already Running Sync#

If the cron job started automatically or you previously launched the script and want to peek at the current progress:

tail -f /home/marc/logs/priority-sync/sync_*.log

3. Check if the Sync is Currently Running#

To verify if rclone is actively transferring data, check your active system processes:

ps aux | grep rclone

Alternatively, check if the system lock file exists (which prevents overlapping runs):

ls -la /tmp/priority_rclone_gdrive_sync.lock

4. Safely Stop/Kill an Active Sync#

If you need to instantly abort a running sync, you must kill both the rclone transfers and the bash script wrapper. This will safely terminate the active streams and trigger the cleanup trap:

killall rclone && killall priority_backups_rclone_gdrive_sync.sh

(Note: Because of --fast-list and chunk comparisons, starting the script again later will instantly pick up exactly where it left off without wasting bandwidth).

Step 9 – Deactivate and Wipe the PBS-to-GDrive Backup Service#

This procedure permanently deletes the PBS backup data, the NAS datastore contents, and all data in the Google Drive Proxmox-Backups target. Do not run it until the deletion scope has been reviewed and approved. The separate restic-nas-backups target and the Backrest/Restic process are not part of this procedure.

The commands below apply to the following hosts:

• Proxmox VE nodes: disable the jobs that write backups to PBS.
• HP1BackupServer (10.1.1.211): remove PBS backup groups/snapshots and the datastore configuration.
• MMDocker (10.1.2.230): stop the Google Drive sync and remove its schedule/configuration.
• NAS (10.1.2.2): delete the underlying ProxmoxBackups share data.

9.1 Disable the Google Drive sync first#

On MMDocker, inspect the current schedule:

crontab -l

Edit the crontab and remove or comment out:

0 23 * * * /home/marc/scripts/priority_backups_rclone_gdrive_sync.sh >/dev/null 2>&1

Stop any active sync and verify that it is no longer running:

pkill -TERM -f '/usr/bin/rclone sync /mnt/ProxmoxBackups GDrive-Encrypted:' || true
pkill -TERM -f 'priority_backups_rclone_gdrive_sync.sh' || true
pgrep -af 'rclone|priority_backups_rclone_gdrive_sync' || true

Do not delete the NAS data until all active sync processes have stopped.

9.2 Disable Proxmox backup jobs#

On every Proxmox VE node, list the configured backup jobs and identify only those whose target is the PBS datastore being retired:

pvesh get /cluster/ vzdump --output-format yaml

Disable or remove the matching jobs through Datacenter → Backup in the Proxmox UI. Confirm that no new jobs are writing to HP1BackupServer before continuing.

9.3 Inventory the PBS datastore before deletion#

On HP1BackupServer, identify the exact datastore name and path:

proxmox-backup-manager datastore list
cat /etc/proxmox-backup/datastore.cfg
findmnt /Backups-Priority

Record the datastore name, repository path, backup groups, and snapshot count. Do not substitute another datastore or path.

9.4 Delete PBS backup groups and snapshots#

Use the PBS web interface on the identified datastore:

1. Open Datastore → Content.
2. Select the backup groups and snapshots belonging to this datastore.
3. Delete the snapshots/groups.
4. Confirm that the content list is empty.
5. Run garbage collection from Datastore → Garbage Collection.

Alternatively, use the PBS CLI only after identifying the exact repository and snapshot list. Review every candidate before deleting:

proxmox-backup-client snapshot list --repository 'USER@REALM!TOKEN@PBS_HOST:DATASTORE'

Use the PBS UI for deletion where possible because it makes the datastore and snapshot scope visible before confirmation.

9.5 Remove the PBS datastore configuration#

After the datastore content is empty, remove only the retired datastore definition using the PBS UI or the datastore management command:

proxmox-backup-manager datastore remove DATASTORE_NAME

Replace DATASTORE_NAME only after verifying it against /etc/proxmox-backup/datastore.cfg. Removing the configuration does not by itself prove that the underlying NAS files are deleted.

9.6 Delete the NAS datastore data#

On the NAS, verify that the exact share is ProxmoxBackups and that no other service uses it:

find /path/to/ProxmoxBackups -mindepth 1 -maxdepth 1 -print

After confirming the path, delete the contents of that share through the NAS UI, or use an explicitly reviewed path-specific command:

find /path/to/ProxmoxBackups -mindepth 1 -maxdepth 1 -exec rm -rf -- {} +

Do not use /, /mnt, or an unresolved wildcard as the deletion target. Remove the SMB mount from /etc/fstab on PBS and MMDocker only after the data deletion is complete and the mounts are no longer needed.

9.7 Delete all data at the Google Drive target#

In the proxmox.app@gmail.com Google Drive account:

1. Open the Proxmox-Backups folder.
2. Delete the entire folder, including encrypted chunks, encrypted directories, metadata, and hidden files.
3. Empty Google Drive trash if permanent deletion is intended.
4. Confirm that restic-nas-backups was not selected or deleted.

9.8 Remove the sync software and credentials#

On MMDocker, after the data is deleted and the process is disabled:

rm -f /home/marc/scripts/priority_backups_rclone_gdrive_sync.sh
rm -rf /home/marc/logs/priority-sync
rm -f /tmp/priority_rclone_gdrive_sync.lock

Remove the GDrive and GDrive-Encrypted remotes using rclone config, and revoke the corresponding Google OAuth authorization. Remove the custom Google OAuth client only if no other process uses it.

9.9 Verify the wipe and deactivation#

On MMDocker:

crontab -l
pgrep -af 'rclone|priority_backups_rclone_gdrive_sync' || true
find /home/marc/scripts /home/marc/logs -iname '*priority*' -print 2>/dev/null

On HP1BackupServer:

proxmox-backup-manager datastore list
cat /etc/proxmox-backup/datastore.cfg
findmnt /Backups-Priority

Finally, confirm that the source Proxmox VM/LXC disks, the unrelated restic-nas-backups repository, and all other NAS shares remain intact.

10. Migrate to a New Google Drive Account from the NAS#

Use this procedure when the previous Google Drive account is no longer accessible and the backup must be rebuilt from the current PBS datastore on the NAS. This is a fresh cloud backup; it does not copy or recover the old Google Drive repository.

The migration source remains:

/mnt/ProxmoxBackups

10.1 Pause the existing sync#

On MMDocker (10.1.2.230), comment out the existing 23:00 cron entry and stop any active sync. Follow the pause and stop commands in Step 9.1.

Verify that no sync process remains:

pgrep -af 'rclone|priority_backups_rclone_gdrive_sync' || true

10.2 Verify the NAS source#

Confirm that the NAS share is mounted and that the PBS datastore is present before starting the new upload:

findmnt /mnt/ProxmoxBackups
ls -la /mnt/ProxmoxBackups

Avoid running a new PBS backup during the initial baseline upload. If new chunks are written during the upload, run a second catch-up sync after the baseline completes.

10.3 Create a new Google Drive remote#

On MMDocker, run:

rclone config

Create a new Google Drive remote, for example:

GDrive-New

Authorize it with the new Google account. The old Google OAuth authorization is not required.

10.4 Create a new encrypted remote#

Create a new crypt remote, for example:

GDrive-Encrypted-New

Configure it over:

GDrive-New:Proxmox-Backups

Use standard filename encryption and encrypted directory names. Generate a new encryption password and salt, and store both securely off-site. These new values are required for future restores.

10.5 Point the sync script to the new account#

Edit /home/marc/scripts/priority_backups_rclone_gdrive_sync.sh and change only the remote configuration:

SOURCE_DIR="/mnt/ProxmoxBackups"
REMOTE="GDrive-Encrypted-New:"

Do not change the NAS source path.

10.6 Perform the initial full upload#

Start the documented sync script manually and monitor its log:

/home/marc/scripts/priority_backups_rclone_gdrive_sync.sh
tail -f /home/marc/logs/priority-sync/sync_*.log

This upload may take considerable time because the complete PBS datastore is being sent to the new account.

10.7 Verify and complete the migration#

After the initial upload completes, compare the NAS source and new encrypted remote:

rclone check /mnt/ProxmoxBackups GDrive-Encrypted-New:

Run a second catch-up sync to transfer any chunks created during the initial upload. Confirm the log and email report success.

Finally, uncomment the daily 23:00 cron entry and perform a restore validation using the new Rclone configuration and the newly stored encryption password and salt.

The NAS datastore is not deleted or modified by this procedure. The previous Google Drive repository and its historical cloud-only data remain unavailable if the old account cannot be recovered.