Veeam Application Backup Repository - A Script That Looks at What Is Actually There

The Application Backup Repository

Veeam Backup & Replication v13.1 introduced the Application Backup Repository (ABR). It runs on the Veeam Infrastructure Appliance in Hardened Repository mode and turns local storage into a pool of virtual volumes, each one exposed as its own NFS target.

The interesting part is what the writing side has to know: nothing. An application, a script, or a device simply writes to an NFS share. Veeam takes care of snapshots, immutability, and access control underneath.

No agent, no plug-in, no awareness of Veeam at all.  That makes ABR a good home for everything that never fitted into a backup job. Which brings us to how you should lay it out.

One Repository Per Source

It is tempting to create one big ABR and point everything at it. Do not. Permissions and the snapshot schedule are configured per repository. That makes the repository your boundary for who may write, for who may read, and for how long data is kept. A single shared repository means one set of NFS permissions covering everything you own. That last point deserves emphasis. A repository full of configuration backups is also a credential store. Switch configurations contain enable passwords, SNMP community strings and VPN pre-shared keys, most of it barely obfuscated at best. Anyone allowed to mount that export can read all of it. Immutability does not help here: it prevents deletion, not reading.

A realistic layout:

The last one is worth a thought. Plenty of environments run a PostgreSQL or MySQL instance somewhere that nobody ever integrated properly, and it ends up dumping to a local disk that is itself never backed up. An NFS target with immutability behind it is a large improvement over that, and it takes about five minutes to set up.

Licensing

Veeam backs the same conclusion from a different angle. Each application backup repository consumes one Veeam Universal License, Socket-based licensing is not supported. According to Veeam's own documentation, you must allocate a dedicated application backup repository for each application, so the one-repository-per-source design is not just good practice, it is also how licensing works.

The Blind Spot

Here is the catch with the design that makes ABR so convenient. There is no backup job. The application writes on its own schedule, and Veeam sees a share that was written to, or was not. There is no job result, no success event, nothing that turns red. Think about what that means. A container whose backup job was disabled three weeks ago looks exactly like one that ran an hour ago. A dump that was truncated looks exactly like a complete one. And if ransomware encrypted the source before the backup ran, Veeam will faithfully take an immutable snapshot of the encrypted result. Your data is “protected” but it is also useless, and nothing tells you. Immutability answers "can I still get my backup back". It does not answer "is what I get back worth having", and it certainly does not answer "which restore point/snapshot can I still trust".

A Script That Looks at What Is Actually There

That is what I built this for. It mounts the live repository and one of its snapshots, reads what is there, and reports the difference. It never opens an archive. Everything comes from four sources: file name, file size, the log the application writes next to each dump, and the first four bytes of the archive itself. A 100 MB backup costs four bytes of reading.

The first version handles Proxmox vzdump backups of LXC containers, because that was the case in front of me. The log turned out to be the most useful part. Proxmox writes a backup log next to each dump. That log contains exactly the success signal that ABR itself cannot provide. It sits right there, next to the data, and nobody reads it. It also records both the uncompressed byte count and the resulting archive size. That gives a compression ratio for free. In my test environment the containers compress at 3.24:1, and they do it consistently. Encrypted data does not compress. If a container that always compressed at 3.2:1 suddenly manages 1.05:1, it’s possible that something encrypted its contents before the backup ran. That is a ransomware indicator derived from two lines of text, without ever touching the payload.

The ratio is a reason to look, not proof on its own. A busy database, rotated logs, or a batch of new images can move it too. But normal variation stays within a few tenths, while encryption pushes the ratio to 1.0, and a real file system never gets there on its own. So the number worth reacting to is not a percentage drop, it is a ratio close to 1. The script also skips guests that never compressed well to begin with, a media store for example, since those sit near 1.0 permanently and the signal does not exist for them. Staying quiet is more useful than reporting a number that means nothing.

Three more checks follow the same logic. A finished dump is written once and never touched again, so if the same file shows a different size or header between two snapshots, someone rewrote it, and there is no benign explanation for that. A guest that was in an earlier snapshot and has no backup at all now has silently stopped being protected. And a backup can report success while containing nothing. Exclude the disks and the job still goes green. The script flags that too.

More details about the scripts, their parameters and sample output can be found in my GitHub repository.

What’s Next?

As always, feedback is welcome. And not just "Nice script, I'll try it". Tell me whether this actually makes sense, and share other scenarios and ideas.

I’m already working on the next release and testing it. The tool is no longer tied to Proxmox: files are grouped into series by stripping timestamps out of their names, so any application writing into the export is covered, and vzdump became one format handler among others rather than the only thing that works.

The compression check no longer uses a fixed threshold. It compares against everything a series has ever shown, which is what catches partial encryption. And when something looks wrong, the tool now suggests where to restore from. That turned out to be the more useful answer, because the backup that triggers the alert is rarely the first one affected. Stay tuned!

Steve

PS. For the full technical details on how ABR is configured and how it works, see the official documentation: https://helpcenter.veeam.com/docs/vbr/userguide/application_backup_repository.html