Restorepoint corrupted during replication job

[FrancWest]

Hi!

Today I received a warning from our replication job that for 3 VM's the restore point was corrupted. Since this sounded quite serious for me I had to check further what the issue was. After further investigation it appeared that the restore point wasn't corrupted but it was because of the fact that the copy job that creates the source backups for the replication wasn't finished yet. So quite a relief that our backups were still good.

I have two questions/suggestions about this:

- Why is this being treated as a warning? A corrupted restore point sounds like an error to me (although it wasn't actually a corrupted restore point in our case).
- Since this is being reported as a warning, it doesn't retry the job and also a manual retry is not possible. I had to start the entire replication job again, which also caused warnings about newer restore points not being available for the VMs that got replication successfully earlier.
- Why doesn't the replication job wait for the restore point to become available for replication? Since this copy-job was still transferring after a healthcheck was done, the job wasn't yet finished before the replication started. It would be useful if the replication job waited for this restore point to become available instead of trying to use it nevertheless and reporting a warning about the restore point being corrupted (which it actually wasn't since it was still being created).

Franc.

[PetrM]

Hi Franc,

1) In the beginning of every backup copy job session, a record about restore point is added to the configuration database and this restore point has "corrupted" state until the successful job completion. Once the job is completed successfully, the state of restore point state is changed to "valid". I guess that in your case, replication checks the latest backup restore point and sees that it has "corrupted" state (because the backup job is still running) and you get this warning as a result.

Do I understand correctly that replication job created the new replica restore point on target but just the latest backup restore point was skipped and was not used as a data source?
In this case, it should be considered as "warning" because the new replica restore point is created despite the latest backup was skipped.

2) The replication job does not wait a backup job because it does not know about backup job settings and its schedule.
The replication job sees a backup as a source of data and works with the latest available VM state.

Thanks!

[FrancWest]

Hi,

no new replica restore point was created for these 3 vms and no data was transferred and the warning ‘restore point corrupted’ was raised. Only when I manually started the replication again, the latest restorepoint was replicated.

But the replication job ‘knows’ what the source is for the replication, so it can detect that the latest restore point is still in the process of being created and it should be possible to wait for it. Especially since you mark the restorepoint as ‘corrupted’ at the start of the copy job.

Also, why do you mark it as corrupted and not as for example ‘in progress’ so you can detect that the restorepoint is being created and it can wait for it until it shows ‘completed’?

[PetrM]

Can you please open the support request and share case ID? May be support team would be able to explain why it throws the warning message instead of error.

Technically, it's possible to check the running job. We mark a backup session with "in-progress" state, the restore point can have 2 states only: consistent or corrupted.

Thanks!

[FrancWest]

Hi,

I opened a case in May about this when I first encountered the issue. Case #04166708. Case was closed as ‘by design’.

[PetrM]

I've reviewed the case and it was closed as "by design" because support engineer explained why replication does not wait for backup and confirmed that this is the expected behavior, however the fact that the job throws the warning remained out of attention.

Let me please clarify this question and I'll update the thread as soon as I have more information.

Thanks!

[PetrM]

@FrancWest
I've reproduced the behavior described above using one of v10 beta builds however it works exactly as you asked on my other server where this patch is installed:
the replication job waits for source job completion (tested both: backup and backup copy) with the message: "Restore point found, but is locked".

I recommend to install the Cumulative Patch 2 and to double check the behavior. If the issue persists, the best option will be to re-open the support case and to escalate it.

Thanks!

[FrancWest]

Hi,

That patch was already installed when I created this forum post. Will try to test it again and re-open the case if the issue persists.

[PetrM]

Sounds good. Please don't forget to paste case id for our reference.

Thanks!

[FrancWest]

I keep getting the warning every Sunday, since on that day the copy job takes longer to complete. I’ve reopened the case again. New case number #04278878

[FrancWest]

The new case is also at the stage of being closed as ‘by design’ and I’m advised to submit a feature request.

[PetrM]

Hi Franc,

The case is escalated and our senior support engineer is working on it now, let's wait for results of analysis.

Thanks!