Storage Recovery

Design backup and restore acceptance

Backup is valuable only when a user can restore the intended data under the stated recovery conditions. Successful upload, encrypted object creation and a storage receipt are insufficient on their own. EdgeORE's current vault is device-local, so a future backup service must add a recoverable key scheme, remote retention and tested restoration before it can be advertised as protecting users from device loss.

Write the recovery promise first

Specify what survives: app restart, device replacement, lost password, lost wallet, node outage or a compromised provider. These scenarios need different mechanisms and tradeoffs. A device-bound encryption key protects local material but cannot be copied to a replacement phone as if it were an ordinary file. A portable recovery secret improves recoverability while creating another item the user must protect.

Do not make the wallet seed the default file-encryption recovery mechanism without an explicit reviewed design. Wallet signing authority and data recovery authority should not be casually fused. A user revoking a node session should not accidentally destroy a file-recovery path, and restoring a backup should not grant a provider wallet access. Separate those identities in the architecture.

Test on a clean environment

A restore test should use a fresh authorized installation or environment that does not already contain the plaintext or cached ciphertext. Retrieve the remote object, validate its identifier and envelope, unlock it using the documented recovery method and compare the output with the original. Record which secrets and authorities were required. A restore on the original phone with an intact Keystore answers a narrower question.

Test missing objects, corrupted shards, unavailable providers, wrong recovery credentials and interrupted downloads. The system should distinguish availability failure from authentication failure. Do not auto-delete the only recoverable copy after a partial restore. Integrity failures should stop plaintext release rather than returning whatever bytes remain. Error states are part of the backup contract.

Consider replication claims

Multiple acknowledgements do not necessarily represent independent failure domains. The same operator or machine may appear under several identities. Retrieval from several paths can provide stronger availability observations, but not universal proof of independence. A future evaluator needs a defined challenge protocol and an explicit trust model. Avoid a replica count that looks authoritative without explaining how replicas were identified and measured.

Retention periods and deletion requests also need precise semantics. An expired contract may allow a provider to stop retaining data, but the customer still needs warning and migration time. A deletion command cannot recall plaintext exports or remove all unknown copies. A transparent product describes these limits instead of promising permanent availability and perfect deletion simultaneously.

Define a launch gate

Before calling backup production-ready, require a documented recovery design, tested clean restore, outage handling, key-loss guidance, capacity bounds and an audited retention/payment policy if money is involved. Preserve an example restore run with non-sensitive data. The acceptance result is that a specific recovery scenario worked under specific conditions. It is not a blanket claim that no user can lose a file.

---

Wiki home · Qualification updates · Sources and credits