Removing Backup Copy Increments

[y1008946]

Hi, I can remove the latest increments in backup copy jobs by editing the VBM file in Notepad++ and it has saved me many times when jobs have become corrupt because of problems with our internet connection.

We now make use of the great feature to encrypt backup copy jobs offsite.

The VBM file appears to be encrypted though so it cant be edited, is there any way it can be edited or a way that the latest increments could be removed?

Thanks very much

[Gostev]

Hi,

There is no way to edit encrypted VBM.

Besides, its not clear what was the point of doing this before. Backup Copy jobs cannot "become corrupt" due to problems with internet connection, because we do network traffic verification automatically. Connection drops will not cause issues either, as the job understands them and recovers automatically.

In any case, what you were doing before is unsupported, as this makes VBM contents out of sync with the configuration database.

If you are running into some corner cases which Backup Copy job cannot handle, they need to be closely investigated through our support, so that Backup Copy jobs logic is enhanced to handle those. Editing backup files manually is not a scalable approach anyway, and it increases TCO of the whole solution significantly due to requiring babysitting and human intervention... so, please help us help you

Thanks!

[y1008946]

Hi Gostev, thanks for your reply.

It was support who showed me how to do it, and there are tools for v7 and v8 to remove increments too, do the tools cause problems?

The problem was caused initially by our ISP, they had a problem with their service and the internet kept dropping for periods.

The problem I came across was after seeding a job, when it was processing the first run and calculating digests, the connection would drop for a period of time. If the connection didn't return before the number of retries expired, the job would fail and it would try to send the whole backup copy file again over the WAN on re-runs.

By deleting the increment, removing the imported backup, re-importing the backup and re-run the job. It would then calculate the digests and run fine thereafter. Being able to delete increments helped save lots of time because I didn't need to create another backup copy to a USB drive (2 hrs), drive to the DR site (1 hr away), copy it across (5 hrs) and set the job going.

The latest problem has been that an encrypted job has started saying...

Failed to verify disk Exchange-flat.vmdk of VM Exchange Error: Keyset '4e34a5d5028730cfa67d8e99a9c0a2aa' not found.

If I could have deleted the last increment (which must have had some kind of problem) I could have probably rectified it.

I will log a call with support, what I have found in the past (until being shown how to delete increments) is that the advice is to re-seed, but I will see what they recommend (Support ID - 00716576).

We've been using Veeam 8 since it was released and it is great software!

Many Thanks

[Gostev]

Thank you very much for your time writing the explanation and opening a new support case. I hope you will be able to reproduce the issue for the devs to investigate. Please do not accept the advice is to re-seed this time, as this way of closing support cases gets us nowhere in terms of improving the quality of our product. Have them escalate the issue to R&D for research instead. I keep stressing this with our support management as well, and they are fully on-board with that - but then there is a human factor as always... it's just very tempting for some individuals to close the support case swiftly with "re-seed/re-create/re-install" type of resolution, instead of spending time chasing the bug that caused the issue in the first place.

As far as your initial question, manual configuration edits leave your environment supported when performed by our support engineer. You can certainly do the same edits manually, but if you do something wrong and brake stuff in the process, we will not be able to support your installation. This would be the time when our support will request that you re-seed/re-create/re-install (and in this particular case, it will be a legitimate request ). Hope this makes sense.