The Day a Backup Has to Work: How Senvra Brings Private Data Back

The day you truly need a backup is rarely a good day.

Maybe the phone is gone. Maybe the app was deleted by mistake. Maybe the device no longer turns on. At that point, the checkmark you once saw in Settings matters less than two practical questions: can the saved file still be verified, and do you still have the credential that opens it?

Senvra's current backup design answers those questions without asking people to manage a new secret for every backup.

Quick start: create, check, and restore

Create and save a backup

1. Open the space you want to protect, then choose Backup from the main menu.
2. Tap Backup, then choose Create encrypted backup for a private space or Create backup for the public space.
3. When the file is ready, optionally rename it, tap Save, and choose a destination in Files. Keep Senvra open until it reports Backup saved and verified.
4. For a private space, keep the Space Access Key that was active when you created the backup. Store the key separately from the .senvrabackup file and, ideally, away from the same iPhone.

Check a backup without importing

1. Return to the matching space type, open Backup, and tap Restore.
2. Choose the .senvrabackup file. Enter the source Space Access Key for a current private-space backup; a public-space backup needs no key.
3. Tap Check. Senvra reads and authenticates the complete archive without importing any content. A successful recovery drill confirms that this file and credential work together.

Restore content

1. Open the destination space of the same type as the backup, then select the file through Backup → Restore.
2. Review the detected protection type, provide the requested key when needed, and tap Import.
3. Senvra adds missing items and leaves matching items untouched. It does not replace the destination space's name, password, Access Key, biometric settings, gesture, or skin.

One Space Access Key, not a new Backup Key every time

For a private space, recovery now depends on two things:

1. the .senvrabackup file saved outside Senvra;
2. the Space Access Key that belonged to the source private space when that backup was created.

There is no additional Backup Password, and current backups do not generate a separate user-facing Backup Key.

This is a deliberate usability decision. A unique secret for every backup creates a growing set of file-and-key pairs that must remain correctly matched for years. That design can be cryptographically strong and still fail its real purpose if people cannot reliably operate it.

The Space Access Key is already the recovery material for a private space. Reusing that established credential makes the backup procedure easier to understand: protect the space key, save the backup file, and keep the two in separate trusted locations.

How a private-space backup is protected

The Space Access Key is not used directly to encrypt every photo, video, note, or document in the backup.

Each private space has its own random 256-bit master key. The backup carries an authenticated envelope that lets the matching Space Access Key recover that source master key. Senvra then combines the recovered master key with fresh per-backup random context to protect a newly generated Archive Key. The Archive Key encrypts and authenticates the backup records.

flowchart LR
    K[Source Space Access Key] --> E[Open authenticated access-key envelope]
    E --> M[Recover source space master key]
    M --> W[Derive backup wrapping key<br/>with fresh random salt]
    W --> A[Unwrap random Archive Key]
    A --> F[Authenticate and decrypt backup frames]

This hierarchy gives each layer one responsibility:

• the Space Access Key proves recovery authority for the source private space;
• the space master key anchors that space's cryptographic identity;
• a fresh Archive Key protects the contents of one backup file;
• authenticated encryption detects modification as well as hiding content.

The backup file does not contain the Space Access Key. Possessing the file alone is not enough to open a private-space backup.

Public-space backups are intentionally different

The Everyday public space is not a private vault. Its backups are therefore not presented as confidential encrypted backups.

A public-space backup requires no key to restore. Anyone who obtains that file can read or restore its contents with compatible software. Senvra states this before creation and restoration instead of implying protection that the public space does not provide.

Use a private space before storing anything that needs backup confidentiality.

The file is verified before and after it leaves Senvra

Creating bytes is not the same as creating a dependable backup.

Senvra writes the backup as a structured container and checks its authenticated records, item relationships, byte counts, digests, and end marker before presenting it as ready to save. Incomplete work remains pending and is not presented as a completed backup.

The next boundary is the copy operation. Saving through Files, iCloud Drive, external storage, or another provider can still be interrupted or altered. When you use Save, Senvra reads the destination file back and compares its header, byte count, and complete-file digest with the verified in-app source. Only a matching external copy is recorded as current.

Sharing a copy is still useful, but Senvra cannot read back every destination chosen by another app. A shared copy is therefore not recorded as externally verified.

A recovery drill reads the whole backup

A recovery drill does not import anything. It is a non-destructive test of the file and its matching credential.

For a current private-space backup, Senvra asks for the Space Access Key used when the file was created. It opens the key envelope, authenticates the header, reads every frame, validates item and archive digests, checks the final marker, and rejects unexpected trailing data.

That lets Senvra distinguish between:

• a valid older backup that can still be restored;
• a valid backup that also matches the current contents of the source space.

Both can be useful, but only the second represents the latest protected state.

Restore adds content without replacing the current space

Restore is additive. It brings missing items into the currently open space and leaves matching items untouched.

A private backup can be restored only through the private-space path, and a public backup only through the public-space path. Senvra verifies the complete backup before accepting imported data. Each restored item is written into a protected pending location, validated, and then published atomically.

The backup contains the source space's content and organization data, such as collections and tags. It does not replace the destination space's identity, name, password, Space Access Key, Face ID setting, gesture setting, or visual skin.

If import is interrupted, existing content remains intact. Selecting the same backup again lets Senvra skip matching items instead of silently creating duplicates.

Access Key rotation changes which key opens which backup

This is the most important operational detail in the current design.

A private backup remains tied to the Space Access Key that was active when the backup was created. Replacing the space's Access Key later does not rewrite files already saved elsewhere. The new key cannot open those older backups.

After rotating an Access Key:

1. keep the previous key for every older backup you still intend to retain;
2. create and externally save a new backup protected by the replacement key;
3. run a recovery drill on the new saved file;
4. retire the old key and old backups only after deciding they are no longer needed.

This behavior prevents a later key change from silently altering an immutable backup file, but it also means key rotation must be treated as part of the backup routine.

Older backups may ask for a Backup Key

Senvra can identify the credential scheme recorded by the selected file. A backup created by an earlier pre-release design may still ask for its original Backup Key.

Follow the label shown after choosing the file:

• Source Space Access Key means the current private-space format;
• Backup Key for older backup means that specific legacy file still needs the key saved with it;
• a current public-space backup opens without a key.

The app does not silently substitute one credential for another.

A routine that works in real life

1. Store each private space's Access Key outside Senvra and outside the same phone.
2. Create a new backup after meaningful content changes.
3. Save the .senvrabackup file to a location you control.
4. Use Save when possible so Senvra can verify the destination copy.
5. Run a recovery drill before deleting the last known-good backup.
6. After Access Key rotation, create and test a new backup before retiring old recovery material.

Senvra does not upload backups to a hosted vault. A location selected through Files may synchronize under that provider's rules, but the choice remains yours.

The honest boundary

For a private-space backup, the file without its matching Space Access Key cannot be recovered by Senvra. The Access Key without a backup file contains no archived content. If both are lost, there is no server-side reset or hosted copy. If both are exposed together, the backup's confidentiality is lost.

For the public space, possession of the backup file is sufficient because that backup is not confidential.

The simpler design removes a fragile per-backup secret, not the user's responsibility. Its goal is a recovery process people can actually complete: one established key per private space, one portable file per backup, explicit verification, and clear limits.

For the wider product context, read What's new in Senvra 1.3 and how Senvra protects private data on iPhone.

Further reading

• RFC 5869: HKDF
• NIST SP 800-38D: GCM authenticated encryption
• Apple Platform Security
• OWASP MASVS-STORAGE-1