This is a long time retention job, so if I don't do nothing I need to wait 1 year to reclaim the 5.2T the first full is using. Even if it's complicated because of the deduplication between backup files, is there any solution to delete the 5,2 revision ?
Cedric, if you delete this full, you will have to delete all the incrementals created prior this full (since they depend on this VBK) and will not be able to restore to any moment in time prior 2013-08-23. If you do need those restore points and need to release space on the backup repository, I recommend to move this chain to some other location and continue running the job with the rest of the chain (latest full and its incrementals).
Ok I will follow your suggestions !
If it doesn't exist yet in the v7 (still running v6.5 here), maybe it would be a good idea to had this feature in the wish list ?
I think he means the ability to transform that intermediate vbk file into a vrb one, o the again have only the last vbk as usual in reversed incremental. To me it sounds like a really heavy IO operation, because Veeam would have to scan all the files newer than the intermediate VBK in order to find duplicated blocks, and rewrite a VRB file...
A viable quick solution is to move all the files newer than the "wrong" vbk file into another directory, import that backup chain, and map the backup job to the new chain. Once the retention period on the new chain is long enough, simple remove the old chain from the backup lists.
Luca.
Luca Dell'Oca Principal EMEA Cloud Architect @ Veeam Software