Is my incremental chain broken?

[briggs]

Hi,
We have a critical file server, that is rather large. Because of the size, we can't do reverse incremental, it seems to take too long to complete. So we do forward incremental, with an ACTIVE FULL each month. We retain 3 months of data.
Today, we accidentally (yes, I know!) had 2 veeam servers on our network, with the same database, trying to do the same backup job, using the same repository, at the same time. We'd restored our veeam server from a backup for testing purposes, given the machine a new IP and name, but forgot to suspend the jobs!
So, it appears both servers ran the same job, at the same time. They both gave warnings, but not fail? - "Unable to truncate transaction logs. Details: RPC function call failed. Function name: [FinishSnapshot]. Target machine: [10.0.0.2]. RPC error:There are no more endpoints available from the endpoint mapper. Code: 1753"

My question is, with 2 backups running at the same time, to the same repository, have I broken the backup chain? Will any further incrementals be broken? Does every incremental need the previous incremental AND a full to be able to restore from? What breaks this cycle?

Many thanks in advance, Alan

[foggy]

Alan, the scenario is indeed quite tricky and unusual. I'd assume that the backup chain will become corrupt since both Veeam B&R servers will try to access the same VBM file while creating their respective restore points and this will mess the whole thing up.

That said, you should definitely be able to restore from the last normal (created before the second Veeam B&R instance came in) restore point without any issues, as previous backups are never touched with the forward incremental mode.

I recommend to turn one of the instances off and perform full backups for the affected jobs to start their chains from scratch.

Does every incremental need the previous incremental AND a full to be able to restore from?

Yes, the whole previous backup chain is required to restore from the particular restore point.

[veremin]

Additionally, the easiest procedure to understand for sure whether or not the latest restore point got corrupted is to try to perform restore activity from it, using Instant VM Recovery, for instance.

Assuming this doesn’t work, kindly follow procedure mentioned by Alexander.

Hope this helps.
Thanks.