Rename backup group

Tacioandrade

Renowned Member
Sep 14, 2012
105
13
83
Vitória da Conquista, Brazil
Good afternoon friends, I have in my PBS the backup of a VM that is with Backup Group vm/136, it is a Windows Server VM that presented problems in the most current version (the damn Windows had a black screen and did not want to boot, I returned a backup from 11/14 with VMID 147 and it started correctly).

But I don't want to lose the history of the backups I already have from PBS, so I'm looking for a way to rename the Backup Group of the VM from vm/136 to vm/147. Does anyone here in the group know how to do this?

Through the web interface I saw that you can change the owner of the backup, change notes about the backup and a few other things, but I didn't find a place to make this change.

Thank you in advance for your help.
 
I've never done this myself yet. Supposing that you are backing the old and new VMID to the same datastore, maybe you can rename the datastore directory vm/136 to vm/147.

In anycase, I don't see the need to mess around with this: just let the old vm/136 backup snapshots to expire at the time set by your prune policy and let the new vm/147 create new snapshots with the new ID. If they are in the same datastore, duplicated chunks will be shared for any VMID/CTID/host.
 
I've never done this myself yet. Supposing that you are backing the old and new VMID to the same datastore, maybe you can rename the datastore directory vm/136 to vm/147.

In anycase, I don't see the need to mess around with this: just let the old vm/136 backup snapshots to expire at the time set by your prune policy and let the new vm/147 create new snapshots with the new ID. If they are in the same datastore, duplicated chunks will be shared for any VMID/CTID/host.
Hello my friend! In this case, I would like to avoid this, since this VM has a large size, so I would like to avoid a new full backup of it.
However, I already scheduled this full backup over the weekend and next weekend remove the backup of the old VM, we increased the storage space to accommodate this unexpected use of storage for our largest VM having 2 full backups.
 
In this case, I would like to avoid this, since this VM has a large size, so I would like to avoid a new full backup of it.
However, I already scheduled this full backup over the weekend and next weekend remove the backup of the old VM, we increased the storage space to accommodate this unexpected use of storage for our largest VM having 2 full backups.
All backups are full backups. There are no differential backups with PBS that are based on previous backup snapshots. All that should matter is if the chunks are already existing or not. And as long as you don`t prune those "vm/136" backup snapshots, a backup of "vm/147" shouldn't consume additional space (except for the changes since the last backup of cause). Deduplication is datastore wide. Shouldn't matter what VMID those chunks are belonging to.
 
Last edited:
Dunuin explained it perfectly :) I would only add that the first backup of vm/147 will have to read the whole disk as the dirty-map is (re)created every time a VM is cold started (that is, if the VM was stopped), but only new, non-already-existing-chunks-in-your-datastore, will need to be uploaded to your PBS. Check the log of the backup and look for "backup was done incrementally, reused" to check how many bytes were already in the datastore for that specific backup.
 
  • Like
Reactions: Dunuin

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!