Recovery guide

A practical backup plan for an encrypted private workspace

A useful recovery plan names the failure, the copies that survive it, the keys required and the test that proves the plan works.

Start with failures, not products

“I have a backup” is incomplete unless the copy survives the event you care about. Device loss, accidental deletion, Google account lockout, ransomware, forgotten credentials and physical damage require different separation.

List the realistic failures first. Then identify which encrypted copy and which recovery material remain available in each case.

Inventory the recovery components

For the SovaSpace Windows recovery workflow, important components can include:

  • the verified Cold Backup control package;
  • a separately kept and verified Root Key copy;
  • the required encrypted Nursova/ object mirror;
  • Secret Space Recovery Keys or the understood delayed-reset path;
  • the device and operating-system access needed to run the supported client; and
  • a record of where the components are stored, without writing secret values into an exposed checklist.

Large attachments may exist as separate encrypted objects. Do not assume that a small database or manifest contains all media bytes.

Separate the copies

Two folders on one drive are not independent against hardware loss. A cloud copy and a local copy synchronized by the same deletion event may also fail together.

Choose separation appropriate to the risk:

  • a different physical device for drive failure;
  • a different location for fire, theft or flood;
  • an offline or access-restricted copy for ransomware;
  • separately controlled account recovery for account lockout; and
  • documented succession access for material another authorized person may need later.

Protect keys without making them impossible to find

The Root Key and protected-space Recovery Keys can be as important as the encrypted data. A key stored only beside the device it is meant to recover does not survive loss of that device.

At the same time, an unlabeled key that nobody can associate with the correct recovery process may be practically useless. Use neutral, non-secret inventory labels and access controls appropriate to the sensitivity of the material.

Test read-only first

Open the Cold Backup in its read-only offline mode. Confirm that expected Entries appear and that the package can be accessed without altering the source.

Then test the object mirror and key procedure on a schedule appropriate to the importance and rate of change of the data. Record the test date and result, not private content or key values.

Define acceptable loss

Backup frequency should follow the maximum amount of work you can afford to lose. If one week of new notes would be unacceptable, a monthly copy cannot meet the requirement even if it is technically valid.

Also define how long recovery may take. A distant offline copy can be excellent protection but slow to retrieve.

Review after material changes

Revisit the plan after changing a Google account, device, storage location, password, Secret Space mode or major application version. A plan that refers to an old path or unavailable device is not current.

The goal is not the largest number of copies. It is a small set of independent, encrypted and tested recovery paths with known owners.

For the product-specific workflow, read Encrypted backup and recovery.

See how the complete workspace fits together.

Review the full feature map, current platform availability and security boundaries before choosing a workflow.