Rename backup group

[Tacioandrade]

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.

 

[VictorSTS]

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.

 

[Tacioandrade]

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.

 

[Dunuin]

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.

 

[VictorSTS]

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.