HPE SimpliVity restore error

[jlangmead]

Hi

I'm trying to investigate further an issue whereby an HPE SimpliVity backup will succeed without issue but a restore attempt of the backup fails immediately with an error stating that a 'Snap ID already exists'. This occurs on both policy based and manual backups, for new VMs that have never previously been protected (backup fine but restore states the same error), it also occurs for any VM resident on any host within the cluster.

It sounds like there might be a 'shared' backup database that is used\replicated by all the OVCs in the cluster which is perhaps corrupt - has anyone seen anything similar before or ideas on how to progress this troubleshooting. As this is occuring on all VMs on any host\OVC within the clsuter including newly deployed VMs (deployed specficially to run backup\restore test) it doesn't sound like a hardware issue nor anything associated with a single OVC etc. I can't find any technotes or advisories on this issue.

This is an old SimpliVity environment (running 3.79) but also hasn't undergone any recent updates or reconfigurations. It is difficult to know when this issue first occured as there were no errors in the backups however attempt to restore the earliest backups also fail.

thanks in advance

[support_s]

System recommended content:

1. HPE Simplivity RapidDR - Troubleshooting

2. HPE SimpliVity Rapid DR 3.6.0 User Guide

Please click on "Thumbs Up/Kudo" icon to give a "Kudo".

Thank you for being a HPE valuable community member.

[gustenar]

Hello @jlangmead, 

Are you attempting a full VM restore every time? This looks like something the support group needs to investigate. It's hard to give you a good answer without looking at logs for this. Please contact the support group for assistance. 

[jlangmead]

Hi @gustenar 

Thanks for the reply - I beleive it's for any method of restore.

Are there any backup\restore specific logs that we can look at please - and also the location of such logs.

kind regards

[gustenar · Accepted solution]

This involves looking at a support capture and internal dbs, not something that we can answer through here easily. This requires support involvement. 

[jlangmead]

OK - many thanks for yhe info

I'll see if I can take this up with Support.