How to Install Duplicati in an LXC Container on Proxmox VE (Encrypted Backups for Your Files and Documents)

Introduction

Most Proxmox backup guides are really about protecting the VM or container as a whole — the disk image, the config, the works. That's what vzdump and Proxmox Backup Server are for, and they're good at it. But that's not always the problem you're actually trying to solve.

Say you've got a Nextcloud VM with a folder of tax documents, or a Windows VM with a "Photos" folder you'd genuinely be upset to lose. Restoring the entire 40 GB VM just to pull out one folder is overkill, and it doesn't give you an encrypted, off-site copy of just the stuff that actually matters to you. That's a different job, and it calls for a different tool.

Duplicati is built for exactly that job: picking specific files and folders, encrypting them, and shipping them off to cloud storage on a schedule. This guide walks through installing it in its own lightweight LXC container on Proxmox VE, so it runs independently of whatever it's backing up. We're working from Proxmox VE 9.2 (Debian 13.5 "Trixie" underneath) and Duplicati 2.3.0.4.

What You Will Learn

• What Duplicati actually does, and how it's different from vzdump or Proxmox Backup Server
• How to create a small, dedicated LXC container for it
• How to install the current stable release from the official .deb package
• How to reach files that live outside the container using a bind mount
• How to set up your first encrypted backup job, step by step
• The errors people run into most often, and what actually causes them
• A few habits that'll save you from a backup you can't restore later

What Is This Feature?

Duplicati is a free, open-source backup application that copies files and folders you choose to a storage destination of your choice — Backblaze B2, Amazon S3, an SFTP server, a WebDAV share, Google Drive, or even a plain local folder. Everything gets encrypted with AES-256 (or GPG, if you'd rather) before it leaves the machine, and only incremental changes get uploaded after the first run.

An LXC container is Proxmox VE's lightweight alternative to a full virtual machine. Instead of emulating hardware and booting a separate kernel, it shares the host's Linux kernel and just isolates the processes and filesystem inside. That makes it start in a couple of seconds and use a fraction of the RAM a VM would need — which is exactly what you want for a background service like Duplicati that just sits there watching the clock.

It's worth being blunt about where Duplicati sits next to the tools Proxmox already gives you:

They're not competing tools. Plenty of homelab setups run vzdump for the VMs and Duplicati for the handful of folders inside those VMs that would actually hurt to lose.

Why Would You Use It?

The honest answer is: you probably don't need this for everything. If losing a VM just means reinstalling Ubuntu and reconfiguring a service, vzdump has you covered. Duplicati earns its place when there's data inside a VM or container that vzdump backs up as a side effect but that you actually want dedicated, encrypted, off-site protection for — documents, photos, a database dump, a folder of configs you hand-edited over the years.

A few situations where it genuinely helps:

• You want an off-site copy that survives the whole Proxmox host dying, fire-and-flood included, without paying for a second full-sized backup server
• The data you care about is spread across several VMs and containers, and you'd rather back it up centrally than configure PBS agents everywhere
• You want the backup encrypted before it ever leaves your network, with a passphrase only you hold
• You're already paying for cheap object storage like Backblaze B2 and want to put it to use for something other than media files

I'll say it plainly: if all you want is "back up my VMs," stop here and go set up vzdump or PBS instead — they're simpler for that specific job. Duplicati is for the layer underneath it.

Prerequisites

Before you start, make sure you've got:

• A working Proxmox VE 8.x or 9.x host with a bit of free storage for a new container
• A Debian 13 (or 12) LXC template downloaded — from the Proxmox web UI, go to your storage, open CT Templates, and download it if it isn't there already
• Root or sudo access, either through the Proxmox shell or SSH
• A destination to back up to: a Backblaze B2 bucket, an S3-compatible bucket, an SFTP server, or even just another disk if you're testing first
• Roughly 10 minutes and about 4 GB of free disk space for the container itself

You don't need any Proxmox subscription tier for this. It works exactly the same on the free, no-subscription install.

Step-by-Step Tutorial

1. Create the LXC container

In the Proxmox web UI, click Create CT in the top right. Give it a hostname like duplicati, set a root password, and pick your downloaded Debian 13 template. For resources, 1 CPU core, 1024 MB of RAM, and a 4 GB disk is comfortable for backing up a modest amount of data — bump the RAM up later if you're backing up very large folders, since Duplicati builds file indexes in memory while scanning.

Leave networking on DHCP unless your setup needs a static IP, and finish the wizard. If you'd rather do this from the shell, the equivalent command is:

pct create 115 local:vztmpl/debian-13-standard_13.5-1_amd64.tar.zst \
  --hostname duplicati --cores 1 --memory 1024 --swap 512 \
  --rootfs local-lvm:4 --net0 name=eth0,bridge=vmbr0,ip=dhcp \
  --unprivileged 1 --start 1

Swap 115 for whatever container ID is free on your node, and adjust the storage names (local, local-lvm) to match your own setup.

2. Give it access to the files you want to back up

If the folder you want backed up lives on the Proxmox host itself — say, a directory on an NFS share you've already mounted there — you can expose it to the container with a bind mount instead of copying anything. Stop the container first, then run:

pct set 115 -mp0 /mnt/nas-documents,mp=/mnt/documents

That maps /mnt/nas-documents on the Proxmox host to /mnt/documents inside the container, read and write. If the data instead lives inside another VM, you'll need to reach it over the network from within the container — an NFS or SMB mount works fine — since a bind mount only works for things already visible on the host.

3. Start the container and update it

pct start 115
pct enter 115
apt update && apt full-upgrade -y

Give it a minute if it just booted — DHCP can take a few seconds to hand out an address.

4. Download and install Duplicati

Duplicati ships as a signed .deb package on its GitHub releases page rather than through the Debian repositories. Grab the current stable GUI build:

apt install -y curl
curl -LO https://github.com/duplicati/duplicati/releases/download/v2.3.0.4_stable_2026-07-09/duplicati-2.3.0.4_stable_2026-07-09-linux-amd64-gui.deb
apt install -y ./duplicati-2.3.0.4_stable_2026-07-09-linux-amd64-gui.deb

Using apt install ./file.deb instead of dpkg -i matters here — apt will pull in any missing dependencies automatically, where dpkg would just fail and leave you fixing them by hand.

5. Enable and start the service

systemctl enable --now duplicati

Check it actually came up before moving on:

systemctl status duplicati

You're looking for active (running) in green. If it says failed, jump ahead to the Common Errors section below.

6. Open the web interface

Find the container's IP address:

hostname -I

Then, from a browser on your network, go to http://<container-ip>:8200. Duplicati's setup wizard opens on first load, and you'll land straight on the main dashboard.

Do this next part before anything else: open Settings and set a login password. By default, anyone who can reach port 8200 on your network gets full access to your backup configuration, encryption settings and all. Takes ten seconds, and you should not skip it.

7. Create your first backup job

Click Add backup and work through the wizard:

• General — give the job a name, and set an encryption passphrase. Write this down somewhere outside Duplicati itself; there's no "forgot password" option for encrypted backups.
• Destination — pick where it goes. For Backblaze B2, you'll need a bucket name and an application key with read/write access to that bucket specifically, not your master account key.
• Source Data — select the folders to back up. If you set up the bind mount earlier, /mnt/documents will show up here like any other local path.
• Schedule — set how often it runs. Once daily is plenty for most personal data.
• Options — the defaults are sensible for most people; the one worth changing is retention, under Smart backup retention, which thins out older backups automatically instead of keeping every single run forever.

Save the job, then click Run now once to confirm it actually completes before you trust the schedule to handle it unattended.

Commands Explained

Common Errors

"Unable to open a socket for listening, tried ports: 8200" means something else is already bound to that port, or a previous Duplicati process didn't shut down cleanly. Check with ss -tlnp | grep 8200 and kill whatever's holding it, or restart the container.

dpkg reports "dependency problems - leaving unconfigured" after installing with dpkg -i directly. This is the classic symptom of skipping apt's dependency resolution. Run apt --fix-broken install to pull in what's missing, or just reinstall using apt install ./file.deb as shown above.

The web UI won't load at all from another machine, but works fine with curl localhost:8200 inside the container. That almost always means the container's firewall or your network's client isolation is blocking the connection — check Firewall settings under the container in the Proxmox UI, and confirm it isn't set to drop inbound traffic by default.

Backup job fails with a 403 error against Backblaze B2 nearly always traces back to an application key that isn't scoped to the bucket you're using, or one that's read-only when the job needs write access. Regenerate the key in the B2 console with read and write permissions on the specific bucket.

"Found N remote files that are unexpected" shows up if you point two different backup jobs at the same destination folder, or if a previous failed run left partial files behind. Run the job with Repair from the job's dropdown menu before trying a normal backup again.

Troubleshooting

If the service won't start at all, journalctl -u duplicati -f is your first stop — it'll usually name the exact problem, whether that's a permissions issue on its config directory or a port conflict. Restart with systemctl restart duplicati after fixing whatever it flags.

If backups are running but taking far longer than you'd expect, check your container's RAM usage during a run with free -h. Duplicati keeps file metadata in memory while scanning, and a container that's too tight on RAM will thrash and slow everything down. Bumping it from 1 GB to 2 GB usually fixes this for anything but very large datasets.

If a bind-mounted folder shows up empty inside the container, double-check the mount actually took effect — run pct config 115 on the host and confirm the mp0 line is there, then restart the container. Bind mounts only apply after a restart if the container was already running when you added them.

Best Practices

• Store your encryption passphrase in a password manager, not in a text file on the same server you're backing up. If that server dies, you need the passphrase to be somewhere else entirely.
• Use a scoped application key or bucket-specific credentials for the destination, never your root cloud account password.
• Actually test a restore once, right after setup. Pick a file, restore it to a temporary folder, and open it. A backup nobody's ever restored from is a guess, not a plan.
• Keep this container small and dedicated. Don't install other services alongside Duplicati in the same LXC — if it needs troubleshooting later, you want a clean, predictable environment.
• Set retention policy on day one. Unlimited history sounds nice until your bucket bill catches up with you.

Frequently Asked Questions

Does Duplicati replace Proxmox Backup Server?

No. PBS and vzdump back up entire VMs and containers so you can restore the whole machine. Duplicati backs up the files you choose, for when you need file-level, encrypted, off-site protection on top of that.

Can Duplicati back up an entire VM's virtual disk?

Technically you could point it at a mounted disk image, but it's not built for that and you'll have a much rougher time than just using vzdump. Stick with Duplicati for files and folders, not whole-disk images.

What happens if I lose my encryption passphrase?

The backup becomes permanently unreadable. There's no recovery mechanism by design — that's the trade-off for real encryption. Write the passphrase down somewhere durable before your first backup job runs.

Is Duplicati free to use?

Yes, it's open source and free, including for the cloud destinations it supports. You only pay whatever your storage provider charges for the space and bandwidth you actually use.

Do I need a static IP for the container?

Not strictly, but it makes life easier since you won't have to look up the address again after a reboot. A DHCP reservation on your router works just as well as a static config inside the container.

Conclusion

Once it's running, Duplicati mostly disappears into the background — which is exactly what you want from a backup tool. The setup here takes maybe fifteen minutes: a small container, one package install, and a backup job pointed at wherever you want your files to end up.

If you've been relying on vzdump alone and it's only ever protected the whole VM, this fills a real gap — an encrypted, off-site copy of the specific files you'd actually be upset to lose, running independently of everything else on your Proxmox host.