Recognising the anti-pattern: Backup and recovery
Why this deserves attention
Data protection requires tested recovery objectives, not only confidence that a backup exists. Clarity here reduces both delivery risk and the long-term cost of ownership.
A technically successful backup may be too old, incomplete or too slow to restore within the business tolerance. On 8 June 2025, this archive entry records the principle as a practical design concern rather than a product announcement.
Watch the warning signs
Look at backup and recovery through the early signs that a convenient implementation is becoming long-term risk. The objective is not to introduce more process; it is to expose the few decisions that determine reliability, ownership and future change.
Define recovery point and time objectives, include metadata and relationships, and rehearse restoration with accountable owners. Record the decision close to the solution so that delivery, support and future architecture reviews work from the same intent.
What good looks like
The organisation knows what can be recovered, how long it takes and which decisions follow a data incident. The team can describe the expected behaviour, the owner, the evidence of success and the response when reality differs from the design.
A useful next step is to review one live implementation against this principle, identify the largest unowned assumption and turn it into a bounded improvement with a measurable outcome.
Official reference
Official Salesforce Release Notes