In my previous article, I explained how I replaced proprietary hypervisors with Proxmox without ever taking production down. Once the virtualization was migrated, one last proprietary piece remained at the heart of the infrastructure: the backup software. It was faithfully protecting a platform that no longer existed.
This second project looked simpler. It was not. Changing backup tools is not swapping one piece of software for another: it is moving a memory. Yesterday's backups must remain readable tomorrow, even though the new tool cannot read them. Here is how I replaced Veeam with Proxmox Backup Server without losing five years of history, and the traps nobody documents.
Why replace a backup that works?
After the migration, the situation was absurd. The virtual machine backup jobs were running against nothing: their sources had moved to Proxmox. And on Proxmox, Proxmox Backup Server (PBS) was already backing up every machine and every container each night, encrypted, incremental and deduplicated.
Two tools, two consoles, two licences, two ways to fail silently. The old one only brought two things PBS does not do on its own: backing up the file shares of a NAS, and a history of several years, locked in its proprietary format.
The reasons to go open source were the same as for the hypervisors: cost, independence from a vendor, and above all readability. A PBS configuration is plain text files. My AI agent can read them, audit them, compare them with the documentation. A proprietary console, it can only look at from a distance.
First question: what would we lose if we cut it today?
Before touching anything, I listed every job of the old tool, with its PBS equivalent and coverage level next to it. Not a wish list: a survey of the live system.
- Virtual machines. Already in PBS since the migration. The old jobs could stop without losing anything.
- File shares. No equivalent: PBS natively only backs up Proxmox guests. So I built a small dedicated container that mounts the shares read-only and sends them to PBS with its command-line client, share by share, encrypted with a separate key. Same deduplication, same retention, same monitoring as everything else.
- The history. This is where it all plays out. No open-source tool reads the old software's format. Migrating to PBS converts nothing from the past.
The gate: prove you can restore, before cutting anything
My rule on this project: no irreversible step without proof. The first one was obvious: being able to restore from PBS, for both kinds of data.
For machines, I restored a container from an encrypted backup into an isolated copy, with no network card and no autostart, so it could never clash with the original. It booted, and its data was byte-identical. Then the copy was destroyed. For files, I extracted a single file from an encrypted archive, with its dedicated key, and checked its content.
Only then did I disable the old tool's jobs. Disabled, not deleted: configuration and restore points stayed intact, and one command could re-enable everything. An unexpected bonus: its data was now frozen, a stable target for what came next.
The real issue: five years of history nobody can read anymore
The oldest restore point dated from September 2021. Five years of history, and one detail that changes everything: most of it existed in a single place, the storage of the backup server itself. The very server I wanted to reuse. Before wiping it, that history had to be taken out, and I had to be sure it would stay readable for years. Three findings changed the plan.
A volume bigger than itself
The old tool's storage reported 10.9 TB used. The folders added up to 14.8 TB. The gap comes from ReFS block cloning: to build its synthetic full backups, the software shares blocks between files instead of duplicating them. When copied, every file takes back its real size. Sizing the target at 11 TB would have failed three quarters of the way. It needed 15 TB.
A five-year-old file, read without a licence
The worst case for a proprietary history is keeping backups you can no longer open. So I tested the oldest one: a backup file from September 2021, opened with the vendor's standalone extraction tool, with no licence, no full installation, no password. Eleven minutes later, I had the machine's disks in VHDX, an open format that can be mounted directly or converted for Proxmox.
But that tool only reads machine backups. Not file share backups, not agent backups.
Keep a reader, not an infrastructure
Reading everything else requires an installation of the old software. Rather than reinstalling it on an old spare server, which would have been over twenty years old by the end of the retention period, I converted the physical server into a virtual machine. It stays powered off, only starts for a read, is itself backed up by PBS, and above all it keeps the old tool's configuration database: the index of every job and every restore point. A clean reinstall would have lost it.
Converting a physical server into a VM on the first try
The conversion booted on the first try: no blue screen, no recovery mode, no BitLocker key requested. That was not luck, it was a checklist.
- Capture the system, not the data. The capture tool ticks every volume by default. Untick everything first, or you drag along tens of terabytes of backups: the selection had to total 134 GB. And never write the image onto a volume you are capturing.
- The right disk controller. The image contains no VirtIO driver: the disk is attached as SATA, or Windows cannot see its own system.
- The right firmware. The source disk is GPT: UEFI boot (OVMF) on a q35 machine, with no pre-enrolled Secure Boot keys.
- BitLocker checked before, not after. A volume sealed to the original server's TPM would have asked for its recovery key on first boot.
The import read 223.5 GiB and wrote only 127: empty areas are not copied. First boot in under a minute, network cut, then every service of the old tool switched to manual start. An archive reader does not need to run.
Two disks, two sets of hashes, and a trap
The history went onto two 18 TB external disks, stored in two different places. Every file has its SHA-256 hash in a manifest: nearly 150,000 files, 11.5 TiB. Nothing counts as copied until a re-read has compared every hash, and then the two disks were validated against each other.
Two lessons along the way. My time estimate was pessimistic by a factor of two: I had based it on a few-minute sample at 42 MB/s, while the sustained rate held 81 MB/s. On a USB copy, a short sample tells you nothing. And folders full of small files ran seven times slower than the others: the penalty comes from the number of files, not the link.
And the trap. Comparing the two manifests, a difference showed up: one folder had lost a week of restore points between the first and the second copy. The cause: the old software's retention. It kept running every night, independently of the jobs, even disabled ones. Disabling backups does not freeze retention. The long-term history was intact on both disks, and the missing week was still on the first one. Without the hashes, I would never have seen it.
Reusing the server: a 37 TB RAID becomes a PBS
The next gate was the most important one of the project: re-read the archive from the external disks, before any wipe. Once it passed, the old tool's server could be reborn.
RAID controller in JBOD mode, so ZFS sees the raw disks. Two RAIDZ2 groups of six disks, about 29 TiB usable, lz4 compression, and no ZFS deduplication: PBS already deduplicates by chunks, doubling it would only cost memory. Why two groups of six rather than one of twelve? The disks were five years old: a rebuild twice as fast, and more disk operations for PBS garbage collection and verification, which read a lot.
Then the synchronization of everything that existed, from the old PBS: 633 backups. One design rule: a synchronization lasting dozens of hours never crosses the backup window. It runs during the day, and a timer stops it before the night. It resumes the next day where it left off.
A small trap along the way: PBS's default notification rule sends an email for every successful synchronization. Twenty emails in a day, and the real alert drowned in the noise. I replaced it with a rule that only speaks up on errors or warnings.
The cutover took 45 minutes, outside any backup window: point the hypervisors' storage and the file container to the new server, with its new TLS fingerprint. Then a real test: an incremental backup in 11 seconds, 95.7% of the data reused from the copied history, and a successful restore from the most recent backup as well as from the oldest one.
The first night, and the forgotten client
The next morning, every machine backup had gone through, and the night window ended around 3:15 instead of 4:00. Only one thing was missing, and the freshness alert found it: a script backing up a hypervisor's configuration was still pointing to the old server.
The cause fit in one word: head. My client inventory went through a truncated output, and two lines were missing. The right method, which I now apply to every cutover: after the first night, list every backup group on the new server, and require for each one either a backup taken after the cutover, or a written reason.
Two settings finished the job:
- Metadata-based change detection. Instead of re-reading every file, the PBS client compares metadata and only re-reads what changed. The largest share went from 28 to 11 minutes, another from 8 to 2, the smallest ones take seconds. Careful: the first pass rewrites everything in a new format, schedule it outside production. And it is not a universal rule: on a share with several hundred thousand small files, the metadata walk is bound by the client's CPU and becomes slower than the classic mode. That one stays classic. The right mode depends on the data, not on the principle.
- Alert thresholds measured, not guessed. A backup's age is counted from the start of the previous one: a long backup goes past 25 hours before the next one finishes, and the alert fired every morning for nothing. I measured the real maximum over seven days, then set 27 hours for machines and 32 hours for files. Real failures are still detected.
The outcome
The real gain, as with the hypervisors, is not the licence. It is that backup has become text: its jobs, alerts and scripts are versioned and documented, and my AI agent could read, measure and check everything with me. The irreversible decisions, wiping a RAID or destroying an old restore point, stayed mine, one by one, after each proof.
If I had to sum up this project in one rule: you do not migrate a backup, you migrate the ability to restore. Until it is proven, nothing is done.
Going further: the article Hyper-V to Proxmox, which came before this project, and Ransomware-proof backups, on how these backups are defended.