Proxmox Time Sync

Syncing time is essential on Proxmox servers, especially in a cluster — time drift can cause serious issues with quorum, backups, and HA.

Here’s how to ensure accurate time sync on your Proxmox nodes:


✅ Recommended Method: Use systemd-timesyncd (built-in on Debian)

🔧 1. Enable and start time sync:

sudo timedatectl set-ntp true

Verify:

timedatectl status

Look for:

NTP service: active
System clock synchronized: yes

This uses systemd-timesyncd, which is light and reliable for Proxmox servers.


🧰 Alternative: Use chrony (Recommended for more control)

chrony is more robust, especially if your nodes might be offline/online often or you’re doing HA.

1. Install chrony:

sudo apt install chrony

2. Edit config (optional):

sudo nano /etc/chrony/chrony.conf

Add or edit NTP servers:

server time.google.com iburst
server 0.pool.ntp.org iburst
server 1.pool.ntp.org iburst

3. Restart and enable:

sudo systemctl enable chrony
sudo systemctl restart chrony

4. Check sync status:

chronyc tracking


🧪 Verify Time Sync on Proxmox

On each node:

timedatectl

All nodes should show:

  • NTP service: active
  • System clock synchronized: yes
  • Same or very close times

🧠 Bonus: Sync RTC (hardware clock)

To sync system time to the hardware clock:

sudo hwclock --systohc


Let me know if you’re using a cluster and want to designate one Proxmox node as an NTP server for others, or if you’d like to sync from your Pi-hole box or router!

Perfect — turning one of your Proxmox nodes into an NTP server is a great idea for local time sync, especially in a cluster or if internet access is limited.

Here’s how to do it using chrony, which is ideal for Proxmox nodes:


🧭 Overview

  • One Proxmox node will be the NTP server.
  • The others will sync from it as NTP clients.

🖥️ On the Proxmox NTP Server (e.g., pve1)

1. Install chrony if not already installed:

sudo apt update
sudo apt install chrony

2. Edit the config to allow LAN clients

sudo nano /etc/chrony/chrony.conf

Add or uncomment these lines:

# Allow LAN subnet (adjust to your LAN range)
allow 192.168.1.0/24

# Make this machine act as an NTP server
local stratum 10

Optional: Use a known upstream NTP source for initial sync:

server time.google.com iburst
server 0.pool.ntp.org iburst

3. Restart chrony and enable it

sudo systemctl restart chrony
sudo systemctl enable chrony


🖥️ On the Proxmox Clients (e.g., pve2, pve3)

1. Install chrony:

sudo apt install chrony

2. Configure it to sync from the Proxmox NTP server:

sudo nano /etc/chrony/chrony.conf

Comment out existing server lines, and add:

server 192.168.1.10 iburst   # Replace with the IP of your Proxmox NTP server

3. Restart and enable:

sudo systemctl restart chrony
sudo systemctl enable chrony

4. Verify sync status:

chronyc sources
chronyc tracking

You should see something like:

Name/IP address             Stratum Poll Reach LastRx Last sample
===============================================================================
192.168.1.10                     10   6   377    32    -34us[ -44us] +/-  200us


🧪 Bonus: Test if the server is responding

From another node:

chronyc sources

Or:

ntpq -p 192.168.1.10


Let me know if you want to also allow the Pi-hole box or other clients on your LAN to sync from this NTP server too — it’s as easy as expanding the subnet in allow.

Migrate Windows 11 to NVME

Let’s walk through migrating your Windows 11 hard drive to a new NVMe drive! I’ll break it down step-by-step.


What you’ll need:

  • Your new NVMe drive installed in your PC (or an external NVMe enclosure).
  • Cloning software (free options: Macrium Reflect, AOMEI Backupper, or EaseUS Todo Backup).
  • A backup of important data (just in case).

⚙️ Step 1: Install the NVMe drive

  • If your motherboard has an M.2 NVMe slot, install the drive.
  • If not, you can use an external NVMe enclosure connected via USB.

🧵 Step 2: Format and initialize the new drive (if needed)

  • Open Disk Management (Windows key → type diskmgmt.msc → Enter).
  • If prompted to initialize the disk, use GPT (for Windows 11, since MBR doesn’t support Secure Boot or TPM 2.0).
    • This process does NOT format the drive — it just sets it up for use.
  • Don’t create partitions — the cloning software will handle that.

🔄 Step 3: Clone your Windows 11 drive
1️⃣ Download Macrium Reflect Free (or another cloning tool).
2️⃣ Open the software and select your current Windows 11 hard drive as the source disk.
3️⃣ Select the new NVMe drive as the destination disk.
4️⃣ Make sure to copy all partitions (including EFI, Recovery, and System partitions).
5️⃣ Start the cloning process — this might take some time.


🖥️ Step 4: Set the NVMe drive as the boot drive

  1. After cloning, reboot and enter your BIOS/UEFI (usually by pressing Del or F2 during startup).
  2. Set the NVMe drive as the first boot device.
  3. Save and exit.

🧹 Step 5: Verify and clean up

  • Boot into Windows from the NVMe drive.
  • Check that everything works properly (apps, files, Windows activation).
  • If all is good, you can format your old drive to use as extra storage.

Alternative: Fresh install option
If cloning isn’t your style, you can always do a fresh install of Windows 11 on the NVMe drive, then copy your data manually — sometimes this yields better performance and avoids issues with hidden partition mismatches.


Would you like to dive into BIOS/NVMe-specific settings for faster boot times? Let me know! 🚀

Optimizing BIOS/UEFI for your new NVMe boot drive can significantly improve performance and ensure a smooth boot process. Here’s how to do it!


⚙️ Step 1: Enter BIOS/UEFI

  • Restart your computer and repeatedly press Del, F2, or the key specific to your motherboard during boot.
  • Once inside BIOS, look for Boot, Storage, or Advanced settings (menu names may vary by motherboard).

🚀 Step 2: Optimize Boot Settings for NVMe

Set NVMe as the Primary Boot Drive

  • Navigate to the Boot Order or Boot Priority section.
  • Set your NVMe drive as the first boot device.
  • Disable the old hard drive in the boot list (if necessary).

Enable UEFI Mode

  • Windows 11 requires UEFI, not Legacy BIOS (CSM).
  • Find Boot Mode or CSM (Compatibility Support Module):
    • Set Boot Mode to UEFI (disable Legacy/CSM if you see it).
    • If you installed Windows 11 in GPT mode, UEFI must be enabled.

Enable NVMe Support (if applicable)

  • Some older motherboards require NVMe support to be manually enabled in BIOS.
  • Look for NVMe Configuration or PCIe Storage Support.
  • Ensure it is set to Enabled or Auto.

⚡ Step 3: Improve NVMe Performance

Enable PCIe 3.0 or 4.0 (if applicable)

  • Locate PCIe Configuration under Advanced settings.
  • Set PCIe mode to the highest supported version (e.g., Gen 3 or Gen 4).

Enable AHCI for SSDs (instead of RAID)

  • If your BIOS has SATA Mode, set it to AHCI instead of RAID/IDE.
  • AHCI ensures better performance for SSDs.

Enable Fast Boot (Optional)

  • Some BIOS versions offer Fast Boot, which reduces boot times.
  • Enable it, but disable it temporarily if you need to access BIOS frequently.

🔄 Step 4: Save and Reboot

  • Press F10 and select Save & Exit.
  • Your system should now boot quickly from the NVMe drive.

🔥 Extra Performance Tweaks in Windows

Once booted into Windows 11: 1️⃣ Enable Write Caching

  • Open Device Manager → Expand Disk Drives → Right-click your NVMe drive → Properties → Policies.
  • Enable Write Caching for better speed.

2️⃣ Enable TRIM for SSD Longevity

  • Open Command Prompt (Admin) and run: fsutil behavior query DisableDeleteNotify
  • If it returns 0, TRIM is enabled. If 1, enable it with: fsutil behavior set DisableDeleteNotify 0

3️⃣ Disable Hibernation (Optional, if space is a concern)

  • Run: powercfg -h off in Command Prompt (Admin).
  • Saves several GB of space on the NVMe drive.

🎯 Final Check

✅ Boot speed improved?
✅ Windows 11 running smoothly?
✅ No old drives interfering?

You’re all set! 🚀 Let me know if you need deeper tuning! 😃

It sounds like your Windows 11 boot process is tied to the M.2 SATA drive, even though your Kingston SA400 SSD is your main C: drive. Here’s how to troubleshoot and fix it:


🔍 Step 1: Check Boot Order in BIOS

  1. Enter BIOS/UEFI
    • Restart your computer and press F2, Del, or Esc (depends on your motherboard).
  2. Go to Boot Priority/Boot Order
    • Make sure your Kingston SA400 SSD is set as the first boot device.
    • If your M.2 SATA drive is missing, the system might default to BIOS because it cannot find a valid boot drive.

🔎 Step 2: Check If Bootloader Is on the M.2 SATA Drive

Your bootloader (Windows Boot Manager) may have been installed on your M.2 SATA drive instead of your Kingston SSD.
To check:

  1. Plug the M.2 SATA drive back in and boot into Windows.
  2. Open Disk Management
    • Press Win + X → Click Disk Management.
  3. Identify the “System Reserved” or EFI Partition
    • Look at both drives.
    • If the EFI System Partition (ESP, ~100-500MB, FAT32) is on the M.2 SATA drive, Windows relies on it to boot.

🛠 Step 3: Repair Bootloader on Kingston SSD

If your bootloader is missing from your Kingston SSD, you’ll need to recreate it.

Option 1: Automatic Repair

  1. Boot from a Windows 11 USB Installer.
  2. Select Repair your computerTroubleshootStartup Repair.
  3. Follow the on-screen instructions.

Option 2: Manually Rebuild Bootloader

If automatic repair doesn’t work:

  1. Boot from a Windows 11 USB Installer.
  2. Select Repair your computerTroubleshootCommand Prompt.
  3. Run these commands: diskpart list disk select disk X (Replace X with your Kingston SSD) list partition select partition Y (Replace Y with the EFI partition, if it exists) assign letter=Z exit
  4. Now rebuild the bootloader: bcdboot C:\Windows /s Z: /f UEFI
  5. Restart the computer and remove the M.2 SATA drive.

🔄 Step 4: Try Booting Without M.2 SATA

  1. Shut down and physically remove the M.2 SATA drive.
  2. Boot into BIOS and confirm Kingston SSD is the primary boot device.
  3. Save changes and restart.

✅ Expected Result

  • If successful, your system should boot directly from Kingston SSD without the M.2 drive.
  • If it still boots to BIOS, check if your Kingston SSD is recognized in BIOS.

Let me know if this works or if you need more troubleshooting! 🚀

DHCP Failover with Pi-hole

I

Let’s get that Pi-hole DHCP reservation syncing set up! I’ll walk you through creating a sync script to keep the DHCP reservations (and any other Pi-hole configurations) identical between your Proxmox VM and Raspberry Pi 4. Here’s how we’ll do it!


Step 1: Set up SSH key-based authentication

To allow the Raspberry Pi to pull the DHCP config from the Proxmox VM without a password:

👉 On the Raspberry Pi 4, generate an SSH key (if you haven’t already):

ssh-keygen -t rsa -b 4096 -C "pi-hole-sync"

  • Press Enter to save it to the default location (~/.ssh/id_rsa).
  • No passphrase is needed for this.

👉 Copy the key to your Proxmox Pi-hole VM:

ssh-copy-id <username>@<proxmox_vm_ip>

  • This allows the Raspberry Pi to SSH into the Proxmox VM without a password.

Step 2: Create the sync script

👉 On the Raspberry Pi, create a script (e.g., pi-hole-sync.sh):

#!/bin/bash

# Define variables
PRIMARY_PIHOLE="<proxmox_vm_ip>"
PIHOLE_CONFIG_DIR="/etc/dnsmasq.d"
LOCAL_BACKUP_DIR="/home/pi/pihole_backup"

# Create backup directory if it doesn't exist
mkdir -p $LOCAL_BACKUP_DIR

# Sync DHCP reservations and Pi-hole config files
rsync -avz --delete $PRIMARY_PIHOLE:$PIHOLE_CONFIG_DIR/ $LOCAL_BACKUP_DIR/
rsync -avz --delete $LOCAL_BACKUP_DIR/ $PIHOLE_CONFIG_DIR/

# Restart Pi-hole to apply changes
pihole restartdns

👉 Make the script executable:

chmod +x pi-hole-sync.sh


Step 3: Schedule automatic syncing with cron

👉 Open the crontab on the Raspberry Pi:

crontab -e

👉 Add a cron job to sync every 5 minutes (or whatever interval you prefer):

*/5 * * * * /path/to/pi-hole-sync.sh


Step 4: Test the setup

👉 Run the sync script manually to confirm it works:

./pi-hole-sync.sh

👉 Check the DHCP reservations on the Raspberry Pi Pi-hole to ensure they match the Proxmox VM.


Step 5: DHCP failover

👉 Now that both Pi-hole instances have the same DHCP reservations:

  • Set the Proxmox Pi-hole as the primary DHCP server.
  • Keep the Raspberry Pi Pi-hole DHCP disabled by default.
  • Use a failover script (as mentioned before) to detect when the primary goes down and enable DHCP on the Pi dynamically.

Final result:

  • DHCP reservations stay synced automatically.
  • No more IP conflicts or lost reservations during a failover!
  • Your network stays resilient even if the Proxmox node goes down.

👉 Let me know if you’d like to add monitoring or notifications to this — we can polish this home lab setup to perfection! 🚀

Failover Script

Let’s set that up! I’ll give you a failover script that’ll:
✅ Periodically check if the primary Pi-hole VM is online.
✅ Enable DHCP on the Raspberry Pi if the primary goes down.
✅ Disable DHCP on the Raspberry Pi when the primary comes back online.


Step 1: Create the failover script

👉 On the Raspberry Pi, create a new file:

nano /home/pi/dhcp-failover.sh

👉 Add the following code:

#!/bin/bash

# Primary Pi-hole VM IP address
PRIMARY_PIHOLE_IP="<proxmox_vm_ip>"

# Check if the primary Pi-hole is online
if ping -c 3 $PRIMARY_PIHOLE_IP &> /dev/null; then
    echo "$(date) - Primary Pi-hole is up."
    
    # Check if DHCP is running on the Pi - if so, disable it
    if pihole-FTL dhcp-discover | grep -q "Pi-hole DHCP server: active"; then
        echo "$(date) - Disabling DHCP on the Raspberry Pi (primary is up)."
        pihole disable-dhcp
    fi
else
    echo "$(date) - Primary Pi-hole is DOWN."
    
    # Check if DHCP is running on the Pi - if not, enable it
    if ! pihole-FTL dhcp-discover | grep -q "Pi-hole DHCP server: active"; then
        echo "$(date) - Enabling DHCP on the Raspberry Pi (primary is down)."
        pihole enable-dhcp
    fi
fi

✅ This script:

  • Pings the Proxmox Pi-hole VM.
  • Enables DHCP on the Pi-hole (Raspberry Pi) if the VM is unreachable.
  • Disables DHCP on the Pi-hole (Raspberry Pi) when the VM is back online.

👉 Save and exit the file (CTRL + X → Y → Enter).


Step 2: Make the script executable

chmod +x /home/pi/dhcp-failover.sh


Step 3: Set up a cron job for periodic checking

👉 Open the crontab:

crontab -e

👉 Add this line to check every 5 minutes:

*/5 * * * * /home/pi/dhcp-failover.sh >> /var/log/dhcp-failover.log 2>&1

✅ This logs the DHCP failover status to /var/log/dhcp-failover.log.


Step 4: Test the failover

👉 Run the script manually to verify it works:

/home/pi/dhcp-failover.sh

👉 Then, simulate a failure by shutting down the Proxmox Pi-hole VM and checking if the Raspberry Pi takes over DHCP.


Final result:

  • Primary Pi-hole VM on Proxmox runs DHCP under normal conditions.
  • Secondary Pi-hole (Raspberry Pi) automatically enables DHCP if the primary goes offline.
  • DHCP is disabled again when the primary comes back online — no IP conflicts, just smooth failover!

👉 Let me know if you want to add email alerts or system monitoring to this! 🚀

Data Backup on a Budget

I have a lot of data that I’d hate to lose. Anyone with a hard drive failure really appreciates the value of having another copy of the lost data. I suppose cloud storage would be a logical place to backup data. With all my personal audio and video files, I might need as much as 10 TB of storage. That would be too expensive for me. My strategy has been to buy enough USB external hard drives to keep two copies of all my data. This has always been a manual process. I am working to automate my backup processes.

There are a couple of options when syncing two file directories. One is to simply copy all new files from the source to the target. Another is to additionally remove all the files from the target that have been removed from the source. I’ll automate the first procedure. If you accidentally remove all files from the source, the second procedure will also remove all files from the target. This option will only be used manually and very carefully.

Personal Documents

stub…

Audio, Video and Pictures

stub…

Duplicate Files

stub…

Server Backups

stub…

Rsync (ChatGPT)

I have three external USB drives: 4 TB, 5 TB, and 12 TB

You can use the following rsync command to synchronize the /documents directory from fileserver1 to fileserver2, ensuring that extra files on fileserver2 are removed:

rsync -av --delete fileserver1:/documents/ fileserver2:/documents/

Explanation of Options:

  • -a → Archive mode (preserves permissions, timestamps, symbolic links, etc.).
  • -v → Verbose output (optional, shows progress).
  • --delete → Removes extra files on fileserver2 that are not present on fileserver1.
  • The trailing / after /documents/ ensures correct directory syncing.

Additional Options (If Needed):

  • Dry run before actual execution (to preview changes): rsync -av --delete --dry-run fileserver1:/documents/ fileserver2:/documents/
  • Use SSH for secure transfer (if servers are remote): rsync -av --delete -e ssh fileserver1:/documents/ fileserver2:/documents/
  • Limit bandwidth to avoid overloading network (e.g., limit to 5MB/s): rsync -av --delete --bwlimit=5000 fileserver1:/documents/ fileserver2:/documents/

You can automate the rsync synchronization using a cron job.

Step 1: Edit the Crontab

On fileserver1, open the crontab editor:

crontab -e

Step 2: Add the Rsync Command

Add the following line to schedule synchronization every day at 2 AM:

0 2 * * * rsync -av --delete fileserver1:/documents/ fileserver2:/documents/ >> /var/log/rsync.log 2>&1

This will:

  • Run rsync at 2:00 AM daily.
  • Log output to /var/log/rsync.log for debugging.

Step 3: Save and Exit

Save the file and exit the editor.

Step 4: Verify the Cron Job

After a day, check if the job ran:

cat /var/log/rsync.log

Would you like email notifications for failures?

Robocopy

stub…

Samba Setup (ChatGPT)

This is a copy and paste from ChatGPT (https://chatgpt.com/share/677bd14a-ef84-8002-93fc-b3456d8a9df8). The formatting and loss of copy buttons is a problem.

Setting up a file server on Ubuntu using an external USB drive is a straightforward process. Here’s a step-by-step guide:


1. Prepare Your USB Drive

  1. Plug in the USB Drive: Connect the external USB drive to your Ubuntu machine.
  2. Identify the Drive: Open a terminal and run:bashCopy codelsblk Find the USB drive in the list. It will likely be named something like /dev/sdX (e.g., /dev/sdb1).
  3. Format the Drive (if needed): If the USB drive isn’t already formatted, format it with a suitable file system (e.g., ext4 for Linux systems):bashCopy codesudo mkfs.ext4 /dev/sdX1 Replace /dev/sdX1 with your USB drive’s identifier.
  4. Create a Mount Point:bashCopy codesudo mkdir /mnt/usb
  5. Mount the Drive:bashCopy codesudo mount /dev/sdX1 /mnt/usb Add the drive to /etc/fstab for automatic mounting:bashCopy codeecho "/dev/sdX1 /mnt/usb ext4 defaults 0 0" | sudo tee -a /etc/fstab

2. Install and Configure Samba (File Sharing for Windows/Linux)

  1. Install Samba:bashCopy codesudo apt update sudo apt install samba -y
  2. Configure Samba: Open the Samba configuration file:bashCopy codesudo nano /etc/samba/smb.conf Add a shared folder configuration at the end:iniCopy code[USB_Share] path = /mnt/usb read only = no browsable = yes writable = yes guest ok = no valid users = your_username
  3. Set Samba User: Add your user to Samba:bashCopy codesudo smbpasswd -a your_username
  4. Restart Samba Service:bashCopy codesudo systemctl restart smbd

3. Configure Permissions

Ensure your user has ownership of the USB mount point:

bashCopy codesudo chown -R your_username:your_username /mnt/usb

4. Access the File Server

  • From Linux: Use the smb:// protocol in your file manager.
  • From Windows:
    • Open the File Explorer.
    • Type \\<Ubuntu_IP_Address>\USB_Share in the address bar.
    • Enter your Samba username and password.

Optional: Install and Configure NFS (for Linux Sharing)

If you prefer NFS for Linux clients:

  1. Install the NFS server:bashCopy codesudo apt install nfs-kernel-server -y
  2. Edit the export file:bashCopy codesudo nano /etc/exports Add:plaintextCopy code/mnt/usb *(rw,sync,no_subtree_check)
  3. Restart the NFS service:bashCopy codesudo systemctl restart nfs-kernel-server