Azure-docs: Clarification regarding the use of AutoRestoreOnDataLoss

[juho-hanhimaki]

Is AutoRestoreOnDataLoss suitable/recommended for production use? Is it implemented in such way that there is no possibility that it can cause any further data loss than what may already have occurred before the automatic restoration?

Are there any caveats / further considerations when using this feature?

---

Asiakirjan tiedot

⚠ Älä muokkaa tätä osiota. Sitä tarvitaan kohteessa docs.microsoft.com GitHub-ongelmien linkityksessä.

• ID: cbd34140-fc7b-80be-e55f-2f04270d1ad6
• Version Independent ID: 50da1aae-9c38-4e7c-cf94-8ed1f24fdd8e
• Content: Understanding periodic backup configuration in Azure Service Fabric
• Content Source: articles/service-fabric/service-fabric-backuprestoreservice-configure-periodic-backup.md
• Service: service-fabric
• GitHub Login: @hrushib
• Microsoft Alias: hrushib

[mimckitt]

Thanks for the question! We are investigating and will update you shortly.

[mimckitt]

@juho-hanhimaki I see no reason why it would not be recommended. Ability to auto heal is always good for production ready services.

@hrushib @aljo-microsoft Thoughts?

[juho-hanhimaki]

Better be safe than sorry for running production services. After all there isn't always a plethora of information out there to get in depth understanding how things work.

One would think AutoRestoreOnDataLoss was by default turned on if it was all around good thing. Yet I don't think it is by default?

[hrushib]

@juho-hanhimaki, AutoRestoreOnDataLoss is implemented in a way that there is no possibility that it can cause any further data loss than what may already have occurred before the automatic restoration with respect to the available SF nodes at the time decision is taken.

Whether to enable AutoRestoreOnDataLoss solely depends on the business need with respect to importance of service runtime vs. impact of (partial) data loss.

Note that, Any partition data restore results in moving the partition's state back in time, given this, the service code should not have strong data consistency assumption for the data across different partitions.