Copy Job - Delete from Disk Consequence on next run?

[evander]

Hi, I want to "delete from disk" on a large copy job to free up space on a repo that is out of disk space.
I am happy to delete the incrementals and plan to keep the GFS copies. This will hopefully give me enough space for the next copy job to run successfully while I make other arrangements.

My questions is: If I do the Delete from Disk (GFS un-selected) will the next job run be a full backup from source or will it still run changes from the last full backup located on the destination.
The VM is large (21TB) and the copy job is going to a remote off-site repo so I dont want all 21TB to go from source to destination. I just want changes from last good backup.
The destination repo is ReFS and jobs are per-vm.

Thanks.

[Mildur]

Hello Evander

My questions is: If I do the Delete from Disk (GFS un-selected) will the next job run be a full backup from source or will it still run changes from the last full backup located on the destination.

This will also delete the full backup from your active backup chain if it doesn't have GFS tags assigned. Which will most likely lead to an active full backup.

Our recommended approach is to lower the retention settings in your backup job. Manual deletion of single restore points is not recommended.
But to manually clear up space, you can delete older VIB files directly from the disk.
Then run a rescan of your repository and remove missing restore points from the configuration database:
https://helpcenter.veeam.com/docs/backu ... ml?ver=120

Please note: Keep the full backup and incremental backups from your active backup chain. That will allow you to continue the backup chains with FastClone aware backups.

Best,
Fabian

[evander]

Thank you Fabian, I am going to try the lower retention option first, hopefully the job will run through, and then look at the manual VIB deletion option if not.

btw: Is there any easy way to identify the active chain?

Much appreciated.

[Mildur]

Hello Evander

The active chain is the most recent full backup (vbk) and all it's incremental ones (VIB).

Best,
Fabian

[evander]

Thanks for the assistance and sorry for slow response but I have been trying various options and trying to run the job over night.

I am still struggling to get a solid backup run due to lack of space. I have manually deleted some old full vbk files but unfortunately because its fast clone ReFS the amount of disk space I get back is minimal. This was not enough for a new backup run to complete successfully.

You mentioned previously that I should keep the latest vbk and vib active chain to prevent the next backup job transferring the full source to destination. However, because the backup has failed multiple times I have a number of vib files and one vbk that are marked as incomplete. Can I therefore remove everything up until the last "good" vbk and still retain the fast clone properties? See image attached for some clarity

I am not worried about losing data at this point as I have multiple backup copies of this same VM elsewhere, my primary concern is just to get a good working backup to this remote repo without transferring all source to destination (many TB)



https://imgur.com/a/FQAZaLr


Thanks

[Mildur]

Can I therefore remove everything up until the last "good" vbk and still retain the fast clone properties? See image attached for some clarity

Depending on what block have changed in the source VM since September, the next copy job will not only transfer the regular size of daily incremental.
The copy job will have to transfer a restore point which covers the current state of the source VM compared to the full-backup taken in September.
It could be many TB.

I recommend to open a case with our customer support to discuss different options you have. One may be adding more storage to the backup repository server.

Best,
Fabian