Skip backup of VM if it hasn't run nor changed

[guido9]

Hi !
I got question regarding the backup feature. I'm running version PVE 9.1.1.
I plan to have a schedule to backup my VMs every night to local (filesystem) storage.
Quite some of the VMs are not running continously. Some are only needed on special occasion or during weekends. These are normally powered off.
I want to RSYNC the backup files to a file server (off site), to protect against local storage failure and fire etc.
I suspect that there is a new backup-file (with a new name) for a VM created every night (even if the VM was not changed, i.e. it's configuration, nor did it run, since last backup). RSYNC would treat it as a new file, which had not been send to the remote site ever before and send it.

My questions:
- Is my thinking correct (ie. a new backup file is created every night for a VM) and RSYNC would not detect that it's same file as transferred the night before ?
- Is there a way to tell the backup schedule in proxmox to only create a new backup file, when the VM was changed or had the VM had been started/ran since last backup ?

Thanks a lot !
Guido

 

[UdoB]

You may place a feature-request-"bug" over there: https://bugzilla.proxmox.com/describecomponents.cgi?product=pve . (If you do: please cross-link to here.)

Currently there is no good solution, as far as I know. But you can either a) manually disable "Backup [x]" for each large Hard Disk or b) use one of the multiple white-/blacklisting methods in the "Create: Backup Job" Dialog - "Selection Mode:".

 

[wbk]

Hi guido9,

In addition to UdoB's suggestion, I notice you are a new member. Have you looked into PBS, the backup component of Proxmox?

It would not directly enable what you ask (ie, skipping unchanged containers/VMs), but it would serve the same end: only changed data is saved.

• PVE+PBS cut each container/VM in chunks
• On backup, only the changed chunks are saved
• Running PBS on the same iron as PVE, it has the chunk storage local
• rsync then runs, picking up only the unique chunks to transfer offsite

The benefit is that even if one of those services has been running over the weekend, only the (smallish) set of changed data needs to be transferred.

The main disadvantage is that the process will still run through all configured VMs and containers.

PS, welcome to the forums!

 

[Impact]

Related: https://bugzilla.proxmox.com/show_bug.cgi?id=3092

 

[niteshadow]

A new backup file is created on local storage.
The old ones are pruned (deleted) after backup file is created, so please set the retention policy of the local storage.
These are "full" backups, check existing backup size to estimate how much you can retain.
Retention policy will usually be in this case "keep X backups" (mine is 2 for example).

As suggested by @wbk PBS is the better choice (incremental backups, proper retention policy)
If you are not ready for that, instead of rsync, why not create another backup schedule and backup directly to a nas or server using SMB or NFS ?

 

[Kingneutron]

Create separate backup jobs based on needs, you're not limited to just one.

 

[bitranox]

> had the VM had been started/ran since last backup ?

you can find out, but its flaky (what if logs are rotated ?) :

grep "/qemu/<VMID>" /var/log/pve/tasks/* 2>/dev/null
# or
journalctl -u pvedaemon -u pveproxy -u pvestatd --since "30 days ago" | grep "VM <VMID>"
# or
journalctl | grep "qemu-server.*<VMID>"
# last stoptime :
grep -E "qmshutdown|qmstop" /var/log/pve/tasks/* 2>/dev/null | grep "<VMID>" | tail -n 1
# last startime:
grep "qmstart.*<VMID>" /var/log/pve/tasks/* 2>/dev/null | tail -n 1

Its all not very nice, but it can be done more stable with some monitoring tool like Zabbix, Checkmk, Prometheus/Grafana ot Your own Logging.
PBS would be here the most elegant and best solution.

If You only have one server, you CAN install PBS on the same machine. Its really not recommended for different reasons, but You can.

 

[SteveITS]

I’m pretty sure there was a FAQ or thread(s) about not using rsync with PBS but I’m not seeing it. IIRC it could be problematic. PBS has its own sync method. Rsync is of course OK with the full backups from PVE.

 

[alexskysilk]

- Is my thinking correct (ie. a new backup file is created every night for a VM) and RSYNC would not detect that it's same file as transferred the night before ?

You're trying to reinvent the wheel.

Moden backup strategies are differential, which means that they are
- content aware (via CBT)
- only transfer the changes

the "simple" vzdump process is not content aware, so you would have to resort to these self made hacks to get what you're after, but if you use PBS all that goodness is already provided. just set the job and forget it.

 

[guido9]

Folks,
thanks a lot for all your comments and suggestions, but I think, besides all the presented ideas, the bottom line remains:
- Backups are being created, while not needed at all: The VMs had not changed
This is avoidable waste of storage, IO and CPU
- PBS is not a solution to the problem, but it seems to be a solution to avoid the waste of bandwidth for the remote transfer.
That's fine, but rsync and rdiff-backup are as well solutions to this problem. Both are known and proven to us, and do not require to
introduce another product, nor training.
- Schedules and Retention settings do not solve this problem, they only help when one knows upfront which VMs ran and which didn't. Unfortunately
in my environment, we do not have that knowledge upfront. Except for the always "on" VMs, the onces which are normally "off", can be started anytime,
so I have no choice but to have a backup schedule to include these VMs all the time.

I think I saw 4 tickets in bugzilla where people have been requesting the feature to skip unchanged VM backups (and Containers). The newest seems to be 6 years old. Looks like this feature is not a priority for proxmox, I'm not going to open another one.

I'm going to try this solution:
A script to rename the backup-files removing the date/time parts. That way my transport (rsync) would hopefully) be able to recognize the unchanged file(s) and not transfer these. This limits me to only have one copy (retention) of each backup, which is what I currently use anyways. But I believe this can
become a too limited solution. If more copies become a requirement then rdiff-backup or PBS might be needed.

 

[alexskysilk]

- PBS is not a solution to the problem, but it seems to be a solution to avoid the waste of bandwidth for the remote transfer.

I suppose maybe I didnt understand what the problem was. I had understood you to not want to transfer backups when no change was present.

That's fine, but rsync and rdiff-backup are as well solutions to this problem. Both are known and proven to us, and do not require to
introduce another product, nor training.

You could have started here and make the whole thread unnecessary. You dont actually NEED vzdump at all to do this.

 

[wbk]

You could have started here and make the whole thread unnecessary. You dont actually NEED vzdump at all to do this.

In guido9's defense : his reason to start the thread was not to ask how he could convince rsync not to pick up (data-wise) unchanged backups, but, as a new user, asking whether he overlooked the option to skip unchanged VMs and containers.

I'm not familiar with commercial virtualization and backup solutions; perhaps the offer a flag indicating 'has not run since yyyy-mm-dd' or some such, while, being closed source, preventing the VM or container from running without the platforms knowledge.

 

[gfngfn256]

Another idea:

Remove the original daily backup job for the VM/s.
Instead, use a hookscript with the post-stop phase to trigger a backup of the VM.