# File Recovery

Even though the probability of a coordinated downtime that results in an unavailable file is negligible, the chance that a significant number of peers in a pool goes offline simultaneously still exists (e.g., a blackout, local disaster, fire).

To ensure the highest standard of durability (99.999999999%) and availability (99.95%), Cubbit employs 2 procedures:

1. Heuristics on pool selection: you can check the 5 criteria used for peer selection in the Redundancy section.
2. Lazy recovery strategy: we'll dive deeper below.

## Lazy recovery strategy​

If, after a series of cumulative disconnections, the redundancy of a file (i.e., the number of online shards $d$ that exceed $n$) is smaller than a chosen security threshold $d_0$ (being $0 < d_0 < k$), the Coordinator triggers a recovery procedure (called "Lazy recovery strategy"):

1. The coordinator identifies the ($k - d$) alternative members of the pool that will replace the offline ones.
2. The coordinator instructs a node to retrieve n shards from the damaged pool.
3. The chosen node retrieves $n$ shards and inverts Reed Solomon to obtain an encrypted chunk (note that it is not necessary to know the AES key used to encrypt the file to invert the redundancy process).
4. The node redistributes the recovered shards to the ($k - d$) new members of the original pool.

If you want to dive deeper into how Reed-Solomon error-correcting code works, check out the Redundancy documentation.