I started to use the program before I understood how to limit the backups to only one VBK copy of any one VM I was backing up. I was manually deleting the VBK files and keeping only one instance. However, now when I go into the Restore Wizard, I have "ghost" entries and some VMs that give an error "this row has been removed from the table and does not have any data". How do I go about cleaning up my mess?
Hello, I am afraid it is not possible to clean up this without editing the configuration database. You should not delete backup files manually, instead you should change the retention policy in the Advanced job settings to lower setting. This way, the product will handle restore points automatically, without producing ghost entries.
To clean up the current situation, I recommend that you delete existing job, and create new one.
Just delete and re-create the jobs in which you were manually deleting backp files. Alternatively, try to change the retention policy for the existing jobs - I believe they should clean up themselves during the next run. Worth trying before re-creating jobs.
Gostev wrote:Just delete and re-create the jobs in which you were manually deleting backp files. Alternatively, try to change the retention policy for the existing jobs - I believe they should clean up themselves during the next run. Worth trying before re-creating jobs.
I'm changing that now.
Why on earth does it default to 14? Can't we just start at one?
Our product stores deltas (changes) only, whether or not you leverage CBT... CBT only allows us to determine those changes faster.
VMware announced that they will fix the CBT issue in vSphere 4.1, but we long have a workaround for this issue available anyway. In all cases, the whole issue is very unlikely to run into on production systems, because it involves reverting snapshots and specific sequence of actions. That is, if we are talking about the same thing here.
