If you look at most OTT architecture diagrams, they look clean, linear, and reassuring.

Real live streaming systems are none of those things.

At scale especially in India , live streaming is not a video problem. It’s a distributed systems chaos management problem with video as payload.

Your real enemies are:

• Sudden concurrency spikes

• Control plane overload

• Cost explosions at the Content Delivery Network layer

• Ad pipeline latency

• DRM bottlenecks nobody load tests properly

If your system survives a normal day, congratulations.
If it survives India vs Pakistan final overs — now you’re running a real platform.

The Only Mental Model That Matters

At scale, every streaming platform ends up optimizing three axes:

You only get to optimize two.

Anyone promising all three is either:

• Pre-scale

• Hiding cost numbers

• Or not running live events yet

What the Real Stack Looks Like (From an Operator’s POV)

Forget marketing diagrams. | Video rarely kills you. | Control plane almost always does.

Real stack layers behave like blast zones:

Example 1: JioHotstar ~ Built For Stampede Traffic, Not Average Load

Figure 1. JioHotstar Stream Stack (bundled from sources) Reference →

The hardest engineering problem in India streaming isn’t sustained throughput. It’s instantaneous concurrency spikes.

During cricket:

• Millions join within seconds

• Session auth spikes

• Manifest requests spike

• Telemetry pipelines flood

If you don’t isolate control plane early, you die early.

Event Streaming Everywhere (Kafka-Class Backbone)

For survival ….

You want:

• Playback telemetry

• Session state propagation

• Real-time autoscaling signals

The real engineering problem:
Hot partitions during single match IDs. ??? If you didn’t simulate “everyone refreshes app during wicket replay”, you’re already in trouble.

Memory-First State (Redis / In-Memory Grid)

Good for:

• Live state fanout

• Session acceleration

• Personalization signals

Hidden risk:
Cluster rebalance during peak = cascading latency storm.

Multi-Content Delivery Network Aggressive Routing

Especially critical in India where last-mile ISP variability is extreme. Tradeoff:
More routing logic = more control plane complexity.

Example 2: Netflix ~ The "Cinema in Your Neighborhood"

Figure 2. Netflix Tech Stack Source→

Netflix’s biggest architectural win wasn’t just encoding AV1 -> .

It was supply chain. They moved storage + delivery inside ISP networks.

That changes everything:

• Transit cost drops massively

• Latency stabilizes

• Fewer BGP(routing protocol) surprises

Netflix operates its proprietary Open Connect CDN, which delivers 100% of video traffic through over 8,000 appliances deployed in close to 1,000 locations worldwide. Source→

In India, Netflix has strategically placed Open Connect Appliances within ISP networks to minimize transit costs and improve streaming quality.

Why This Doesn’t Fully Solve Live Sports

Live is unpredictable. You cannot pre-cache future segments.

So live success depends more on:

• Encoder redundancy

• Packaging region failover

• Manifest service resilience

Not CDN strength alone.

Example 3: Amazon Prime Video ~ The Ultra-Reliable "Always-On" Machine

Figure 3. Amazon Prime Stack Source→

If JioHotstar is a stadium and Netflix is a neighborhood cinema, Amazon Prime Video is the mission-critical infrastructure designed to never fail. Prime Video’s goal is "Five Nines" (99.999%) reliability, meaning less than 26 seconds of downtime per month.

• AWS Elemental Power: They leverage a specialized suite of tools:

  • MediaConnect: Ingests the raw feed securely.

  • MediaLive: Encodes the video into multiple quality levels in real-time.

  • MediaPackage: Prepares the video for every possible device, from a 4K TV to an old smartphone.

• Dedicated Highways: They use Direct Connect and Transit Gateways to create private, high-speed "highways" between the live event (like an NFL stadium) and the AWS cloud, bypassing the messy public internet entirely.

Dedicated Media Pipeline = Predictability

General compute works until: Encoder jitter appears, Kernel noise hits real-time workloads , Shared network bursts happen . Dedicated media services trade cost for deterministic behavior. At scale, determinism is cheaper than chaos.

Most teams scale video delivery, but very few scale license servers properly. DRM outages cause “video loads but doesn’t play” , Which users interpret as: “Platform is broken.”

Example 4: Zee5 ~ The Cost-Efficient Kitchen

Figure 4. Zee5 (Bundled from sources) Zee5→

Zee5 has optimized the "cooking" process to handle India’s diverse mobile landscape.

• Custom Transcoding: They moved away from generic tools to build an In-house Transcoder on Google Cloud.

• Hybrid Cloud: By mixing AWS and GCP via high-speed private links, they’ve reduced file sizes. This means cheaper data for users and faster load times on budget smartphones.

!! Margin Makes money !!

In the high-stakes world of streaming, optimizing the "kitchen" is a matter of financial survival; shaving just 5–8% off your bitrate without compromising visual quality can translate into millions of dollars in annual savings on CDN and delivery costs. This "stakeholder survival math" is what drives platforms like Zee5 to build custom in-house transcoders that prioritize mobile-first efficiency over generic cloud solutions.

Example 5: SonyLIV ~ The Interaction Engine

Figure 5. SonyLIV Stack (Bundled from sources) source→

SonyLIV focuses on how to make every second of a stream interactive and profitable.

• Seamless Ads: They use Server-Side Ad Insertion (SSAI). Instead of the app "pausing" for an ad, the ad is stitched directly into the video stream. No stutter, no "Ad Loading" screens.

• Live Engagement: Using a real-time layer like Lightstreamer, they push live polls and quizzes to millions of fans simultaneously without disturbing the video feed.

Key Takeaways: The Streaming Strategy Matrix

• JioHotstar (Scalability First): Built to survive massive, sudden traffic spikes by using Apache Kafka to decouple systems and a Multi-CDN strategy to ensure no single point of failure during national events.

• Netflix (Quality First): Invests heavily in Edge Computing through the Open Connect program, moving content inside the ISP's network to eliminate latency and provide a premium 4K experience.

• Zee5 (Efficiency First): Focuses on Cost-Optimization and mobile performance by leveraging a custom, in-house transcoder on a hybrid cloud setup (AWS and Google Cloud).

• SonyLIV (Engagement First): Prioritizes Monetization and Interactivity through Server-Side Ad Insertion (SSAI) and real-time messaging layers that keep fans engaged without breaking the stream.

• Amazon Prime (Reliability First): Implements Multi-Region Redundancy using the AWS Elemental suite, ensuring that if one entire geographic region fails, a second one is already running to pick up the slack.

Act 1: The Problem with Old‑School Virtualization

• The old setup had one big hypervisor doing everything: run VMs, push packets, feed disks, and keep bad actors out. Think of a waiter who must cook, serve, wash dishes, and guard the door all at once. It worked, but it slowed down when the restaurant got busy.

Figure 1 . VMware Esxi Architecture (Type 1 hypervisor)

• Performance overhead and scalability pain: The hypervisor handled networking, storage, and security, eating CPU cycles that should have powered the app.

• The cloud couldn’t scale like this. The answer wasn’t a tweak. The answer was to break the problem apart and rebuild it. Here’s how it was done.

Act 2: The Solutions – The In‑House Beasts

Chapter 1: AWS – The Radical Hardware Revolution (Nitro)

Story arc:
AWS didn’t just tune a hypervisor; it broke the whole thing into pieces and pushed the heavy lifting into custom cards, leaving a tiny layer to guard CPU and memory. Think of a kitchen where the chef only cooks while robots handle delivery, dishwashing, and the door.

The how:

• Networking offload: A Nitro card takes over VPC networking, so packets don’t steal host CPU time.

• Storage offload: Another Nitro card handles EBS and local NVMe I/O, keeping reads/writes fast and steady.

• System control + security: A controller and a security chip own secure boot, firmware trust, and management APIs, so the host where apps run stays sealed off.

• Minimal hypervisor: A lightweight, KVM‑based layer handles just compute and memory isolation—nothing extra.

Figure 2 . AWS Nitro Link

Chapter 2: Google Cloud – The KVM Mastermind (with a Titanium Heart)

Story arc:
Google kept KVM at the core, then armored it and gave it a new bodyguard: Titanium—a smart offload layer on the host and across the data‑center fabric.

The how:

• Hardened KVM on the host keeps VMs isolated and tight.

• Titanium on‑host offload (think IPU/DPU) takes over packet paths and block I/O so the CPU can focus on apps.

• A second tier of scale‑out offloads spreads work across Google’s fabric—Hyperdisk teams up with Colossus to push huge IOPS without upsizing compute.

“The control plane dynamically detects flows that exceed a specified usage threshold and programs them to be direct host‑to‑host flows… allowing offload systems to focus on the long tail.”
Source

Figure 3. Titanium Offload Block Diagram (simplified) and 4. Titanium in-action

Chapter 3: Microsoft Azure – The Enterprise Champion’s Proven Path

Story arc:
Azure leaned into its strength: Hyper‑V. It refined a design enterprises know well—parent partition in charge, child partitions for VMs—and made the pathways between them fast and clean.

The how:

• A parent partition owns the hardware and offers services.

• Child partitions run the VMs.

• They talk over VMBus—high‑speed channels that cut out slow device emulation. Drivers that “know” they’re virtual make it even faster.

Top: “Parent Partition (devices + management)”
Below: “Child Partition (VM)” × N
Arrows: “VMBus” between parent and each child

Act 3: The Final Verdict – The Silent Race Continues 🏁

One‑line scoreboard:

• Performance: Offload wins. Nitro and Titanium move I/O away from the host CPU; VMBus keeps Azure’s path lean for Windows‑heavy stacks.

• Security posture: Minimal host access and hardware roots of trust are the norm—AWS locks down hosts; Google adds isolation via offload tiers; Hyper‑V enforces strict partition boundaries.

• Flexibility: Google’s scale‑out offloads let storage and network scale without resizing compute; AWS keeps shipping new instance types; Azure shines in hybrid cohesion.

Closing shot:
This race is quiet, but it powers the internet. Every new offload, tighter lock, and faster data path makes apps snappier and safer—from a single startup to the world’s biggest enterprises. The finish line keeps moving with each new card, bus, and silicon upgrade.

This article is all about how I solved that problem. We'll look at why a simple solution isn't always the best and then dive into the tool that made my life so much easier.

The Problem with Port Forwarding

When I first started, my initial thought was simple: just open a port on my home router and point it to my homelab's IP address. This is called port forwarding. In theory, it works, allowing external traffic to bypass the router and reach a specific device on your internal network.

However, I quickly learned this is a terrible idea. Opening a port on your router is like leaving the front door to your house wide open. It exposes your homelab and potentially your entire home network to the internet. This makes it a prime target for hackers and malicious bots that are constantly scanning for vulnerabilities.

The Solution: A Secure Tunnel

The answer to this problem is a Virtual Private Network (VPN). Think of a VPN as a private, encrypted tunnel through the public internet. It allows your devices to communicate with your homelab as if they were on the same local network, even when they're miles apart. This keeps your connection private and secure, as no one can see what's happening inside the tunnel.

Traditionally, setting up a VPN server can be complicated. You'd need to configure a server on your homelab with something like OpenVPN or WireGuard, manage certificates and keys for each device, and deal with complex firewall rules. As a beginner, this felt like a huge obstacle.

The Game-Changer: Tailscale

Then I found Tailscale. It completely changed the game for me. Tailscale is a mesh VPN service that builds on the WireGuard protocol but makes the setup incredibly simple. It creates a private network that securely connects all your devices—laptops, phones, servers—regardless of their location.

Here’s how it works:

1. Install Tailscale on each device. I installed it on my homelab server, my laptop, and my phone.

2. Log in with the same account. As soon as each device logs in, they all become part of the same private Tailscale network.

3. Done! That’s it. There's no need to configure complex firewall rules or mess with router settings.

Figure . V P N

With Tailscale, I can access my homelab server from my hostel as if it were sitting right next to me. I can securely SSH into my server, connect to my VS Code Server instance, and even access my self-hosted services using their private Tailscale IP addresses. It’s all seamless, secure, and incredibly easy.

For a beginner like me, Tailscale was a godsend. It removed the biggest barrier to remote access and allowed me to get straight to the fun part of using my homelab. And it helps me reduce complexity to access my node in my parent’s home.

The Power of VS Code Server

My coding journey revolves around Visual Studio Code (except CMake). It's a fantastic editor, and the best part is that I don't need to run it on my laptop. Instead, I installed VS Code Server on my homelab server. Once it was installed, I could access it through a web browser on any of my devices—my laptop, my phone, or even the old desktop at home.

Although i am in trail phase , the experience is seamless. It feels exactly like the desktop version of VS Code, with all my familiar themes and extensions already there. I can open my code files, run terminal commands, and debug my programs from anywhere. All the heavy lifting, like compiling large projects or running tests, is done on my powerful Dell workstation, so my old laptop stays cool and quiet.

JupyterLab for Data Science and Learning

After working with cloud platforms like Google Cloud Platform's Vertex AI Workbench and Google Colab, I've grown incredibly comfortable with their interactive environments. They've become my go-to for all my coursework, especially for data science and machine learning projects. I love how these tools let me write and run code, visualize data, and create documentation all in one place.

The biggest challenge I faced early on was managing dependencies. Different projects require different versions of Python libraries, and I quickly ran into what people call "dependency hell." The solution? Conda. I created multiple Python environments, each with its own set of libraries for specific projects. For instance, I have one environment for a machine learning project using TensorFlow and another for a data analysis project using Pandas and NumPy. This simple setup has saved me from countless headaches.

Image 1. Locally Hosted JupterLab (example code)

The Ultimate Hybrid Workflow: Google Colab + Local Runtime

Here's a cool trick I discovered that has been a game-changer for me. I can connect Google Colab to my local JupyterLab runtime. This gives me the best of both worlds: the familiar and powerful Google Colab interface, but with all the processing power and storage of my homelab. It's perfect for when I want to use Google's features while keeping my data and computations on my own hardware.

Image 2. Local Runtime connected

My pro tips for a remote coding setup:

• Always use virtual environments. Whether it's Conda or venv, isolating project dependencies will save you a world of pain.

• Invest in a good internet connection. My 40 Mbps downstream is more than enough for a smooth remote coding experience.

• Version control is your best friend. Get into the habit of using Git for all your projects, even the small ones.

le fond : A Repurposed Workstation

When I decided to build a homelab, I didn't want to buy a new server(money!!). Instead, I opted to repurpose a powerful workstation I found. My main server is a Dell Precision 7910. It’s a beast of a machine, and for me, that power is what makes this lab work.

The specs are overkill for a beginner, but that's exactly what I wanted. This machine has two Intel Xeon E5-2673 v4 CPUs, giving me a massive 40 cores and 80 threads to play with. This allows me to run multiple virtual machines and containers without a hitch. I've also got 64GB of RAM and a combination of a 512GB SSD for my operating systems and a 2TB HDD for general storage. With space for future expansion with 8+ drive bays, 4 PCIe4 x8 Slots and 1300 W of Power Supply with upto 1TB RAM . With all the Virtualization and Remote MAGIC .

To protect this valuable machine and my data, I have a Schneider APC 1100 VA UPS. Best Purchase as for frequent power cut in my area .

Image . Workstation

The Network Backbone

A good homelab is built on a solid network, even a simple one. My setup begins with my Airtel ISP router. It provides me with fast internet—I get around 45 Mbps upstream and 40 Mbps downstream with a 1 Gbps router.

From there, my devices are connected to a simple D-Link DGS-1008A 8-port switch. This is an unmanaged switch, which means it's incredibly simple and just works. It acts like a network power strip, allowing me to connect all my wired devices without any complicated configuration as i only have 1 LAN port on my ISP router.

Figure . Simplified Network Diagram

The Software and Virtualization Layer

For my lab, I chose Proxmox Virtual Environment as my hypervisor. I picked it because it’s free and offers a fantastic web interface that makes managing my virtual machines a breeze.

Within Proxmox, my primary server is an Ubuntu Server 22.04 VM. It's where I host my VS Code Server and JupyterLab for remote coding. and most of the current projects . I'm also using my lab as a learning sandbox; I'm even running a separate ESXi VM within Proxmox to learn about different virtualization platforms without needing dedicated hardware.

Image . Proxmox Dashboard

Storage, Backups, and Other Devices

When it comes to storage and data protection, my approach is simple and honest. I don't have a RAID setup because I don't have a lot of mission-critical data. If a drive fails, I'll just replace it and start over. For important files, I have a simple backup strategy: I periodically back up my critical VMs to my laptop and create weekly snapshots of key data to Google Cloud Storage.

Figure . Backup Flow Diagram

In addition to my main workstation, I also have a Dell Inspiron 3505 laptop as my daily driver. It has a Ryzen 3 CPU, 16GB of RAM, a 512GB SSD, and a 1TB HDD. I use it for daily tasks and as a backup location for my homelab. I also have an older i5 6th gen system with 8GB of RAM and a 2TB HDD running Linux Mint at my home, which I'll discuss in a future article on remote networking.

That’s a wrap on the hardware that powers my homelab although very small. In the next article, I'll show you how I've configured my systems to create a powerful remote coding environment using VS Code Server and JupyterLab. Stay tuned!

• Hero stats:

  • <200 ms cached replies

  • 10k+ concurrent users

  • 95%+ recommendation accuracy (stress‑tested in production)

• Engineered for scale: microservices, Gemini 2.5 Pro multi‑model, and a polyglot data layer tuned for retail .That can serve on all platform : shopping platform, kisosk and as standalone chatbot app .

User Pain Hold and Why this Problem Statement :

The user pain is clear: keyword boxes and endless catalogs slow decisions, especially in‑aisle where price, diet, and local stock all collide; expectations set by Amazon’s constant tech leaps demand effortless, guided discovery, so Walmart must turn its unmatched offline footprint into a digital advantage.

This problem statement targets that gap: a lightweight assistant that elevates the in‑store experience for shoppers and a companion extension for associates speeding availability checks, suggesting substitutes, and accelerating pick/pack reducing abandonment while converting Walmart’s physical scale into a durable edge.

System at a Glance :

Figure 1. System Architecture Tool Used→

Figure 2. Data Flow Diagram

How it works (in 5 beats) :

• Intent lock: Domain prompts route queries to “search, compare, refine” with schema‑locked tools.

• Dual‑tier routing: Tier 1 handles the essentials instantly; Tier 2 adds availability, alternatives, and trends when context demands.

• Search + semantics: Typesense narrows fast; Qdrant re‑ranks by meaning and visuals; fused for precision.

• Reality check: Live inventory and regional pricing blend into the final rank so answers match shelf truth.

• Personal touch: Profile, behavior, and store affinity shape a personalization score alongside relevance.

User Experience:

Figure 3. User Flow Diagram

Start with scan, snap, ask: users scan a shelf QR/tag, snap an item photo, or speak/type “gluten‑free cereal under INR 100 near 75001,” the assistant locks intent and fires Tier 1 search to filter by price and diet, fuses semantic matches via Typesense and Qdrant, escalates to Tier 2 for live availability, pickup/delivery and nearest‑store distance, then returns a tight “Your Smart Picks” panel with the best option (₹85), why‑this choice, and healthier alternatives—one smooth, real‑time glide from question to add‑to‑cart .

Lesson Learned :

• Accuracy and Relevance: We fixed hallucinations and relevance issues by using a hybrid search approach (Typesense + Qdrant re-ranking) and ensuring that all responses are grounded in real data, with built-in retries for failures.

• Latency and Efficiency: We dramatically reduced latency spikes by implementing parallel processing, short-term caching, and setting strict time limits for each step. We also managed token costs by using a lower model temperature and compressing memory.

Part of the Proxmox Baremetal Journey series

I wanted to make my Proxmox homelab more secure and flexible by using Tailscale on an Ubuntu 22.04 LXC container. The end goal: turn the LXC into a subnet router and exit node for my entire Tailscale network. And later add IDS/IPS for experimentation. This post documents the steps to install and set-up tailscale.

Think of this as both a how-to guide and a "learn from my setup journey" story.

1. Preparing the LXC in Proxmox

When creating your container in Proxmox, you’ll need to enable nesting and ensure the tun device is available.

Here is my config : /etc/pve/lxc/100.conf (for container CT100):

arch: amd64
cores: 2
features: nesting=1
hostname: CT100
memory: 512
net0: name=eth0,bridge=vmbr0,hwaddr=BC:24:11:58:98:29,ip=dhcp,type=veth
rootfs: local-lvm:vm-100-disk-0,size=8G
swap: 512
unprivileged: 1
lxc.cgroup2.devices.allow: c 10:200 rwm
lxc.mount.entry: /dev/net/tun dev/net/tun none bind,create=file

2. Configure Netplan for Networking

Inside the container, set up DHCP with Netplan:

nano /etc/netplan/50-cloud-init.yaml

network:
  version: 2
  ethernets:
    eth0:
      dhcp4: true

Apply changes:

sudo netplan apply

Verify IP:

ip a

Screenshot of IP output:

Screenshot of netplan config:

3. Install Tailscale

Follow the official guide:

curl -fsSL https://tailscale.com/install.sh | sh

Bring Tailscale up:

sudo tailscale up

A browser window will open asking to connect your device.

Tailscale auth screen:

4. Enable Subnet Routing & Exit Node

Advertise your container as an exit node:

sudo tailscale up --advertise-exit-node

Or to route your LAN subnet:

sudo tailscale up --advertise-routes=<>

Approve routes in the Tailscale admin console.

5. Using the LXC as Exit Node

On another Tailscale device, set the container as your exit node:

sudo tailscale up --exit-node=<LXC_IP>

Replace <LXC_IP> with the container’s Tailscale or LAN IP.

6. Handling Key Expiry

By default, Tailscale auth keys expire. If you need reusable or long-lived keys, check Key Expiry Docs.

Generate and use reusable keys for automation.

Takeaways

• Nesting + tun device are required in the LXC config.

• Netplan must be configured with DHCP.

• Tailscale can easily advertise routes and exit node.

• Keys expire unless replaced with reusable ones.

With this setup, my Proxmox-hosted LXC is now a fully functioning VPN gateway + exit node for my Tailscale network.

I broke my install more times than I'd like to admit, but by the end I learned a ton about how PBS works under the hood. This post documents everything I learned while setting up Proxmox Backup Server to help others avoid my mistakes and establish production-level workflows.

Think of this as both a how-to guide and a "don't make my mistakes" story.

🔧 What Went Wrong (And How I Fixed It)

PBS is very strict about ownership and permissions. If they're wrong, nothing works. Here are the main traps I fell into:

Permission Issue #1 → The proxmox-backup directory was owned by root:root. PBS needs it owned by backup:backup.

Permission Issue #2 → I used 755 for the config directory. PBS requires 700.

Permission Issue #3 → My datastore subdirectories weren't owned by backup:backup. That blocked PBS from creating the crucial .chunks directory.

🛠 Clean Installation Guide

1. Update & Prepare System

sudo apt update && sudo apt upgrade -y
sudo apt install curl wget gnupg lsb-release apt-transport-https -y

2. Add the Proxmox Repository

echo "deb http://download.proxmox.com/debian/pbs bookworm pbs-no-subscription" | sudo tee /etc/apt/sources.list.d/pbs.list
wget -qO- http://download.proxmox.com/debian/proxmox-release-bookworm.gpg | sudo gpg --dearmor -o /etc/apt/trusted.gpg.d/proxmox-release-bookworm.gpg

3. Fix GPG Key Issues (if needed)

sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 1140AF8F639E0C39
sudo apt update

4. Remove Old Packages (for a fresh reinstall)

sudo apt-get purge proxmox-backup proxmox-backup-client proxmox-backup-docs proxmox-backup-server -y
sudo apt-get purge proxmox-kernel-* proxmox-default-kernel -y
sudo rm -rf /etc/proxmox-backup /etc/systemd/system/proxmox-backup*
sudo rm -rf /mnt/pbs_backup/*

5. Install PBS

sudo apt install proxmox-backup-server -y

6. Create Datastore Directory

sudo mkdir -p /mnt/pbs_backup/datastore1

7. Fix Permissions

# Datastore ownership
sudo chown -R backup:backup /mnt/pbs_backup/datastore1

# Create and secure PBS config directory 
sudo mkdir -p /etc/proxmox-backup
sudo chown -R backup:backup /etc/proxmox-backup
sudo chmod 700 /etc/proxmox-backup

# Manually create .chunks directory (if PBS doesn't create it automatically)
sudo -u backup mkdir -p /mnt/pbs_backup/datastore1/.chunks

8. Start PBS Services

sudo systemctl start proxmox-backup
sudo systemctl enable proxmox-backup
sudo systemctl start proxmox-backup-proxy
sudo systemctl enable proxmox-backup-proxy

📘 Key Takeaways

Permissions are critical:

• /etc/proxmox-backup → must be backup:backup with 700
• Datastores → must be backup:backup so PBS can create .chunks

Two services must run:

• proxmox-backup → API server
• proxmox-backup-proxy → Web interface

Troubleshooting Tips

If you encounter issues, check these common points:

1. Verify service status: sudo systemctl status proxmox-backup proxmox-backup-proxy

2. Check permissions: ls -la /etc/proxmox-backup and ls -la /mnt/pbs_backup/datastore1

3. Review logs: sudo journalctl -u proxmox-backup -f

Remember: when in doubt, proper permissions are usually the answer with PBS.