Proxmox Backups Shouldn't Be This Frustrating. One Homelabber Wrote a Script.

Proxmox Backup Server can use storage backed by a Synology iSCSI LUN, and a community script attempts to simplify the initial connection and setup. It reduces repetitive configuration work, but it does not replace a recoverability test or a decision about storage failure domains.

The published pbs-synology-iscsi project describes guided iSCSI and CHAP configuration. The discussion around it was less about whether the script runs and more about whether NFS, local PBS storage or iSCSI is the simpler long-term architecture.

Why use Synology iSCSI for Proxmox Backup Server?

Synology iSCSI can present block storage to a dedicated PBS host, avoiding some of the file-share permissions that frustrated this setup.

The builder, who goes by MorphyDK, described repeated frustration with using NFS for PBS storage on Synology. It wasn't a dramatic storage failure or a tale of vanished backups. It was the smaller, grinding problem of permissions and configuration that made each fresh installation feel unnecessarily difficult. Anyone maintaining a homelab knows that kind of friction. A task works, but returning to that state months later can mean reconstructing forgotten decisions. The backup system starts to feel like one more thing that needs rescuing. That's a particularly annoying place to be when its entire purpose is to make recovery easier.

Before deciding on a target protocol, review a wider Proxmox backup strategy that includes off-host copies and restores.

The turning point was finding Derek Seaman's approach to attaching an iSCSI LUN to a Proxmox Backup Server host. MorphyDK tried it and reported that it worked. That distinction matters: the idea of using iSCSI wasn't presented as a breakthrough invented from scratch. The builder openly credited Derek's work as the backbone and focused on making the process friendlier. Instead of returning to a collection of commands and notes every time, the aim was a guided setup with menus, colors, detection, and clearer decisions. The problem being solved was repetition as much as storage. Less detective work, fewer forgotten steps, and a setup that another homelabber might feel comfortable attempting.

Underneath the argument is a genuine technical difference. NFS exposes a network file share, bringing file ownership and access behavior into the relationship between PBS and the NAS. iSCSI exposes block storage to the PBS machine, where a suitable Linux filesystem can hold the datastore. The official PBS storage documentation describes datastores as directories on standard Unix filesystems such as ext4, XFS, or ZFS. That doesn't make iSCSI universally better, and it certainly doesn't remove every possible failure. It does change where the filesystem is managed, which is exactly why someone exhausted by NFS permissions might find the alternative appealing. The practical question becomes whether that trade makes this particular environment easier to operate.

What does the PBS Synology iSCSI script automate?

The repository describes a guided workflow for configuring the iSCSI target and authentication instead of repeating manual steps.

The published project goes beyond a colorful menu. Its repository describes guided iSCSI target configuration with CHAP authentication, storage inspection before changes, and the ability to recognize and reattach an existing PBS datastore instead of automatically erasing it. It also describes post-install tasks such as repository adjustments, system upgrades, mount recovery monitoring, and trim scheduling. Those are the author's documented features, not proof that every path works flawlessly on every system. Still, the ambition is clear. The script tries to turn an easily forgotten sequence of storage and operating-system steps into a repeatable procedure. For someone who has already rebuilt the same setup several times, that's a very understandable ambition.

A particularly important promise is what happens when the tool encounters existing data. Backup storage is one of the worst places for a script to make an incorrect assumption. The repository says the setup checks disks and attempts to preserve and reattach an existing datastore when it finds one. That deserves attention, because a good installer should recognize when the correct action is to leave something alone. But a description in a README isn't a substitute for inspecting the code and testing the destructive branches safely. The project also offers a direct shell command that fetches and executes the script. Convenient? Absolutely. Something to run blindly on the only copy of irreplaceable backups? That's a much harder sell.

The builder also acknowledged getting substantial assistance from Claude AI. That admission doesn't automatically make the code bad, just as writing every line by hand wouldn't automatically make it safe. It does raise a fair question about review and testing, especially where partitioning, mounting, upgrades, and authentication are involved. Here the human collaboration in the replies offered an encouraging counterweight. Derek himself appeared and offered to incorporate the changes through a pull request. MorphyDK followed up privately. A tool that began as a personal irritation had attracted interest from the creator of the earlier approach. That's how small infrastructure utilities can become useful to more people, provided maintenance and review grow alongside convenience.

Is NFS or iSCSI simpler for Proxmox backups?

Neither NFS nor iSCSI is always simpler; the better choice depends on how the datastore is owned, mounted, monitored and restored.

Not everyone wanted a more elaborate iSCSI installer. One participant described putting PBS directly on the storage server, avoiding the need to connect to storage over NFS, iSCSI, or SMB in that arrangement. Another pointed to a guide for running PBS as a Synology virtual machine. People shared experiences with older Synology hardware too. A DS1815+ was remembered as working well for PBS, while someone using an RS820 said the setup was reliable even though it wasn't setting speed records. That last observation might be the most sensible benchmark in the entire discussion. When the job is safeguarding a home network, predictable backups may matter more than impressive throughput charts.

The underlying storage tradeoffs are explored in the ZFS, Ceph, LVM Thin and RAID comparison.

A different commenter reduced the proposition even further: run PBS in Docker on a capable NAS. It was presented as a quick, uncomplicated solution, with a modest memory estimate, but that estimate was one person's assertion rather than a tested requirement across NAS models. Containers can be attractive when they fit existing habits and hardware. They also move compatibility, persistence, and recovery questions into another layer. The alternatives weren't all interchangeable, and the comments didn't demonstrate that they were. Some operators want a dedicated PBS machine and remote storage. Others want the backup service sitting on the storage hardware itself. Both can be coherent choices, but each asks the administrator to trust a different part of the setup.

Then came the suggestion that made the original script look almost modest: add iSCSI multipathing. One commenter shared a rough shell example and argued for configuring multiple paths between the PBS initiator and storage. The author said they would look into it, while another reader asked whether that meant multiple storage sessions. Multipathing can be relevant when redundant paths are available, but the fragment in the discussion wasn't presented as a reviewed, production-ready addition to the project. More importantly, it highlights the endless homelab temptation. Every time someone removes a configuration headache, another person spots a resilience feature worth adding. Soon a script designed to reduce fiddling risks acquiring its own impressive collection of moving parts.

How should you judge a PBS storage setup?

Judge the design by successful restore tests and predictable failure recovery, not by whether the initial wizard completed.

The disagreement isn't really about whether NFS or iSCSI deserves a trophy. It is about where complexity should live. A dedicated PBS instance with a Synology iSCSI LUN keeps the service and its storage separate, but demands network storage configuration. PBS running on the NAS may eliminate that connection, but it places the backup service and stored data on the same appliance. A container-based deployment may look lightweight, but it has its own support and maintenance considerations. Multipathing adds resilience to a suitable network design, though it adds more to configure. None of these tradeoffs can be settled by how satisfying an installation menu looks. The right arrangement depends on what equipment already exists and which failure scenarios the owner cares about.

There is also a distinction between a reliable connection and a reliable recovery plan. A successfully mounted LUN doesn't show that a damaged virtual machine can be restored. A script that detects an existing datastore doesn't establish that the data inside is healthy. The discussion includes positive anecdotes and useful ideas, but no comparative benchmarks or long-term restore evidence for MorphyDK's new tool. Treating those missing details honestly is important. A sensible adopter would review the script, test it against disposable storage first, understand which actions can alter disks, and verify that a restore actually works. Those checks are less exciting than an automated setup, but they are the part that separates reassuring backup activity from recoverable data.

Perhaps the most appealing aspect of the story is its modest starting point. Someone faced a repeated problem, learned from an existing solution, and built a tool to save others time. The original contributor was willing to collaborate. Other homelabbers offered architectural alternatives and a suggestion for more resilient connections. Nobody produced a universal answer, and the new script doesn't need to become one to be useful. Its value will be decided by whether it makes PBS easier to set up without making it harder to trust. Because a backup system that installs beautifully but fails at the moment of recovery hasn't solved the frustrating part after all.

I would choose the protocol the operator can monitor and recover confidently, and run a full guest restore before trusting it. If a direct PBS datastore on reliable local storage is simpler in your environment, the extra iSCSI layer may not be worth adding.